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