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