That means you want work done in Mesa so that the GPU in question is better supported than it currently is.
But you also want Firefox's Webrender changed to allow using the GPU in question under Linux, by default. Otherwise the browsing experience is laggy as hell for everything other than HN. That means lots of testing in Firefox, and somehow convincing them not to blacklist your GPU under Linux. (Which I'm guessing takes time since changes in Mesa don't hit every major distro all at once.)
And you also need video acceleration to work out of the box. Otherwise you're going to be trying various flag combos just to get your phone from getting hot while watching a video. And then your browsing experience probably gets laggy again.
And then you're going to need to rinse and repeat that entire process to get the baseband to work with nearly any carrier, at least in the U.S. They probably aren't going to support using that baseband on something that isn't an android phone. You'll need some reliable way around that. Is this an open research question? I don't know.
Once you have those done, try to figure out why playing music to a bluetooth speaker over this device sometimes changes the pitch of the audio! Oops, another unexpected rabbit hole.
I declare by fiat all of the above problems have been solved.
Oh no, I forgot about battery life.
Now I've got a summer project to figure out why suspend sometimes-- but not always-- freezes my phone.
After that I need to figure out the signal path between baseband and Linux to figure out why getting a call sometimes-- but not always-- wakes the phone so it rings reliably.
These are all hard things. The idea that motivated rando open source devs can roll up their sleeves and solve phone usability is laughable.
A lot of these kinds of problems go away with vertical integration and limited scope. E.g. if you only want to make phone calls and send SMS (or the internet application of your choice) so you can call it a phone, it's not terrible. You can write that. When you want to run a massive black box like Firefox on top of another massive black box like a proprietary GPU, it is terrible.
None, but the point is that trying to make a dumbphone, using Linux as an ingredient, allows each part of the product to be very specific about the other parts, whereas trying to add general phone support to Linux (say, if you plug in a USB modem) will require either a lowest common denominator or an inconsistent experience, and will have abstraction layers in the middle making the software much harder to develop. Consider that the SMS app for My Linux Dumbphone can open /dev/ttyUSB5 and send AT commands, and the experience as a whole is tested and edited by one person until it works well, while the one for KDE has to use some KDE API which either adapts to KDE Connect (which has to follow an already-designed protocol) or to a Linux kernel API which is implemented by a lowest-effort driver.
Comments
The word just is doing a lot of work here.
E.g., you want graphics acceleration.
That means you want work done in Mesa so that the GPU in question is better supported than it currently is.
But you also want Firefox's Webrender changed to allow using the GPU in question under Linux, by default. Otherwise the browsing experience is laggy as hell for everything other than HN. That means lots of testing in Firefox, and somehow convincing them not to blacklist your GPU under Linux. (Which I'm guessing takes time since changes in Mesa don't hit every major distro all at once.)
And you also need video acceleration to work out of the box. Otherwise you're going to be trying various flag combos just to get your phone from getting hot while watching a video. And then your browsing experience probably gets laggy again.
And then you're going to need to rinse and repeat that entire process to get the baseband to work with nearly any carrier, at least in the U.S. They probably aren't going to support using that baseband on something that isn't an android phone. You'll need some reliable way around that. Is this an open research question? I don't know.
Once you have those done, try to figure out why playing music to a bluetooth speaker over this device sometimes changes the pitch of the audio! Oops, another unexpected rabbit hole.
I declare by fiat all of the above problems have been solved.
Oh no, I forgot about battery life.
Now I've got a summer project to figure out why suspend sometimes-- but not always-- freezes my phone.
After that I need to figure out the signal path between baseband and Linux to figure out why getting a call sometimes-- but not always-- wakes the phone so it rings reliably.
These are all hard things. The idea that motivated rando open source devs can roll up their sleeves and solve phone usability is laughable.
A lot of these kinds of problems go away with vertical integration and limited scope. E.g. if you only want to make phone calls and send SMS (or the internet application of your choice) so you can call it a phone, it's not terrible. You can write that. When you want to run a massive black box like Firefox on top of another massive black box like a proprietary GPU, it is terrible.
What Linux device works with a modern baseband OS out-of-the-box with, say, Verizon or AT&T?
I think it's just as terrible as Firefox/Mesa/Proprietary GPU-- e.g., jumping on forums, pentesting magic messages to the Baseband OS, etc.
None, but the point is that trying to make a dumbphone, using Linux as an ingredient, allows each part of the product to be very specific about the other parts, whereas trying to add general phone support to Linux (say, if you plug in a USB modem) will require either a lowest common denominator or an inconsistent experience, and will have abstraction layers in the middle making the software much harder to develop. Consider that the SMS app for My Linux Dumbphone can open /dev/ttyUSB5 and send AT commands, and the experience as a whole is tested and edited by one person until it works well, while the one for KDE has to use some KDE API which either adapts to KDE Connect (which has to follow an already-designed protocol) or to a Linux kernel API which is implemented by a lowest-effort driver.
I find it always does, especially when people are talking about software.