[noasaservice]

Admittedly, that's doubly concerning. Pine chooses the BoM; we don't.

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

[MartijnBraam]

There is not really any good options for the sensors, it's all a few closed developers.

[ocdtrekkie]

Martijn, I want to really give you some credit for these responses: It's rare to see someone who will step in and defend bad takes against the party they are also taking issue with.

[bombcar]

Agreed, for someone who is watching from the sidelines it lends a lot of credence to Martijn.

[yjftsjthsd-h]

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

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.

[hertzrat]

If it’s no, but has a dozen asterisks, to the end user, that’s still a “no, this component does not work properly.” The footnotes can be 5 pages long but the chart is still straightforward

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

[ac29]

In the store right above the add to cart button it says:

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

[noasaservice]

That indicates that hackers can do shit to get it to work.

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.

[seba_dos1]

What's up with those "can't even do the phone thing"? It's not 2007 anymore, GNU/Linux phones can do phone calls, and PinePhones aren't different.

[megous]

Not sure what you'd have to plug to Pinephone Pro to destroy anything. Maybe a badly broken charger or a dirty plug.

There's nothing wrong about Pinehnone Pro's Type-C port supporting circuitry. It's pretty much a reference design this time.

[zozbot234]

> should be showing on their pages a hardware matrix showing what works and what doesn't.

inb4 What works: You tell me!

[megous]

> Admittedly, that's doubly concerning. Pine chooses the BoM; we don't.

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)

[MartijnBraam]

Rear sensor was chosen as a balance of kernel code available and picture quality, I had some influence there, front sensor was originally the ov5640 but that just got replaced due to availability.