Support periodic wakeups

calebccff commented 2 years ago

From what I can tell, stated currently doesn't handle periodic wakeups to reconnect to wifi and fetch notifications. This can (I think) be implemented by adding RTC support to stated:

When unlocking wakelocks, if the wakelock we're unlocking is the last active one (and we therefore expect the device to go into suspend), register an RTC wakeup event for some time in the future (30 seconds, 1 minute, 2 minutes, ??).

It's worth noting that the RTCs on Qualcomm devices are read only, they almost always have the wrong time. This has to be worked around by setting the RTC wakeup time relative to the current time in the RTC itself.

g7 commented 2 years ago

I was discussing about this some months ago with @DylanVanAssche, he showed me that on postmarketOS they're using a little daemon called waked: https://gitlab.com/seath1/waked and we shared some thoughts about what upstream-Purism wants (i.e. using systemd) and what other stakeholders (pmOS, Droidian, etc) want.

Using systemd timers looks good in the surface but in my view it's not worth it once you want to do something more complex (like aggregating multiple wakeups firing up in the same period - so you wake only one time). Plus there is this whole not-working-on-other-init-systems thing which is less than ideal :D

Since apps need to be changed to actually register an RTC wakeup, I think we need to decide where is the best place to handle this. I do not want to duplicate efforts so I'm more partial on using waked for now. An alternative would be exporting the same DBus interface as waked so at least application changes can work with either daemons.

I'll want to provide an (PolicyKit-gated) interface to register wakelocks, so in future this flow might work:

(waked) RTC wakeup registered ---> (stated) opportunistic suspend ---> (device) RTC wakeup fires ---> (waked) timed wakelock obtained ---> (apps) wakelock obtained + processing happens

It will probably work better once I ditch PM_AUTOSLEEP so that stated can handle the whole suspension flow like it happens nowadays in Android.

What do you think? /cc @DylanVanAssche interested in your thoughts too if you have time

calebccff commented 2 years ago

that sounds quite good, I wasn't aware of waked.

could you expand a little on ditching PM_AUTOSLEEP (or drop some Android docs)? I wasn't aware they did something else now.

g7 commented 2 years ago

This is how it works in Android: https://source.android.com/devices/architecture/systemsuspend

Relevant work in other distros:

mce (Sailfish OS) uses PM_AUTOSLEEP but it enables it only when entering suspend, thus behaviour is similar to the one above (mce still controls when to go to sleep)
repowerd (Ubuntu Touch) uses PM_AUTOSLEEP as well, didn't check when it gets enabled though. As a fallback, it can use Android's libsuspend as well (actually I think UT on oneplus6 uses that, but I might be wrong)

droidian / stated

Support periodic wakeups #2