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.
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.
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.
Very much agreed.
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'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.
(12-28-2021, 07:38 PM)Subsentient Wrote: 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.
(12-28-2021, 07:38 PM)Subsentient Wrote: 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.
(12-28-2021, 07:38 PM)Subsentient Wrote: 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.
(12-29-2021, 01:28 AM)barray Wrote: 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.
