I've been reading the Android kernel source a bit (I'm an Android hater, not a hacker, and would prefer to keep it that way -- besides I feel like puking every time I read some of the hacks).

Seems that user-space wakelocks are not reclaimed when the process dies -- and thus they are prone to being leaked (a dubious decision if you ask me). But then this means that the approach in the first post is a valid way to take a permanent wake lock:
And indeed I've checked and it does the same my trivial module did. If you do the above command, the kernel is not suspending. You can list current wakelocks in /proc/wakelocks.

I have no idea why it doesn't work for szopin -- maybe we are talking about two different problems here? What's exactly the difference with mcetool "suspend policy"? I am quite sure that with an active wakelock it does not suspend at all.

Besides, with the wake_lock, double tap to unblock still works.


Yeah, well. I discovered this the moment I logged in via ssh to the device. Not only it was a surprise to me: the fact that no one else mentioned this was also a surprise. Opportunistic suspending is terribly annoying if you're trying to do anything useful with the device -- background applications basically get SIGSTOP'd the moment you turn the screen off. Computations are interrupted, timeouts are ignored, and writing daemons becomes hard.

If I had known beforehand that the Jolla device used opportunistic suspending, I probably would never have bought it. I know they probably had no choice....

The good news is that I was using "permanent wake_lock" mode to workaround this and that it had 'acceptable' battery life when compared to the stock (with tohd running) software.
The bad new this is that improving the battery life when under "permanent wake_lock" mode might be very well impossible. The kernel is full of hacks (Qualcomm-made no doubt) that just assume the device is going to spent most of its time suspended. There are bazillions of sub-second timers everywhere, in the kernel, the Android side...