My experience running desktop Linux on PinePhone

[Subsentient]

NOTE: This may be a bit ranty, because frankly I'm frustrated. Please excuse that, no offense is intended.

Background/context:

I've been running Fedora with XFCE (big icons etc) on my PinePhone since around the beginning of the pandemic. Maybe April or May 2020? Not sure. I've been using it as a daily driver, patiently, fixing issues as they arrive, for that span of time.
I've had two PinePhones in that time, a Mobian CE and a Braveheart.

I've been building custom kernels based on megi's sources for the majority of that time. They're not really modified much, they just have things like btrfs as builtins, and my occasional patches for stability or compile fixes. My PinePhone Mobian currently runs kernel 5.15.11, the latest at time of writing.

I'm a programmer myself with a background in several systems languages and several scripting languages and cross-platform development, though mostly userland.

The last straw today was when I tried to play music in a lyft and the system hung because I dared try to play audio out of the 3.5mm jack.

Here we go.

We're now about to enter 2022, and I still have a miserable experience daily. It's a rare day indeed that my PinePhone doesn't seize up entirely at least once. It's not the RAM speed issue, that's fixed for me, I'm at 400 something Mhz. Hard lockups are usually caused by any one of: rtl8723cs wifi drivers, Goodix touchscreen related Xorg hangs/segfaults, sound card drivers, or just using more than a few hundred MB of data over wifi. I finally got Bluetooth working, but the audio performance is so bad that it pops and cracks constantly, making it unusable. Sometimes Pipewire (Fedora's pulseaudio replacement, and Pulseaudio before that) just randomly crashes with no explanation. Sometimes a phantom finger shows up and decides to hold down something on the screen so I can't use the screen at all.

What's become clear to me is that it's the drivers that are the issue, not the hardware, and for the mostpart, not the userland.

It seems to me that developers have patched just enough of the most common issues that it works fine for custom touchscreen GUIs that do exactly one very specific thing (which I can't stand, I want a real desktop with a virtual keyboard and window manager), but the vast majority of not-so-uncommon edge cases are ignored completely, meaning that anyone running a normal, non-phone-oriented OS and GUI will constantly hit them. If there are fixes/hacks in mainstream PinePhone distros, they are undocumented and/or out of date, because I sure as hell can't find them anywhere.

I don't blame the kernel developers who volunteered to work on the PinePhone, in fact people like (and especially in specific) megi are the only reason that things can work at all.

I blame the concept of expecting the community alone to entirely write the drivers for this hardware. I've been very, very patient, but I strongly believe that Pine needs to hire someone with a background in Linux driver development at least part-time to clean this mess up. (I'm tired of fixing other people's C, so don't look at me, at least right now)

I imagine most of the contributors are like me, programmers with a day job and not a lot of free time, so they try to get the bare minimum functioning, but they have no time to refine it or fix edge cases, or work on big refactors. The result? A bug riddled abortion that can barely boot to a desktop without emitting a mushroom cloud due to some bizarre edge case or race condition/deadlock in a kernel driver.

It's now in a situation where I"m scared to copy 200MB to my PinePhone over SSH because there's a 60% chance it will hard-lockup in the middle of the transfer. (that wifi issue has been happening since I got the first PinePhone, by the way)
Don't get me started on the call audio routing model. That should never have been an ALSA thing. That should have been a bitstream on some device node that was rendered by some userland app to the user's sound system.

Just thinking about how the thread icon should be a broken lightbulb.

I'm sorry guys, I'm tired, and I'm angry, and I'm deeply disappointed.

Please share thoughts, solutions, and similar experiences.

[barray]

The last straw today was when I tried to play music in a lyft and the system hung because I dared try to play audio out of the 3.5mm jack.

You think the PinePhone is bad, try being a PineTab user. You get all the same A64 lock-up issues plus some hardware issues (such as the fact my WiFi and Bluetooth completely died for no reason). I've heard an uncommon number of people chewing through SD cards too. I really suspect there are actually tonnes of undiagnosed hardware issues out there. The real rate of failure will be:

defects_found / (units_sold - (units_collecting_dust + units_unreported_dead + users_no_forum))

I suspect they currently only consider `defects_found / units_sold` and hence think failure rate is much lower than it actually is.

Honestly I think that the biggest problem here is a lack of focus. The PinePhone, PineTab, PineBook and most other products should be using the standard SOPINE compute modules. This eliminates tonnes of their problems and even creates a very clear product upgrade path.

They already have something that's almost a drop-in replacement for the Pi CM4 board, so in theory this means they could validate their designs against a known working design whilst still developing their own compute board. Why on earth you would try to solve all of these problems at the same time seems insane to me.

I blame the concept of expecting the community alone to entirely write the drivers for this hardware. I've been very, very patient, but I strongly believe that Pine needs to hire someone with a background in Linux driver development at least part-time to clean this mess up. (I'm tired of fixing other people's C, so don't look at me, at least right now)

