And if they're choosing unsupported/unsupportable chips without doing the barest of legwork to get them functional (or hell, get docs public), then that's a huge problem.
Pine should be showing on their pages a hardware matrix showing what works and what doesn't. The Pinephone Pro doesn't qualify for the definition "phone".
If they were serious, they'd put this page up front, with a list of all the stuff that they imply works, but doesn't: https://wiki.pine64.org/wiki/PinePhone_Pro_Software_State
inb4 What works: You tell me!
Actually camera sensor was changed on request from Martijn. (or so I was told, when I was asked to add support for the cameras in the kernel)
"The PinePhone Pro Explorer Edition is aimed at Linux developers with an extensive knowledge of embedded systems and/or experience with mobile Linux"
To me thats pretty a pretty clear implication that many things may work poorly or not at all.
And, they call it a Pine *PHONE* Pro.
It can't even do the "Phone" thing.
And read up about the hardware critical failures that can destroy stuff when you plug in the wrong usb-c connection.
Yes, I expect a minimum functionality. You know, like NOT FRYING SHIT. They couldn't even manage to do that.
There's nothing wrong about Pinehnone Pro's Type-C port supporting circuitry. It's pretty much a reference design this time.
I'm actually on board, but do note that that's going to be a chart full of subnotes and caveats - things like "camera produces an slightly red-shifted but passable image on default software shipped from factory, red-shift is fixed with kernel 5.19-patch-foo but that breaks focus, Mobian ships that kernel with a userspace correction filter that fixes it in the latest nightlies[...]". You'll end up with a small table that's 90% little yellow "works with caveats" boxes and then several pages describing the caveats and various working and shades-of-working configurations. Oh, and it'll need to be timestamped and constantly updated (as in "major bugs fixed, and sometimes added, on a weekly basis")
In short, summarizing active development is never going to be simple.
One day I’ll probably end up with a Linux phone, but I mean, not if I’m worried I’ll get surprised when it arrives
My $200 pinephone can, on a good day, do 0.5hz. I dunno, but I expected more.
That's not a $200 proposition, though. :)
And I guess there's no huge motivation, given the expected quality of the resulting image. Maybe someone will write it for some other similar AW SoC that uses the same HW block.
Such is the power of FOSS.
I used to be all for early adoption, but too many people ran off with my money via Kickstarter and Steam Early Access.
edit- add phase x2 =p
It can make phone calls.
It took a separate $31,000 kickstarter and 4 years of a multi-vendor cooperation to create and upstream then non-existent accelerated stateless video decoding API for Linux. Pine64 would have never released anything if they waited on Linux API standardization process (have multiple users of the API in kernel, etc.). And even after 2 years of availability, the only major user of the API is gstreamer, and it's still bubbling through the stack so that you can just open Firefox and play an accelerated video.
Pushing through this process even nicher accelerated encoding feature, usable pretty much only for the cameras (which are quite crappy on the OG pinephone, so motivation is already low, there), is just not going to happen for giving someone a 7 year old outdated phone worth $150 only to some enthusiasts and $0 to pretty much everyone else, lol. That's just ridiculous.
I’d expect my PinePhone to come with software too. I mean, I guess it did, I think I just expected more from the open source community than from the nameless fly-by-night vendor.
Software takes time. But their plan is "cobble shit together in an untested and unmaintained state and YOLO".