Hacker News new | ask | show | jobs
by mg 1467 days ago
I also have one for two years now:

https://twitter.com/marekgibney/status/1276881389091278848

I have to say that I never found a use case for it.

I remember that I hated the OS it came with. I think it was some flavor of Ubuntu that did not let you install software in any normal way. If I remember correctly, I did not even manage to get vim running.

After some reading up on mobile Linux distros, I switched to Mobian, which I generally liked.

But then I noticed that the phone wakes up and turns on the screen at random intervals. And quite often. Never found a solution to fix this. The web is full of reports about it:

https://www.google.com/search?q=pinephone+wakes+up

I watched the development around it for a while and contributed some details about the issue. Checked back every few weeks and did not see any progress. Then forgot about the phone at some point.

2 comments

I have a Pine64 board from an ancient Kickstarter. Some parts of it like video decoding have never worked. There was at one point something vaguely in the shape of a driver that was supposed to support it appeared in an undocumented zip file but I never managed to get it to work. Requests for specs so the community could write their own driver fell on deaf ears. I decided never to buy another Pine product again, and I have not regretted that decision.
Allwinner A64 supports accelerated video decoding in mainline Linux for a few years already. (See the links I psoted elsewehere in the comments.)
I suspect this is due to incoming messages waking up the cellular modem, but the host being unable to recognize them. Either spurious, or dropped.
It's a subtle problem of tradeoffs. How do you keep the system aware of incoming messages when you'd like to save as much battery life as possible?
This is a problem Android, which is also Linux-based, has already solved. You can wake up a process (on a power efficient core, if available) without waking up the screen.

One problematic issue I can see the Pinephone have in regards to this is that there's no unified push service that works for all apps. Google has forced everyone on Android to use their push service and it's terribly restrictive for application development but over the years this has also solved a lot of battery life issues. Apps holding open connections of their own just to see if there are any notifications is fine on desktops but it's a challenge open platforms will need to solve somehow.

> One problematic issue I can see the Pinephone have in regards to this is that there's no unified push service that works for all apps

I won't reveal exactly where this is happening because the software is still in a proof-of-concept stage, but KDE folks are working on a 'unified push service' right now.

> One problematic issue I can see the Pinephone have in regards to this is that there's no unified push service that works for all apps.

I don't think that's the problem. It would not be that hard to have system-wide settings to control which applications can apply for background updates.

My (limited) understanding is that the difficulty resides in hardware support for sleep/low-power and the many different implementations from every hardware vendor. Note that it's also a problem on desktops/laptops (with S3 and related techs) even on Windows using official firmware/drivers.

If you have more detailed reads, please share :)

I wonder if running Mozilla's autopush[1] and making web push a standard across apps would help solve this?

This would let you run your own push server (or use someone else's), configure it system wide on your device, and all apps would be able to use it automatically with their services.

[1] https://autopush.readthedocs.io/en/latest/index.html