I agree. The sort of kernel work going on here is enough work for _at least_ one person working full time. If there isn't the budget then charge more for the device. For example, at this point I have given up any kind of hope there will ever be H265 support on the A64, despite the silicon being there for it. A dedicated person would at least be able to direct community efforts in this space. We need the 'Torvalds' of Pine kernel development - not to single handedly solve every problem but to ensure quality and direction.

[acid andy]

I suppose I've had quite good luck with my XFCE desktop on Slarm64 but I swapped in the kernel and modules from Manjaro. I've not tried megi's kernels yet or compiling my own. I don't have a lot of time to keep testing different versions so when I find a working setup I don't mess with it too much.

I'm not seeing hard lockups every day like you're describing but that may be because most days my usage of the PinePhone is quite limited and repetitive. I also don't know whether the fact you're on 32 bit compared to my 64 is at all relevant.

It seems to me that developers have patched just enough of the most common issues that it works fine for custom touchscreen GUIs that do exactly one very specific thing (which I can't stand, I want a real desktop with a virtual keyboard and window manager), but the vast majority of not-so-uncommon edge cases are ignored completely, meaning that anyone running a normal, non-phone-oriented OS and GUI will constantly hit them.

Yeah, as I say, most days my PinePhone is indeed only doing a small number of very specific things - it's usually nothing more than a simple media consumption device for me to listen to a bit of music and occasionally browse the web (but normally just reading text - I fully expect watching videos to be like Russian roulette) and generally speaking these usage patterns just work (and on an XFCE desktop, usually with quite a few windows open and programs running).

I do get annoyances and glitches, like the tray on the bottom right of the XFCE taskbar regularly decides to just stop redrawing, making it very difficult to click on the Network Manager icon, but I'm not seeing daily Xorg segfaults or hard lockups really. That may be partly down to the fact that the battery life is so poor that it usually runs flat after a few hours of music or surfing meaning that's much more of an irritation than any very occasional lockup.

Once every week or two I do use it for calls, which works I'd say about 8 or 9 times out of 10. I agree the audio routing can be a bit crap. I wound up writing a script with a desktop shortcut "GIMME SOUND", which mutes and then unmutes all of the channels I need for a call, along with enabling the headphone output as well because that does no harm and is annoying when it goes off. As part of my ritual preparing for a call I tap that shortcut a few times until I hear a crackle of sound output from the earpiece, then I know it's working (you see there's a bug where sometimes even though alsamixer says a channel is enabled, it won't actually be audible unless I mute and then unmute it). After that, with eg25manager and the Calls app up and running, if I'm expecting an incoming call, I will religiously dial out to one of my network's free numbers to test that the modem is awake and the audio is working, then hang up again. I repeat that every so often and provided I do this arcane dance, do you know what - it more often than not actually works as a telephone! 

I should also say that's it's been great fun building various programs and games from source on the device and tinkering with the code to get them to work on Slackware and with the PinePhone's interface, or removing dependencies I don't like. For building code I have to say it's been rock solid. More often than not I've been pleasantly surprised what can be made to run on this device as well. I don't know about stability but I don't run the games for very long - the getting them working part is probably more fun actually.

As for the touchscreen, I can't really remember having issues with it very often in the recent past. When I'm using heavy programs it will often become unresponsive for some time but I blame that more on the desktop than the touchscreen driver. If I wait it will often eventually sort itself out, or when I used to have the XFCE power button functions enabled, pressing that to bring up the shutdown splash screen would make the touchscreen responsive again.

One thing at the moment that's guaranteed to need a reboot is if I accidentally send my PinePhone into deep sleep while something is playing audio through ALSA. For some reason when it wakes, the sound that was in the audio buffer loops eternally until I power off the phone. I must get around to coding something to shutdown ALSA or flush the buffer somehow before entering deep sleep.

So that's where I am. When the battery's not flat, I really enjoy having a tiny desktop Linux experience in my pocket. It's rough round the edges, sure, but my way of working is to find what works and what doesn't and if something doesn't work and I can't fix it after a few days of hacking, swap it out for a different package or program and use that instead. For example, I was previously using SDDM as my display manager but after I had to remove the fbturbo driver to get screen rotation working, SDDM would just stop with a flashing cursor and no usable diagnostic information. I gave up and built GDM for Slarm64. So, yes, some things crash, but for me, the crashes seem fairly predictable, so I learn patterns of behavior that step around them, because it's infinitely better than selling my soul to Andr*id.

It's now in a situation where I"m scared to copy 200MB to my PinePhone over SSH because there's a 60% chance it will hard-lockup in the middle of the transfer. (that wifi issue has been happening since I got the first PinePhone, by the way)

I normally don't even try. When I want to copy stuff onto it I tend to either plug in a memory stick to the Convergence adapter or pull the SD card and write directly to that from the other machine.

I blame the concept of expecting the community alone to entirely write the drivers for this hardware. I've been very, very patient, but I strongly believe that Pine needs to hire someone with a background in Linux driver development at least part-time to clean this mess up. (I'm tired of fixing other people's C, so don't look at me, at least right now)

