Qualcomm hardware support increasingly in good shape with Linux kernel
phoronix.com
phoronix.com
I can't really say if it's due to better features, price, vendor support, open source support, documentation, or perhaps all of the above. In any case, some competition is certainly welcome.
9/10 times the turned-down requests for OpenWrt support of Device XY are because of Broadcom SOCs/Wireless_chips in the device.
> But still a work-in-progress is audio support, DP Alt-Mode, enabling the DSPs, USB-C power delivery, and GPU acceleration
No GPU acceleration? And somehow this is seen as good support?! The reverse engineered Asahi Linux driver has better support than whatever this is.
Qualcomm historically wrote awful OSS code that couldn't be upstreamed because it barely worked on a subset of their own SoCs, and broke basic function for everything else. Typically featuring incredibly invasive architectural changes that patched far too many layers of the OS with unmaintainable code.
QC then converted bad code into a business model, nickel and diming OEMs who needed bugs fixed to ship their products.
The idea that QC SoCs now have good upstream support is bizarre to me. At best, it means a few high volume SoCs can boot to console on reference designs. Forget about peripheral support for things anyone would take for granted, like audio and GPU.
A great start would be to make the user space Adreno GLES libraries talk to the freedreno DRM backend. So one could use the QC proprietary GLES libs with a mainline kernel without rebuilding with KGSL.
There's a similar story here for every subsystem driver, where they insist on a brittle proprietary solutions (one branch for every chip!) that can't be upstreamed.
QC is not a low level employee lacking agency over their job description. They're a business that is free to set their strategy in response to risk and competition.
The less that QC upstreams, the more risk they incur, especially with tightening security scrutiny (e.g. 2021 Cyber EO requirements).
QC can also get disrupted by Mediatek doing a better job with Linux.
It should be if they're really serious about software support.
Imagine just walking around with one normal phone and one phone that you can hook to with xreal glasses, connect that phone to a remote server and you got yourself all the power you want in your hands (provided you have good Internet).
Thanks for the suggestions though!
Hope you don't mind me firing a bunch of questions
Do you use it as "just" a smartphone or as a laptop substitute?
And how much screen on time do you get?
How long does it take to charge?
Have you tried using steam link?
What OS/ROM/disto do you have installed on it?
I tried to use it as a laptop. It works fine for non-heavy tasks, but not sufficiently secure for me (I prefer Qubes OS). It is very helpful for doing some configuration though. See also: https://forums.puri.sm/t/anyone-using-the-l5-as-their-main-c...
I get maybe 3-4 hours of heavy browsing. Usually, when I'm using the phone a lot, it lasts half a day. Also, the background apps are not frozen like on Android/iOS and can drain the battery very quickly if you don't close them. The good news is that you can replace the battery without tools and instantly get 100% charge again.
It can charge in about three hours with the original charger, but I often use other chargers, which are slower (e.g., it can take 6 hours or more during the night). See also: https://forums.puri.sm/t/usb-dcp-5v-1-5a-protocol-and-librem...
I didn't try steam link. I tried to install Mobian. It works but the functionality lags (https://news.ycombinator.com/item?id=39155229) behind the default PureOS, which I use. The software is still under heavy development and the phone is still getting longer battery life and smoother UI.
See also: https://forums.puri.sm/t/librem-5-daily-driven-in-profession..., https://forums.puri.sm/t/librem-5-daily-driven-in-profession....
No swappable battery, but the efficient cpu, more ram and faster recharge makes it more worth it for me.
Thanks again!
I'm probably going to buy a raspberry pi 5 or equivalent, slap a 2x12000mah battery and 5" oled touch screen on it, build an case around that and call it a day. It's going to be pocketable, it's going to have a lot more battery life and a lot cheaper.
As for my phone, I'll probably get a pinephone or librem equivalent once there's one I can actively use for about a normal working day without having to replace the battery or experience slowdowns.
Thanks for all the info on this thread!
It's so interesting to me to guess how and where this is happening, what the pressure points are driving this. It feels like there's two areas that have been highly motivated to make Qualcomm more than good for limited-lifetime appliances running unmaintained kernel.
First around were the motivated hobbyists, namely, OpenWRT. OpenWRT already had a close relationship with part of Qualcomm: the Atheros (acquired by Qualcomm in 2011 for $3.1B) wifi chipsets were the linux wifi chips to have. But as MIPS faded and ARM rose, Qualcomm become more and more dominant in OpenWRT space. Trying to port vendor SDKs and drivers in, and then work on more upstream support, has been a long running OpenWRT project. I myself own a number of Nighthawk X4S/R7800 (IPQ4019 chipset, 802.11ac wave-2) routers (Maybe soon time to move on, if only there were good options!).
Those efforts to upstream are really getting to a good spot these past couple years. ipq40xx was ok but rough. After some kind of iffy early chip releases that seem destined to never be supported, most recent ipq80xx chipsets with 802.11ax/wifi6 seem well supported on mainline. But it's still not ideal: Qualcomm has a bunch of iptables-bypassing network-processing offloading support for the +2 of it's 4+2 cores, that is unlikely for OpenWRT to ever support (https://forum.openwrt.org/t/xiaomi-ax3600-performance-thread...). Especially as wifi speeds tick higher it's unlikely new routers will be able to go fast enough unless there's some breakthrough in network-offload, and with great solutions like VPP about it's not impossible, but it seems unlikely & requiring quite a heroic feat to even get started reverse engineering & beginning the process. (Personally it makes me just want to use x86 based routers with m.2 cards for APs & skip Qualcomm cpus.)
The other prong of upstreaming comes from a very different place: Google. Specifically Chromebooks, which have really pushed hard for support to get upstreamed on supported platforms. I think it might now be an out and out requirement to have upstream support! This added real weight to the drive to upstream. We also see MediaTek having done amazing things with getting their stuff upstreamed, often seeing chips consumers wont see for years getting kernel support, with many of the target boards becoming future Chromebooks. Chips like the 8cx were pretty early onboard here.
The chip here is more phone oriented, a Snapdragon Gen 3. Things seemed to really start going much faster a year or two back. Looking at PostmarketOS, the support matrix really isn't bad for mainline kernels and top-tier chips (https://wiki.postmarketos.org/wiki/Qualcomm_mainline_porting)! I'd love to see support expanded for lower-market chips (such as the 7+ Gen 2, https://www.anandtech.com/show/18775/qualcomm-announces-snap...), which looks like it'd be a great mid-range tablet/small desktop core, if supported.
It's still quite hazy to me how much Qualcomm is actually supporting/helping these efforts, versus how much is paid or free open source work. But, the future is exciting. Being able to run non-Android OSes really starts here. I don't know what specifically the changes will be, but able to have devices evolve & change beyond just being consumer appliances opens the doors of possibility, to new forms of computing. Letting folks adapt & change systems around them keeps giving rise to exciting new things, and I'm for it!
There is also the whole interesting disconnect where they employ one or two cranky old timers to maintain the upstream ath drivers, then have the usual Indian teams write untested rushed upstream "support" patch series for the routing WiFi chips. The old timers don't want to test them because they believe their job is in the tiny and shrinking Qualcomm laptop WiFi market and the Indian teams don't test by doctrine and superior orders. And this is for the Qualcomm-on-Qualcomm case; they fare much worse trying to submit patch series for all the other bits and pieces you need to make the Qualcomm SOC work that invariably comes with the routing WiFi chips.
On the one hand, we might actually be able to upgrade kernels! Neat, overdue, necessary. S24 has 7 years of updates! Why & what changed? Well, there's decent upstream support. Ok, so they can keep the computer running. But the phone is basically a whole second system, and GKI promise to let them keep the phone parts running along as is, while the computer part changes. This is cool.
I'm a bit scared though too. We're opening a pandora's box where a good portion of the computer's drivers are no longer running on Linux. How many of the upstreaming efforts that are now underway will be undermined by folks running vendor blobs against the stable & closed Google Kernel Interface, instead of the changing & GPL Linux Kernel Interface? GKI seems like an insane threat to mainstream winning; it's a totally parallel constructed world designed to avoid the need to mainstream, and that's basically a horror.
I'd love to see a Google Kernel Interface run on a non-Android device. If I can run a Debian phone & have all the fancy bits and bobs work, I won't feel so bad about GKI. But it feels like GKI is custom-bred for Android specifically, and that Google is pulling off the mother of all Embrace, Extend, and Extinguishes against Linux, is finally going to subvert & dethrone the Linux kernel by wrapping it & making everyone target that (& have the wrapper be ultra-coupled to Android).
> If I can run a Debian phone & have all the fancy bits and bobs work, I won't feel so bad about GKI.
You can try Droidian, it's a Mobian fork configured to run as a GSI. You'll be running proprietary kernel modules and relying on Android's low-level layers (which is a somewhat unstable arrangement, since we don't know how these may change in future devices) but at least the system level and UX will be a plain Linux userspace.
I agree, the distance between Android and mainline has been shrinking and that's wonderful to see. Agreed again, no one has been upstreaming a good amount of their work; that's the state of the world. I'm not totally willing to absolve Google of all fault/responsibility here, but I understand-ish. I'm still not sure though that GKI doesn't let us backslide, doesn't let folks do even more closed, doesn't reverse some of our gains.
As for Droidian & the ilk; I'm happy these exist. At the risk of once more going over the top though: I feel very differently about running my own Linux userland hoisted far atop a tower of controlled, locked-down platform I don't have access to, than I do having actual access to devices. It's wild how not our own our devices are. Maybe I can run a userland, but if I cant coordinate bluetooth devices and audio and display outputs myself, it's not really a good userland. And if Google SafetyNet is underfoot controlling my most personal machine forever, well, that's a sad shitty anti-user feature the future is being consigned to.
If there is one entity that could have changed this years ago, it was Google, especially after Microsoft ditched Windows Phone.
Look, I'm no friend of big corporations strong-arming their will around, but in this case it might have been good for once. Instead, you get a hellscape of Samsung messing around deep in Android Core (as everyone who wants to develop a long-running background app is likely to hit), and rooting being an extremely painful process that will brick about half the apps on your phone.
What do you mean by this? Device drivers are still running on Linux.
>How many of the upstreaming efforts that are now underway will be undermined by folks running vendor blobs against the stable & closed Google Kernel Interface
Keep in mind that the KMI (kernel module interface) is only stable within the same LTS release. When upgrading to the next LTS there can be breakages since Linux still hasn't made a stable API for out of tree developers to use.
>instead of the changing & GPL Linux Kernel Interface
The interface is the same normal interface as any other kernel modules. It's up to the kernel module's developers if they wish to use GPL exported symbols or not.
>GKI seems like an insane threat to mainstream winning
I see it as being mostly neutral as it's goal is for being able to deliver security updates to phones by just swapping out the kernel. It's slightly beneficial in the sense that the code for the initial startup of the system has to be upstreamed since the kernel has to be able to boot far enough to get to the point where it can load vendor kernel modules.
>it's a totally parallel constructed world designed to avoid the need to mainstream
The world where there is code that can not be upstreamed already exists. GKI is about cleaning up the boundary of where upstream code lives and where third party code lives making each piece more modular.
>I'd love to see a Google Kernel Interface run on a non-Android device
As mentioned by a sibling GKI stands for Google Kernel Image and you could run it on a non Android device if you wish as it's open source including information like what version of the compiler should be used.
>& have the wrapper be ultra-coupled to Android
There is no wrapper here. There are a few additional patches to the kernel that add some hooks for vendor kernel modules to use, but kernel modules do not have to go through a wrapper.