Qualcomm could REALLY stop this at any moment by just relaxing the licensing, and pushing their own open drivers.
Like the Epstein Files and Trump, there really seems to be something inherent to the platform they don't want people knowing about.
this post was submitted on 21 Nov 2025
76 points (100.0% liked)
Linux
10229 readers
735 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
I know nothing about what it takes to develop a laptop. Are these issues (BIOS updates, virtualization support, USB4 support, etc) something the laptop manufacturer needs to develop solutions for in-house? Wouldn't that be the job of Qualcomm? Or are Tuxedo saying that these things aren't supported on the Linux side yet? Qualcomm claimed to be contributing to the kernel last year, so idk if that just hasn't happened yet or if they just lied.
Either way this is disappointing, but understandable. There's no sense in working to release a laptop with previous-gen hardware that's not going to be competitive.
My understanding is that most of this is down to ARM's (relative) lack of standardization. Consumer ARM SoCs don't even have ACPI, so you aren't even guaranteed to be able to do things like powering off the system. Qualcomm pretty much has to add some minimum support for their SoCs to the kernel because most of their consumers will want to get Android working on them, but that doesn't mean they'll do more than they have to for that.
There's a reason you can install Linux on any x86 PC and it will mostly work, but you can't install an ARM Linux on a phone. Even Android forks like Lineage don't support all Android phones, even though they're shipping basically the same thing the manufacturers are.
definitely. Qualcomm provides the SoC and drivers for what comes on that package, but you’ll want to add a battery controller, power controls, and other embedded systems onto the motherboard to make it act like a real system. it’s also a way different boot process in my experience than a normal x86 platform. the difference between ARM and x86 isn’t just the instruction set. plus at this level nothing is ever plug and play.
as for how Valve was able to ship an ARM device, they stuck to the normal kinds of IO a mobile device with a SD8gen3 would have and already have a great OS for fast iteration that they have tight controls over.
i’m excited for this XElite line, but i can see how it’s not in Qualcomm’s best interest to spend their engineering labor on porting to desktop Linux, not with Microsoft and Dell etc already having bids on that time. as long as Qualcomm is upstreaming and not actively blocking open source development, i don’t understand the kind of resentment i see for them. because they work with Google? i see them becoming more open as they become more prolific outside of embedded systems and Android. i see it as an exposure problem.
Mmmmh, this does not seem to bode well for the RISC V laptop they were also working on, iirc ...
How did Valve do it? 🤔
The same way smartphones do?
Well they have a lot more resources for sure.
Yeah but how? A lot of their stuff is open source so I wonder if it could be adapted...?
Well, they run the biggest(?) game store on the planet, so they probably have more money to throw at problems than a tiny hardware manufacturer from Germany.
LOL that doesn't answer how!
I still don't understand what you're asking lol
They were wondering the technical approach not logistical.
Obviously the logistics are "more money" but given that much about steam is devices is open, they were wondering what technical approach may have been taken, and whether it might be open and possible to piggyback off of.
What were specific compatibility patches for the kernel, I guess, but I am also not sure