Re: Overzealous suspend everything watchdog [workaround included]
 

Allright, just tried this, altough I did not login via USB, but via WLAN.
And lo and behold!, it works just as you describe. If I do not touch anything it will not refresh. If I touch a key, it will refresh.

Also, if I ping it from another device, it starts to refresh the top listing.

Re: Overzealous suspend everything watchdog [workaround included]
 

Yep, I meant WLAN -- fixed the post.

Re: Overzealous suspend everything watchdog [workaround included]
 

OK, so you argue that as the wakelock taking process is gone, now the device should revert back to the non-responsive state, right?
I tried that command, logged off and logged back on, and now when I launch "top" it does refresh continiously... How is that?

Re: Overzealous suspend everything watchdog [workaround included]
 

Well, no idea. I might be completely wrong.

Re: Overzealous suspend everything watchdog [workaround included]
 

With just ssh in top does indeed pause for me. I'd not noticed this before. I presume it's because I usually have an sshfs running too as that's the only semi-nice way I can get to it from my Mac.

Re: Overzealous suspend everything watchdog [workaround included]
 

After 8 hours off charger the SbJ is at 60% with the suspend disabled which is not bad, so I think I'll keep it like this. Definitely better than the Z10.

The only thing I miss is the double-tap to unlock, especially now that the phone wakes up instantly. Before it took a couple of seconds to wake up, to the point that I pressed a second time resulting in the phone responding to both events and waking up for a moment before sleeping again.

Re: Overzealous suspend everything watchdog [workaround included]
 

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...

Re: Overzealous suspend everything watchdog [workaround included]
 

Never said it doesn't, just thought I'd mention it as had to run and my question on IRC had no other answers at this point.


Interesting, need to compare battery consumption in both cases, though expecting the same, btw when Jolla is acting as a hotspot (without sim, just for ssh) I have no problems connecting to it after some time (whether new connection or resuming old), but battery consumption is even worse than suspend and on router.

Can you share your workaround, want to see which way is best to have (and the least battery hungry)

Re: Overzealous suspend everything watchdog [workaround included]
 

Ah, I see. Well, echo asdf > /sys/power/wake_lock is basically "my" workaround too. I was just too stupid to figure out that there was a way to create these wakelocks from userspace. From what I see, a userspace space wakelock should be the same as a kernel one (except the type is forced to WAKE_LOCK_SUSPEND but this is what we want...).

---------

So, I've found the difference.

Seems that Android has a middle state between suspend and normal that is called "early-suspend". "Double tap to unlock" seems to be enabled during early-suspend, and thus will only work when the device is either suspend or "early-suspended".

Having a wakelock prevents the device from suspending when the screen is off, but it will not prevent it from going to early-suspend, it seems. So double tap to unlock works and I presume some peripherals are put in a low power mode (dynpm on Android is basically non-existant it seems).

Using mcetool --set-suspend-policy=disabled disables BOTH suspending and early-suspend altogether. Therefore, double tap to unlock does not work. However, there is a third method, mcetool --set-suspend-policy=early, which enables early-suspend only. I suspect this third method will be exactly the same as taking a wakelock.

Re: Overzealous suspend everything watchdog [workaround included]
 

Tomorrow's question, does the SbJ have better battery life with --set-suspend-policy=early?

So far I'm pretty much happy that it made it for 14 hours with 15% remaining with suspend completely disabled.