Hacker News Reader

Comment by krageon | Hacker News Reader

This person doesn't need the core features of a modern smartphone: consistent alarms and reliable connectivity. As such, it is no wonder they love the pinephone: it is essentially a tiny laptop!

That said, I don't find this very compelling: I am in fact called by people and I don't think having to implement a hack around the system's sleep state is acceptable (especially given that it may still not be reliable, what with the dependability profile of the connectivity chipset). It may be more accurate to call this a Pine: Not much of a phone to be found.

View on HN

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

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.

Agreed. In addition my Pine phone needed a heatsink to handle 95+ degree weather. That's in the open air... when sitting in the pocket it radiated a scary amount of heat.

They are a neat gadget. But I don't think they're more or less of a neat gadget than any other Quectel 25(?) based iot device. The phone form factor, for me, was rendered useless.

If you don't use WiFi, try turning the dip switch off. In my case it makes the phone 7-10 deg C cooler (~39 -> ~31). It'll also make your screen brighter; I can lower brightness from 25% to 0% for indoor lighting.

(This is regardless of whether you're connected to a WiFi network or not. ie just disconnecting from a network isn't enough; you have to turn the dip switch off.)

You could describe it as a Phone-shaped Pine. Which is pretty cool all on its own.

If I'd bought a PinePhone expecting a working phone, I'd be pissed. But as a hackable phone-shaped Linux platform, it's totally cool.

I've not had OP's connectivity issues, so it works pretty well as a phone. Certainly better than my OpenMoko, which kept having audio issues requiring fiddling in /etc/alsa.conf

I agree about alarms; but like OP, I only use them when the phone's plugged in overnight, and hence not suspended. For ad-hoc alarms on the move, I just use my digital watch.

Same here, no problems with connectivity on my PinePhones' (first edition and pro).

Perfectly functional phones with the added advantage of hardly any spyware or other garbage, plus - if I wanna - I can leave it anywhere for an instant reverse tunnel. Handy for many, many things ..

> That said, I don't find this very compelling: I am in fact called by people and I don't think having to implement a hack around the system's sleep state is acceptable

Nobody has to implement hacks. There's a proper solution on Pinephone that can wake/power it on alarm. OP just doesn't know how to do it.

A proper solution would be that it just works.

That's an unrealistic expectation of this phone. If you want thinks to just work you shouldn't buy a PinePhone and they make that really clear on their website.

The sale page of the PinePhone says this in red letters[0]: "Beta Limited Edition PinePhones are aimed solely at early adopters. More specifically, only intend for these units to find their way into the hands of users with extensive Linux experience."

And their wiki has this to say[1]:

"Bear in mind that the software for these smartphones is very early, with most of the software being in alpha or beta state. That's especially also the case for scalability of applications, their availability and practicability, any hardware function implementations and the firmware. The software is provided as is. There is no warranty for the software, not even for merchantability or fitness for a particular purpose."

[0] https://pine64.com/product/pinephone-beta-edition-linux-smar... [1] https://wiki.pine64.org/index.php/PinePhone

It just works for me. It may not just work for you if you load your phone with some software that doesn't use the available features fully. But that's not really the problem of the HW itself.

I’ve found a watch to be way more effective than any phone or other device I’ve ever tried at keeping a reliable alarm.

And no; not a smartwatch that needs charging every day - or ever…just a timex that might need it’s battery replaced every year or two.

As far as reliable connectivity, dumbphones are way more rock solid than any smartphone could pretty much ever hope to be.

Yeah I like it for this too. What Samsung Dex was except not a $2K phone.

The reliability on HDMI out is flaky though in my experience. I have both versions of Pinephone eg. Pro.

Disable sleep state. Problem solved. I daily it as a simple phone and telegram.

Reply on news.ycombinator.com