[Nexus 4 Android Development] thracemerin:
Frequently Asked Questions

Q: You gave us 192Mhz, now you removed it and set 304Mhz back to 384Mhz, why?

A: Good question, there had always been some speculation in this thread and others that frequencies below 384Mhz were not in fact being set correctly, show-p1984 managed to run his device at 27Mhz with no stability issues (this should be impossible) so we did some quick and rather unscientific benchmarking in this thread and found that there didn't seem to be any difference in CPU performance between 192Mhz and 304Mhz (and there should have been), I then speculated that 304Mhz was also not being set, after a little more unscientific benchmarking I determined that there was no difference in performance from 304Mhz to 384Mhz either, so based on this I don't see any reason to allow these frequencies.

Q: I don't want to use the 192mhz frequency, how can I disable it? (Build 3-6)

A: One of the four options below will fix it:

You can delete my script, it's located at /system/etc/init.d/01cpu and reboot, this will set you back to 304mhz minimum.

You can remove it from the zip file (same location in the zip hierarchy) before you flash.

You can use your favorite kernel tuner (trickster, fauxclock, etc...) to switch the minimum frequency back to 304mhz and set it on boot.

You can change the /system/etc/init.d/01cpu script to set whatever minimum frequency you want (it has to be a valid one from the table)

Q: If the 192mhz and 304mhz steps use the same undervolt settings, how can 192mhz use less power?

A: The formula for power consumption is: P = f * c * V ^ 2

Where: P = power consumption, f = frequency, c = capacitance and V = voltage

So: since c is constant in this case, and we'll assume you've used the lowest UV possible (600mV)

At 304mhz: P = 304 * c * 600 ^ 2

At 192mhz: P = 192 * c * 600 ^ 2

This means that 304mhz uses approximately 1.58 times more power than 192mhz over the same time.

Q: There are a bunch of fixes for the delayed notification issues in various threads, what should the settings be for this kernel?

A: The following values should be set in your /system/etc/wifi/WNCSS_qcom_cfg.ini (depending on your ROM you may have different values), these are the Google stock values and appropriate for this kernel.

McastBcastFilter=3
HostArpOffload=0
gEnableSuspend=3

You can set these values by flashing this: wlan_revert.zip - MD5 - 381013687035626bcb1cbaf609ea4311

Q: Does this kernel include the ARP offload patch?

A: No, and for those of you following my other thread here: http://xdaforums.com/showthread.php?t=2102986 you will know that there is an issue where our WiFi chip responds to ARP requests with a bad MAC address during deep sleep, this results in problems with direct connect (WiFi direct, AirDroid, etc...) and can cause issues with certain types of routers and networks that do not cache ARP addresses for long, as a result I no longer use it in my other kernel either. I am using a different solution which solves the problem for me and many others but has a slight battery life hit, I will post a flashable zip to modify the binaries to include this fix at a later time, but for now if you wish to include this fix do the following.

open /system/etc/wifi/WNCSS_qcom_cfg.ini in your favorite file editor
find the line that currently reads gEnableSuspend=3
change the line to read gEnableSuspend=2
save the file
reboot your device.

Q: I flashed this kernel and my battery life sucks! WTF?

A: Clearly I didn't design this kernel to drain your battery (nor did _motley) and in my experience most battery drain issues are app related and not kernel related. In order to help me help you solve the problem, please download Better Battery Stats either from the Play Store (costs money, but I strongly encourage supporting the dev) or the free version from XDA and provide me with a dump file for a few hours of use so I can see what is going on with your device, if you don't do this I will assume the battery drain is your fault and will ignore your complaint.

Q: Can you add feature x from kernel y?

A: Maybe, I'm not going to take this kernel and stuff it full of every single idea anyone has while lying in bed trying to fall asleep, but if the feature seems like something that most would use and it's in a reasonable state of working (ie. not something that someone else just started working on) then I will consider adding it, absolutely no promises in this regard.

Q: I got a random reboot, SOD, other bug that must be kernel related, what do I do?

A: Provide me with appropriate logs (dmesg, logcat, last_kmsg (see my sig)) and instructions on how you caused this if possible, if I can't reproduce the issue and I can't see it in the logs there is nothing I can do. Be as detailed about what you were doing at the time it happened, more information is always better than less.

Q: If _motley comes back what will happen with this project?

A: Well, I don't want to step on any toes here, this was originally _motley's work, what happens to it long term if he returns will ultimately be up to him. If he wants to continue from where he left off and merge his own changes beyond b49, I may keep going as a separate project, if he wants to fork me and continue from the point I'm at when he returns that's ok with me too and I'd probably stop if that were the case, but we're speaking in hypotheticals here, anything is possible.

Q: Touch control doesn't work! Why not?

A: Touch control requires a module that is compiled by the author and provided as a pre-compiled binary. I'm not specifically looking to break it's functionality, but changes I make may cause it to stop working at any time between releases, the only way to get this fixed is to speak to the author of the addon and have him recompile the module. If he needs my assistance with anything specific to this kernel, I will do my best to help him out.