[BetterBatteryStats] Tungstwenty:
Thanks for that info. This was motivation enough for me to look a bit more into how this particular app works, especially considering the fact that on GNex or other devices there are "soft"/touch keys like home, menu, etc. which on other devices are physical keys and therefore still work even with the TS device fully powered off.

I inspected the ARM code of the kernel module (no sources are available) and it's a pretty interesting approach, especially considering the fact that it will work even on stock kernels. It does some hacking around the original TS driver so that its sleep/wakeup triggers are overriden :)

From what I saw, it's exactly the same as on the S2:

1 - After the screen turns off, a "pre-suspend" hook on the TS driver is called (and other device drivers might do the same)

2 - That routine (actually called early_suspend) will, like on the S2, disable the interrupts from the hardware and will also shut down the power from the TS sensors. Disabling the interrupts is kind of redundant, since the HW will not know fingers touched it and will not raise an interrupt anyway.

3 - During this state - and note that this doesn't mean the device is in deep-sleep; it can be still awake doing stuff on the background such as a download, etc. - screen interaction activity is non-existing whatsoever. The sensors are also not draining any kind of power from the battery.

4 - If the device goes to full deep-sleep (other HW devices such as the sdcard controller might get fully shut down, and CPU also goes idle), it is just a particular case of the previous item.

5 - If during deep-sleep there are any sort of HW interrupts, the CPU awakes from its sleep. The IRQ routine can then either handle the interrupt and go back to sleep (e.g. look at a received WiFi packet and completely ignore it) - and this CPU overhead will only show in the CPU stats and interrupts counter, not in KWLs - or it might break deep-sleep by activating (even if temporarily) a KWL and schedule some work after the interrupt handler finishes. The KWL is used to make sure deep sleep does not kick in again before that scheduled work has a chance to run. And in this 2nd case you'd then indeed see in BBS the KWL time and counter.

5 - Just before the screen comes back up (if it does, since a wake up might not turn on the screen if all it's doing is e.g. sync'ing your emails), the TS driver early_resume routine is executed. It resumes power to the TS sensors and reenables the interrupts coming from there. Remember that even with the screen on, the CPU may go idle (not "device-wide" deep sleep, just CPU idle) and it's the interrupts that make it resume to do something.

Ok, that was "kernel drivers & devices 101", I guess (I wouldn't know most of this perhaps 1 month ago :D)

Back to the Slide2Wake feature.

On a custom kernel like Siyah and others before it, activating s2w will change the early_suspend routine (item 2) so it no longer shuts down the power from TS sensors. Also, it doesn't disable interrupts any more for that piece of HW, which now still has enough power to detect touches, if any, and raise interrupts for the CPU to wake up and handle.

This alone, even if no touches occur and therefore the interrupts are not raised, surely causes a measurable (?) drain increase, to keep the sensors up and running. This is the key aspect of this entire reasoning.

If touches do occur (be it by the fingers or by the pocket cloth, if it's picked up), then we'll add some CPU consuption for it to wake, handle the interrupt, and go back to being idle. This is the part that is visible indirectly - in CPU stats and in /proc/interrupts.

About PGM:

It does exactly the same, except for the fact that it doesn't rely on the original early_suspend and late_resume routines being changed, nor the interrupt handler code. Instead, it dynamically redirects those to be under its control. If you activate s2w in the app, it prevents the original atmel_ts_early_suspend / _late_resume routines from even running, leaving the TS power always on. That will surely increase the drain, but ultimately it needs to be measured indirectly with some battery level monitor to see the drain rate. The interrupt routine is also hijacked in order for the module to detect if the magic wake-up touch sequences occurred, which will trigger the screen on or whatever action. Pretty neat idea, really.

Indeed. But following my line of though above, I'm more inclined to blame the relevant power consumption on the (perhaps small) TS sensor *constant* drain, rather than the very sporadic CPU execution of the interrupt routine.

It all depends on how much drain each device's TS sensor requires in order to merely be "listening".

I'd suggest superbobup (and others) to use My Battery Drain Analyser to check in the morning what rate of discharge did you have during the night under stable conditions (with wifi off, sync as well, perhaps even in flight mode if you want).

Do it one night with slide2wake active (or with the PGM module loaded), and another without it.

The attached screenshot shows one of my readings - the one where I left s2w turned on overnight, showing values around 1 %/h until the alarm went off.

Cheers

TT