View Single Post
Posts: 1,101 | Thanked: 1,185 times | Joined on Aug 2008 @ Spain
#507
Originally Posted by auouymous View Post
Does /sys/devices/platform/i2c_omap.2/i2c-0/0-0045/disable_kp (n810) exist and does it lock/unlock keys when writing 1 and 0 to it?

Does writing 1 and 0 to /sys/devices/platform/omap2_mcspi.1/spi1.0/disable_ts lock (n800 and n810) and unlock the screen?
Yes.
Let me know if this is still a problem after I release the new code, and if it is try to let me know what conditions cause it.
Installing latest test binary now.

Kroll mentioned some abnormal battery drain a couple releases back and I optimized a few of the hardware polls but none of the changes shouldv'e made any noticable changes in battery life. The loop goes to sleep when screen is off or ASUI is unmapped and only dbus signals will wake it briefly. You can test this by installing the debug binary and watching its log while the screen is off or ASUI is unmapped.
Since it only happened to me once up to now, it may be difficult to reproduce. While it was happening, I looked at "top" output; I didn't see much, but it looked for a moment that there was some periodic dbus traffic with icd2 which caused short cpu spikes, with the device in "flight mode".
I'll run the debug binary from now on and hope it reproduces again.
For a couple months now I've had a 0.4%/minute drain, with no load and screen off, after turning off wifi or entering flight mode. Even happened after I reformated and hadn't yet installed ASUI. I had to reboot every time I used wifi. Recently found out that if I stop ssh and all wifi services the problem goes away. So your 0.8%/hour is nothing!
Mi wifi AP (my PC with an atheros card) can sometimes leave the battery dry in a couple of hours because it don't supports power management correctly, so yes, a stuck wifi is really dangerous