Hacker News Reader

Comment by nousermane | Hacker News Reader

> core features of a modern smartphone: consistent alarms

For me personally, this is one thing missing from a modern smartphone. Many old-school GSM phones, when completely turned off (but battery still inside), if there is an alarm programmed, will turn on automatically few seconds before the programmed alarm, just in time to sound on the dot.

Very useful, and exactly what I want, when I go to sleep. You can sort of approximate that with "do not disturb" mode, but that drains a bit of battery (and traffic in cell data plan) uselessly.

View on HN

This works on pinephone and pinephone pro, too.

On Pinephone, the RTC(has alarm support) is in the SoC and is always powered by PMIC even when the phone is off. PMIC can be configured to power up on interrupt signal, and SoC can be configured to pulldown the interrupt line on RTC alarm.

On Pro RTC is inside PMIC directly.

HW can do it. Alarm app just has to use the HW correctly.

True. There's a demo prooving it: https://wiki.mobian-project.org/doku.php?id=wake-mobile

(Tested on my PinePhone on Mobian: it works!)

Yep, all the alarm clock program really needs to do for this to work, is to setup a timerfd with CLOCK_REALTIME_ALARM flag set.

Then timer firing will wake the system.

That's pretty much it. Standard Linux feature across all systems that support system suspend and RTC wakeup.

man timerfd_create

And for non-systemd systems like postmarketOS, there's waked that writes directly to the RTC dev node directly for the same effect. pmos also patches gnome-clocks to use waked.

That's an "interesting" solution, since exactly what waked does is already done by kernel internally if you use timerfd, without the need for any special daemon. Any app that wants to be woken up at certain time can just register a timer for that time with the kernel.

I wonder if waked writing directly to RTC doesn't break the kernel alarm functionality used by timerfd, but hopefully not https://gitlab.com/seath1/waked/-/blob/master/src/main.cpp#L...

But why not, it's FOSS. :)

The issue is that it's not possible to create wakeup timers without root or CAP_WAKE_ALARM, hence why you need a more privileged daemon of some sort that your regular alarm clock app binary. Eg with systemd it doesn't let timer units in the user session that can wake the system, which is what is blocking gnome-clocks upstream from using systemd timer units.

But yes, I don't know why waked uses the dev node directly instead of using CLOCK_ALARM, and it's definitely possible it interferes with anything else going through the kernel using CLOCK_ALARM.

Maybe I'm missing something, but why not simply `setcap cap_wake_alarm+p gnome-clocks` and any other app that may legitimately use this?

No, you're not missing anything. I should've been clearer that I was talking about gnome-clocks specifically, which wants to use systemd both so that only systemd needs the privileges rather than gnome-clocks itself and so that it can autostart gnome-clocks using the timer [1] even if gnome-clocks is down at the time (ie gnome-clocks doesn't itself need to keep the timerfd alive).

In general, setcap'ing the binary will work fine.

[1]: https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests...

I think one reason not to use the timerfd method is that you (waked) could drop the fd if it terminates unexpectedly. There is probably a way to persist the db separately... But the device node is right there.

If waked terminates unexpectedly, it has to be told about all the registered alarms by all apps again after restarting. Apps need to be notified to provide the info again, etc. If waked would keep a database, then you have a syncing problem, between apps and waked, possibility of desynchronization. If app crashes, and doesn't remove alarms from waked, the phone will wakeup, but there will be no app to present the UI. Sounds confusing.

Automatic resource management by kernel when the app crashes or is stopped is actually quite nice. You just restart the app and setup the timers again from the stored settings. You have to store alarms persistently, in any case. You'll get event in the eventloop of the app that registered the timer, etc. Complexity of the solution is minimal. Less opportunity for bugs and failures.

it has to be told about all the registered alarms by all apps again after restarting

Is that true? Or does it just read from the rtc state? (Or leave it alone?) Also for efficiency reasons, don't you want a single wakeup being scheduled rather than potentially spaced out wakeups?

stored settings

Aka a database, right? Albeit a per-user database. What you are talking about sounds more like a service (daemon) than an app, though, from my perspective. A sort of per-user waked. That operates by holding timerfds it negotiated away from a privileged service. You can't revoke FDs anymore/yet, right? Although you can mark them cloexec and go on a killing spree.

> Is that true?

Yes.

I just want the timer to fire and be handled in the process where it's needed, regardless if the system is suspended or not completely transparently. Waked doesn't help with that. I certainly don't want a special daemon that I have to register with over a complicated protocol (d-bus) in addition to having to manage the timers in app when it can be avoided just by passing a single flag to timerfd_create which will work universally and will not depend on systemd.

Spliting alarms into a deamon and UI shell is kinda pointless unless some other app would need access to alarms. But that would be a different service than waked in any case. Waked doesn't handle timers.

Did you know that this works on some modern smartphones ? At least my OnePlus 7TPro does wake up from an alarm when it's totally powered down.

In my experience, this feature is common on Chinese android phones, but not on Pixel, Samsung, Sony...

I dont want my phone waking up no matter what when I power it down. I powered it down because I want it down.

Most smartphones do that, it's part of all SoC vendors' base code. However Google Pixels don't do that (which leads to no standard Android API available for that...)

> You can sort of approximate that with "do not disturb" mode, but that drains a bit of battery (and traffic in cell data plan) uselessly.

Airplane mode helps too I find.

Yep. Is what I always do now.

This is the case for Xiaomi and I think for Samsung (I use both)

I'm pretty sure the chipsets in a modern phone still support waking up at a given time even from 'off' state.

Just no OS exposes an API allowing that to userspace.

Reply on news.ycombinator.com