TUXEDO scraps its Linux-based Snapdragon X Elite laptop — says the SoC "proved to be less suitable for Linux than expected"
Posted by ZacB_@reddit | linux | View on Reddit | 118 comments
cpt_emco@reddit
Not blaming Tuxedo, as these are not trivial problems, but I'm still hopeful, given what Valve has been up to. So maybe with some more time and the X2?
gmes78@reddit
The issue with ARM is that everything is device-specific. Whatever drivers Valve works on for their VR headset will not benefit Linux ARM users as a whole.
flecom@reddit
I've been saying this for years whenever someone talks about how great ARM is, until there is an ARM UEFI every arm device is basically just ewaste
Liarus_@reddit
i didn't know all of this, I'm glad i know now
Fr0gm4n@reddit
There is, but it's for servers under the ARM SBBR spec.
https://developer.arm.com/Architectures/Unified%20Extensible%20Firmware%20Interface
flecom@reddit
ok an ARM UEFI for regular devices mortals would use, SBCs, phones, laptops, etc
HexagonWin@reddit
all recent qcom devices use uefi afaik
idontchooseanid@reddit
You can run UEFI on SBCs using tianocore. However they are rather hacky. But don't expect anything like x86. It was an honest mistake from IBM. A non-standard working group was allowed to do actual good consumer development at IBM. Normal divisions of IBM hated it.
cluberti@reddit
Admittedly Microsoft makes their UEFI available as open source (Project MU) which can be made to run on just about anything, but as others have said there are still device-specific things that have to be added on ARM SoCs to make boot work and as such any build is tied to the platform it was built for and needs to be tweaked for each SoC variant. There are forks of this already built out for a bunch of AARCH platforms, for what it's worth.
leaflock7@reddit
that is up to the vendors to work together on a standard rather than ARM missing something
eestionreddit@reddit
Valve is using a Snapdragon 8 Gen 3 in the Frame. At least some of what they're doing should also help with the more laptop oriented chips.
gmes78@reddit
As it stands, each laptop still needs its own device tree. You can't just drop Linux on any Snapdragon 8 Gen 3 and expect it to work.
LvS@reddit
But you can use the drivers that exist once you've plonked in the device tree.
idontchooseanid@reddit
Do they guarantee that they are going to port into mainline kernel and opensource userspace drivers (e.g. Mesa Freedreno) ? Otherwise it is very unlikely to get fully opensource stack with Qualcomm.
LvS@reddit
That's so far what I've seen them doing at least.
No idea about guarantees they give, but the people working for them contribute quite a bit to freedreno.
nroach44@reddit
That assumes that
a) Valve's drivers use DT b) The laptop you're using uses (and has a non-broken) DT c) The peripherals in the DT communicate over interfaces supported by the DT drivers
a&b - for example, many old Tegra2~ish tablets don't use DeviceTree, they instead hard-coded hardware information in the kernel code directly.
c - The Cisco ASA 5505 uses a switch chip that's supported by the Linux kernel, but it's connected over I2C, not MDIO (which the kernel knows how to support). So you'll have to figure out how to adapt the MDIO driver to talk over I2C, or write your own driver / tool.
donald_314@reddit
Do/will they exist in other form but a device specific binary blob?
Zettinator@reddit
On servers UEFI and ACPI are quite typical on ARM systems. We have yet to see this on SBCs, laptops, etc.
NimrodvanHall@reddit
Will RISC V have this same issue as ARM?
vaynefox@reddit
The problem with RISC-V is that SOC manufacturers cant get their shit together and come up with a common standard to make it easy to support on software side, so it's pretty much wild west. Each manufacturers has their own instruction sets that arent compatible with one another making it a nightmare to build low level softwares on it (e.g open source drivers, generic drivers)....
nroach44@reddit
Yes.
Basically any device that's not a "Standard Platform" (e.g. UEFI x86 "PC") leaves identifying the hardware entirely up to the OS.
In the past, PowerPC Macs and Sun SPARC systems had OpenFirmware, which created a "Device Tree" data structure describing the system to the OS.
The current state of play on ARM, MIPS, RISC-V etc. is using DeviceTree, but instead of it being discovered and generated by the firmware, it's usually loaded off the boot disk by the bootloader.
This nearly completely negates the entire reason for DT, as now your OS vendor has to know the layout of your hardware.
WarEagleGo@reddit
hehe
:)
idontchooseanid@reddit
Yep. Basically any system except x86 are proprietary as hell. Even x86 is proprietary as hell, if you keep looking for the internals.
RISC-V being open source benefits the chipmakers. There are no direct benefits to regular consumers. The open nature of RISC-V can also be worse since there are little standardization of a "good desktop PC featureset" (there is G extension but no guarantee of implementation). There is no enforcement to implement full feature sets. So would be hardware sphere will be hell to navigate as a consumer. If you think modern USB is bad, RISC-V will be 10x worse.
Moreover most of the proprietary crap doesn't come from the ISA or the CPU cores but proprietary peripherals. There is absolutely no standard to creating SoCs with various peripherals. Every single manufacturer does their own thing. It is totally unrelated to ARM vs RISC-V vs x86.
Most of the x86 chips just carry the IBM PC legacy and implement nice peripheral protocols like PCIe. However, most (if not all) current Intel laptops don't / won't have 100% driver coverage under Linux. Many of the core hardware works due to PCIe. This doesn't mean that there are Linux drivers for every single small accelerator, DSP chip, or position sensor that's installed on an SPI bus is supported under Linux or well-tested. Only Windows has 100% coverage.
gmes78@reddit
It seems like RISC-V has ACPI support.
Vogtinator@reddit
So does Arm, to basically the same extent.
nightblackdragon@reddit
ACPI won't solve these issues. What we need is something akin to standard chipset like on x86.
Great-TeacherOnizuka@reddit
And it took them years to realize that?
LordAlfredo@reddit
It's not just realization, it's more likely for each issue they tried one approach, failed, iterated, failed, kept iterating, tried a different solution, ran into different problems, and have now finally concluded they're making headway so slowly that by the time it's viable it will be obsolete.
dumbestbeaver@reddit
The coding ability at Valve >>>>> a random hardware retailer
WolfeheartGames@reddit
Valve doesn't hire developers. The entire team on cs2 was like 10 guys and some artists.
Storyshift-Chara-ewe@reddit
Valve heavily funds KDE and basically hired the creator of dxvk to maintain it and update it
starm4nn@reddit
Valve's strategy has pretty much been:
Find someone who does the thing you're interested in for free
Give them money in exchange for adding features you want
Storyshift-Chara-ewe@reddit
I can't complain tho, Plasma has become the best Linux desktop and dxvk is so good it's basically just a component you can add to windows games (even on windows) and get good results and also deprecating gallium nine
Scheeseman99@reddit
Valve heavily contract outside workers to work on Linux stuff eg. Techpaladin.
SquareWheel@reddit
And just recently, Igalia. Valve has spent a lot on contractors to solve these problems for them.
insanemal@reddit
I don't see any issues with that. They are spending money on experts.
This is an all round win
FalseRelease4@reddit
Tuxedo isn't a random online store selling something like Dell laptops with their own logo on it, they do a lot more than that
Zettinator@reddit
Qualcomm has promised regular UEFI and ACPI for the X2, let's see if that works out (and works well in practice). With this it should have a chance of competing with x86.
nightblackdragon@reddit
Regular UEFI and ACPI is not going to solve poor Qualcomm Linux support.
Zettinator@reddit
Sure. But it would be an important stepping stone. Without getting these basics right, I don't think there's a realistic chance that things will eventually work out.
sartres_@reddit
Qualcomm promises a lot of things. When the XE1 came out, they said
and
This was in May 2024. Most of that is still kind of broken, a year and a half later.
RoomyRoots@reddit
ARM is just a bad ecosystem. Depending on the good will of the manufacturers is too risky and effort.
jimicus@reddit
x86 is the outlier.
Virtually every other hardware ecosystem has historically had at least a certain amount of vendor lockin. x86 is very unusual in having a reliable, reasonably open ecosystem and a consistent way to enumerate the hardware installed.
ARM are starting to head in that direction, but it's by no means a requirement for someone implementing an ARM design.
MrScotchyScotch@reddit
One company made a simple platform, everyone made clones that were 10x cheaper, everyone bought the clones, the clones stayed compatible so people had a reason to buy them
KnowZeroX@reddit
I think the issue stems that x86 is the standard in servers, and with servers companies want full control of their hardware.
ARM on the otherhand use has mostly been in locked down embedded systems. Even if there are now some ARM servers, these days most people don't care as much about the underlying hardware due to the cloud.
We can only hope on RISV but I fear it'll take decades to be viable.
jimicus@reddit
While they're not the behemoths they once were, it wasn't too long ago you could choose between POWER, PA-RISC, Itanium, SPARC and more besides.
x86 became the standard because of price - Linux pretty much killed commercial Unix, which most of these platforms were purchased for, and the x86 server world has long treated Linux as a first-class citizen.
If Torvalds was just five or ten years older, Linux couldn't have happened in the same way. The home computer world was much more fragmented in terms of hardware platforms, and the platforms available lacked many of the hardware features necessary for even a fairly rudimentary Unix-like OS.
alrs@reddit
Linux has run on all kinds of architectures essentially forever. That Power, SPARC, PA-RISC, Alpha, MIPS, and m68k all dropped the ball is the fault of their respective owners, not Linux.
If Torvalds was older he could have bought a Tandy 6000 and just run Xenix. A 386 was not a cheap computer in 1990.
idontchooseanid@reddit
If Torvalds wasn't at the right place at the right time, the predominant open source Unix would probably be a BSD or OpenSolaris. GPL and GNU could be also forced into obscurity.
mailslot@reddit
Intel was instrumental in the death of PA-RISC, MIPS, and Alpha.
idontchooseanid@reddit
x86 got standard interfaces way before Intel started selling to server ecosystem. It's not just Intel but IBM's decision to use off-the-shelf components and PC clone industry developing around. Since the components of the clones were also off-the-shelf Intel was forced to standardize. They didn't do it out of the goodness in their hearts. It was an enabler business strategy to onboard as many clone manufacturers as possible.
DesiOtaku@reddit
Ironically, I would love to get an x86 based phone that can run something like (K)Ubuntu out of the box. I already have a Librem 5 but it is still not trivial to install a different OS or at the very least boot an OS from the USB.
mailslot@reddit
A slow phone with two hours of battery? Sign me up!
DesiOtaku@reddit
Yeah, Atom was pretty bad back in the day but I think AMD's current APUs are pretty good; even for a mobile form factor. I am sure something like the Mendocino would probably be fine. Combine that with Plasma Mobile and now you got a pretty response system.
nukem996@reddit
ARM manufacturers view driver support as throw away code. It's ugly and buggy but works well enough to get a product out. They have 0 interest in creating maintainable code that is upstream able. They insist you get driver support from them but only support 1 or 2 kernel versions before marking the hardware deprecated.
Avamander@reddit
Don't forget the NDAs lurking on every corner if you want the source not just the blobs.
jimicus@reddit
NDAs for source code that has cannot possibly function without being compiled as a kernel module and use GPL'd interfaces. The embedded world is chock-full of such examples - code that simply cannot exist without being a GPL violation.
CrazyKilla15@reddit
Almost none of it is actually GPL violation, and if it was it would destroy free software entirely. Thats no exaggeration, a US court ruling that linking interfaces, ABIs, are copyrightable means that, for example, wine is dead, because it implements the proprietary and newly subject to copyright windows ABI interface and can replace the proprietary windows libraries, violating the proprietary licenses. It would also reverse Google vs Oracle in all but name because what use is being allowed to use an API in source code, but it being a violation when you build a binary? Is LD_PRELOAD making a derivative whenever you run it because of linking?
Its also already meaningless in the EU because they declare that interfaces necessary for interoperation are not copyrightable in the first place in Directive EC 2009/24 recitals 10 & 15
I know you probably dont really care I just really believe the position linking inherently on its own makes a derivative is so incredibly harmful to Free Software and the new legal force would almost exclusively help further entrench proprietary code and prevent Free drop-in replacements from existing, and I think it is Good, Actually if some proprietary software that for one reason or another cant be avoided can have its proprietary guts replaced. I think its harmful even with a "Only use full free software and nothing else" world-view
PsyOmega@reddit
The claim that enforcing GPL conditions on linking would somehow wreck Free Software ignores that the GPL is precisely what keeps corporate enclosure at bay, because treating linking as outside the license lets proprietary vendors siphon community labor without giving anything back, while real Free ecosystems thrive when copyleft ensures reciprocity, and far from killing compatibility projects like Wine strong copyleft simply requires that replacements remain Free rather than allowing closed guts to hide inside a supposedly open stack, and Google vs Oracle is irrelevant because APIs and ABI boundaries are different legal questions, and protecting GPL linkage rules does not outlaw reimplementation, it only stops companies from bolting nonfree modules onto Free cores and calling the result open, and even EU interoperability rules do not forbid copyleft since they only guarantee the right to reimplement behavior which the GPL already respects, and the harmful outcome is actually the opposite since weakening GPL linking lets proprietary blobs become permanent dependencies that choke out Free dropin replacements and shrink the commons, which is why defending strong GPL linkage is essential for long term software freedom even if some projects must adapt or refactor to remain truly Free.
CrazyKilla15@reddit
The GPL is valuable outside of its nonsensical, legally unenforcable, legally unenforced(nobody is suing over this! nobody is even particularly trying to stop it socially! When did you last see anybody saying NVIDIA drivers shouldnt exist?), and legally cannot be enforced in the EU.
The idea that the GPLs linking argument is doing much of anything is ridiculous.
Analog_Account@reddit
Ewwwwwww...
So disappointing really.
jimicus@reddit
There's been a dirty little secret in the embedded world for many years, which is that most of the manufacturers don't give a fuck about the GPL.
Why do I say that?
Simple. The companies producing the hardware platform for OEMs (usually) provide driver code for OEMs and they almost invariably require an NDA.
As a result, the source code for those drivers never sees the light of day - even though it does things that simply aren't possible without at the very least being a kernel module, and potentially compiled directly into the kernel.
klipz77@reddit
This is the number one problem I have with ARM, closely followed by random boot shenanigans (shims, closed source ram training, etc) required for various vendors.
I’ve been having lots of fun with some rk3588 based soc’s but that’s only because Collabora has spent the last two years reverse engineering the entire chip and upstreaming drivers….
LoafyLemon@reddit
Chromebooks can do that just fine. The recent ARM chips work great and have stupidly long battery life, and great performance without a single active fan in the chasis. I can run multiple Linux apps in crostini with zero performance degradation or overheating.
RoomyRoots@reddit
Chromebooks are not well supported because they are ARM devices, but in spite of being ARM devices. Google actually did a good job forcing companies to collaborate on making standard devices, no wonders many got custom coreboot support.
Still they are weak machines and the Snapdragon X Elite was supposed to be the x86 killer.
LoafyLemon@reddit
I politely disagree. ARM chips while generally less performant in x86 applications, completely leave x86 chips in the dust when working in pure ARM, and at a fraction of the power use. They are stupidly efficient in comparison.
ARM is defacto the future, and x86 emulation is already underway. Yes, you lose about 20% performance, but the fact it works at all is very promising for the future of ARM architecture.
https://github.com/FEX-Emu/FEX
PsyOmega@reddit
I don't agree here.
My X13S, a thinkpad with a snapdragon 8cx gen3, has a 4p4e core config, and uses 25W under full load of ARM64 native prime calc burnin.
It benchmarks about as well as an i7-1165G7 overall.
This is, granted, a fanless laptop, but it still sucks down power in terms of the silicon and can burn your hand if you run it too long.
My 1165G7 laptop OTOH, sips power. To get the same synthetic benchmark scores capped at 10W PL1/PL2.
The perf/watt metric these days comes from node, not architecture. Apple silicon is a monster of perf/watt, but that's only because they use the most advanced TSMC nodes, run HUGE cores, and clock them in the V/F sweet spot.
chocopudding17@reddit
The person you were replying to wasn't saying ARM wasn't performant; the "in spite of being ARM" thing meant "in spite of ARM being so fractured as to be just an ISA and not a proper hardware platform."
LoafyLemon@reddit
I am disagreeing with the performance claim, not the first paragraph.
idontchooseanid@reddit
"They" in their sentence points to Chromeboxes which were very weak ARM devices, not ARM CPUs in general.
mailslot@reddit
No, ARM chips aren’t necessarily fast. There are some fast ones, but there are plenty of performance hogs based on reference designs, like the Raspberry Pi & Rockchip SOCs. If a company has deep enough pockets, they can redesign an assload of circuitry and race one out… but they can do the same thing with an x86 or MIPS instruction set too.
Intel and AMD are the kings of x86 today, but they’re not the only manufacturers. There are some truly awful performing x86 clones out there. It’s how they’re implemented, not the architecture itself. Modern x86 CPUs, internally, are practically RISC anyway.
When people speak of high performance ARM, they should be referring to Apple & Qualcomm instead. Apple isn’t going to start selling the M5 to PC OEMs. So, realistically, any hope of mainstream high performance ARM PCs currently lays completely on Qualcomm and a handful of obscure server CPUs.
silenceimpaired@reddit
Imagine how the world will be when Hippie Collective Inc. releases RISC V chipset :)
PMvE_NL@reddit
A manufacturer can still make a closed source riscV chip if I am not mistaken.
mailslot@reddit
Any CPU that performs well will certainly be closed source.
silenceimpaired@reddit
Surely not Hippie Collective!
fellipec@reddit
Arm OEMs want to lock users
TheNavyCrow@reddit
they don't, at least not qualcomm
linux is def not their priority, but they're still providing upstream supporting
fellipec@reddit
Yes they are. Locked bootloaders, no standard into the bootloader/device tree, every device is its own quirks. Yes they want you locked up.
AncientAgrippa@reddit
Turns out the Debian guys were right about this one, if you all remember the drama from a while back
wRAR_@reddit
I don't, what was the drama?
AncientAgrippa@reddit
Don’t hate me for this but I was running an experiment that says redditors will upvote anything , looks like it is the case.
SolidSank@reddit
You got me, I assumed there were forum post dramas about this on some unofficial debian port to snapdragon.
I know Ubuntu has it's unofficial version for these snapdragon laptops, but the last I checked was right before buying my current laptop (and development didn't really go anywhere because it's complicated to get webcam and all the laptop stuff working 100%).
AncientAgrippa@reddit
don't get me started on the canonical snapdragon flame wars of the early 2020's.
bennyc500911@reddit
What if there really was some drama that you just didn't know about?
Obnomus@reddit
Lmfao
shegonneedatumzzz@reddit
best chuckle i’ve gotten from here in a while lmao
AncientAgrippa@reddit
What’s funny is that I can see since my second comment people have been downvoting the first lol
john0201@reddit
This is the best comment I think I’ve ever read on Reddit
mlor@reddit
Is this yet another test?
KlePu@reddit
Are you testing me now?
wRAR_@reddit
I like it
stobbsm@reddit
As someone who worked with Qualcomm socs in a previous job, they won’t be suitable. Qualcomm is super protective of its IP, not allowing most to actually compile from source but to use their precompiled modules.
This means that they control how long an SOC is viable in a commercial product.
pfp-disciple@reddit
Pretty decent article until "In the meantime, there are countless Windows 11 laptops powered by Qualcomm's Snapdragon X Elite". Way to throw shade at Linux.
Nelo999@reddit
Most of those Windows 11 laptops cannot even run the vast majority of Windows programs out there as they are unsupported on ARM.
Just look at the latest Surface Pro fiasco for example:
https://arstechnica.com/gadgets/2025/06/review-microsofts-13-inch-surface-laptop-isnt-bad-but-it-is-a-step-down/
Meanwhile, most Linux distributions work on ARM and most of the Linux software supports it too(just because Linux does not support that specific chip, it does not mean it does not support ARM in it's entirety).
Just like Linux works on PowerPC, MIPS, SPARC and so on.
CPU families that Windows can only dream of.
mailslot@reddit
Windows used to work on PowerPC, MIPS, Alpha, and Itanium. There was even an experimental unreleased port for SPARC. Windows is actually cross platform which is why it wasn’t a huge deal to port to ARM.
20dogs@reddit
It's quite a mild point, and relevant to the site focus.
pfp-disciple@reddit
Yeah, the article is still relevant. The first part is very interesting and newsworthy.
prosper_0@reddit
lol, yeah, but they're Windows 11 laptops. That's only marginally better than a nonfunctional linux laptop. And let's not forget that most of those show stoppers for tuxedo would simply be ignored by a lot of the skeevier Windows manufacturers.
RoomyRoots@reddit
It's WindowsCentral after all.
Fofeu@reddit
The site is windowscentral.com ...
Cry_Wolff@reddit
Windows central is very pro Windows? I'm shocked!
nevadita@reddit
So hold up, if all the ARM virtues we have heard form Apple Silicon aren’t achievable on Linux then are you telling me that windows on ARM is better?
What’s this bizarro world?
Nelo999@reddit
Windows on ARM isn't better lol.
It cannot even run the vast majority of Windows software as it does not even support ARM.
Meanwhile, not only most Linux distributions and software support ARM.
But Linux also works on anything from x86 to PowerPC, MIPS, SPARC and so on.
CPU families that Windows can only dream of.
Just because Linux does not support that specific chip, it does not mean it does not support ARM as a whole.
nevadita@reddit
Okay but like, the ARM virtues they are talking and gauging themselves about are from where? MacOS On apple sillicon or what?
Or just judging by using mobiles as reference?
And the snapdragons elite x laptops? Those run windows no?
skoink@reddit
I'm not surprised by this. Qualcomm's Linux support is surprisingly garbage-tier. KVM doesn't work because Qualcomm decided to move a bunch of their clock/power management code into a VM, which only runs under their shitty proprietary hypervisor. Their drivers also don't support clock scaling or shutdown of unused CPU peripherals.
IngwiePhoenix@reddit
Tuxedo saw the Snapdragon DTs and were like...
... nah fam. Nah. nnnnaaaaaahhhhhh.
Understandable. x)
shirro@reddit
The Snapdragon X Windows debut was a bit of a flop as well. It doesn't matter how good your hardware is if the drivers and OS features can't exploit it. Marketing on you hardware's supposed capabilities is pointless the moment someone gets their hand on a product and discovers it doesn't live up to the hype.
The good news for Qualcomm and Linux ARM fans is that Valve is paying elite devs money to raise Snapdragon to the where it should be for the Frame. Companies like Tuxedo and System76 will be able to badge engineer better products in future as a result.
JackDostoevsky@reddit
well that's more than a little disappointing, as i had in the back of my mind that i'd look at a Snapdragon CPU when i upgrade my laptop next year. guess all signs continue to point to me buying a Framework lol
CaptainObvious110@reddit
Good
Great-TeacherOnizuka@reddit
Why?
The_Band_Geek@reddit
RISC-V when?
bengringo2@reddit
That will be on China. They have been making inroads with DeepComputing. I wish we could see more development on it in the west but ARM is far more popular here.
New-Tomato7424@reddit
Bye bye, now give us highend strix halo with haptic touchpad
LowOwl4312@reddit
ARM is a dead end, long live x86
viper4011@reddit
Valve: Hold my beer.
I know it’s not the same chip but it still feels like that.
PMvE_NL@reddit
Oh yhea the goggle thingys are gonna run an arm processor right?
wRAR_@reddit
4 nm Snapdragon® 8 Gen 3
cac2573@reddit
Shocking
CinSugarBearShakers@reddit
This is a test run if MS AI can create a post and converse with itself on social media.