4 ms·

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

by megous 4y ago

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.

julienpalard 4y ago
True. There's a demo prooving it: https://wiki.mobian-project.org/doku.php?id=wake-mobile https://wiki.mobian-project.org/doku.php?id=wake-mobile (Tested on my PinePhone on Mobian: it works!)
- megous 4y ago
  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
  - Arnavion 4y ago
    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.
    - megous 4y ago
      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#L39 https://gitlab.com/seath1/waked/-/blob/master/src/main.cpp#L... But why not, it's FOSS. :)
      - Arnavion 4y ago
        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.
        megous 4y ago
        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?
        Arnavion 4y ago
        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/146/diffs#8074a9cf0e5dac92ab12215f4a171b906100414d_0_79 https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests...
      - CameronNemo 4y ago
        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.
        megous 4y ago
        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.

by megous 4y ago

julienpalard 4y ago

True. There's a demo prooving it: https://wiki.mobian-project.org/doku.php?id=wake-mobile https://wiki.mobian-project.org/doku.php?id=wake-mobile (Tested on my PinePhone on Mobian: it works!)

megous 4y ago
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
- Arnavion 4y ago
  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.
  - megous 4y ago
    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#L39 https://gitlab.com/seath1/waked/-/blob/master/src/main.cpp#L... But why not, it's FOSS. :)
    - Arnavion 4y ago
      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.
      - megous 4y ago
        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?
        Arnavion 4y ago
        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/146/diffs#8074a9cf0e5dac92ab12215f4a171b906100414d_0_79 https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests...
    - CameronNemo 4y ago
      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.
      - megous 4y ago
        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.