Very much agreed.

---

I agree. The sort of kernel work going on here is enough work for _at least_ one person working full time. If there isn't the budget then charge more for the device. For example, at this point I have given up any kind of hope there will ever be H265 support on the A64, despite the silicon being there for it. A dedicated person would at least be able to direct community efforts in this space. We need the 'Torvalds' of Pine kernel development - not to single handedly solve every problem but to ensure quality and direction.

If Pine aren't willing to do that then the obvious alternative would be crowdfunding it. The two questions then are: one, can anyone be bothered to organize that, and two, is the community big enough (and generous and rich enough) to actually contribute enough money to pay for the work needed. I have my doubts, actually.

[barray]

If Pine aren't willing to do that then the obvious alternative would be crowdfunding it. The two questions then are: one, can anyone be bothered to organize that, and two, is the community big enough (and generous and rich enough) to actually contribute enough money to pay for the work needed. I have my doubts, actually.

I thought about this, but I think it still needs to come from Pine64. This person would need inside knowledge about upcoming projects, would need some kind of influence in the hardware decisions (i.e. go for this CPU because it has good kernel support). There is also the point that a person skilled enough to work on kernel development wants (and deserves) job stability.

To have such a developer should just be a case of adding a few dollars to each product. Given that everybody benefits from better kernels (no matter those chosen Linux distro), it seems like something everybody should contribute into.

[acid andy]

I thought about this, but I think it still needs to come from Pine64.

Ideally, yes, but that's not our decision to make. It's not the first time this idea has been brought up and I think Pine's current approach is pretty clear. I'll be pleasantly surprised if there's a change of approach though.

[Subsentient]

Ideally, yes, but that's not our decision to make. It's not the first time this idea has been brought up and I think Pine's current approach is pretty clear. I'll be pleasantly surprised if there's a change of approach though.

Indeed, they're not required to do this, but what I hope they eventually realize is that it's in their own self-interest to do so. The PinePhone already has a reputation in some places as too buggy to use as an actual phone. They'd get considerably more sales if the PinePhone was appealing to those who wanted to run Linux on their phone, but who were not willing to deal with the pandora's box of bugs in PinePhone drivers and userland support code. It's pretty easy to extrapolate that this demographic is much larger than the ones who will be tolerant like you and I have. Right now, the PinePhone is still not usable for basic functionality for many people, and it's been two years since I got mine.