The stability layer also doesn't actually let you seemlessly update the kernel. Those userspace binaries are coupled to specific kernel releases, and it requires work on the vendors part to facilitate new kernel version upgrades. Maybe being upstream will force them to actually take backwards comparability with older userspace binaries more seriously though.
I hope they succeed but the last generation has only recently become mostly usable for specific distros. General support may take a while.
(And I don't think Qualcomm has seen the light - my understanding is that the Turnip drivers are purely reverse engineered.)
presentation is half the message!
That would be great. As far as I know, there currently are no options for lightweight tablets that support Linux.
Not sure how well WSL2 on tablets work. Does anybody here have experiences with WSL2 on tablets like the new Microsoft Surface Pro that uses the Snapdragon X Elite chip?
Apparently WSL2 does work, it pulls a native ARM64 Linux distro and then proceeds as usual.
The hardware is great, though, I love the 12” Surface with the X1E. WSL2 works great!
I can understand Apple Silicon having an initial advantage due to its hardware TSO support, but I'd have expected some combination of efforts at ARM and Qualcomm to have caught up by now. Shouldn't ARMv9 have a standardized (if optional) TSO mode? I'm disappointed by the foot-dragging.
Does this count? https://puri.sm/products/librem-11
And I would want to do a normal Debian stable installation. Just like I can on a Lenovo laptop. The Librem 11 comes with their own Debian based distro and I can't find any info if I can install a normal Debian on it from scratch.
> Hardware-accelerated video recording into H.264 (AVC) and H.265 (HEVC) formats
no mention of AV1? Surprised since most websites including YT uses it heavily.
Maybe that part of the driver isn't finished yet?
It actually introduces new things into the UAPI because no one else did fully-stateful AV1 decode before.
- Their Snapdragon X laptop didn't do very well, and they likely realize an ARM Windows laptop will always be a second class citizen: https://www.techpowerup.com/329255/snapdragon-x-failed-qualc... .
- Likewise, Mobile SoCs are completely dependent on Android without proper upstreaming (which they haven't done in the past).
- They are seeing Valve spending time and money on FOSS support paying off, especially with their new hardware releases.
On the other hand, proper upstreaming of the chips give them much more flexibility for different linux-based OSes.
I will say with my 8 gen 3 snapdragon I'm impressed and also disappointed - stupid thing needs active cooling and I'm pretty sure it's bad enough that it's desoldered or damaged the core or something from heat but also you can't get driver updates for the GPU if you wanted because Qualcomm be the way it do.
A common example is overheating, because the way the OEM has done their device isn't a setup that the driver knows about.
Which is why on laptops, the drivers if available have to be from the OEM themselves.
If installing drivers that come directly from NVIDIA onto a laptop can cause that laptop's GPU to overheat in the sense of getting so hot it fails to function properly or has degraded reliability, that's entirely NVIDIA's fault. If by "overheating" you just mean drawing more power and causing the fans to get louder than they would in an out of the box configuration, the blame for that should be shared between NVIDIA, Microsoft, and the laptop OEM, but you shouldn't blame the user for doing something that should work and would work if those three vendors could cooperate.
Naturally nowhere to be found on PC stores, and online I never found it on sale in the Dell store.
Go into store, get to talk with a "genie", whatever upsells to meet their KPIs, and leave with another computer that counts to the world market share in desktop units.
Which for all practical purposes means Windows, macOS, Chromebooks, iPad Pro or Android tablets with keyboard for Dex, HyperOS, HarmonyOS NEXT , and zero GNU/Linux devices.
1st party native software support is high and 3rd party native software support is higher than Linux. Both have feature complete userspace emulation layers for the 3rd party part (largely game focused) Windows doesn't need Proton for that. Both can run open source apps natively.
I am pretty sure 99% of the population is in the same situation.
It's like phones where people say everyone will buy out any phone with more battery life and then the standard type phone is always actually what sells. Consumers will gladly pick more battery all else equal, but that's not what the snapdragon laptops have been.
Not that Apple gave consumers much choice, but when they switched over it was truly all else equal or better and it sold like hot cakes, despite many popular still needing emulation for the first year they still ran better than they would have natively in the other option anyways. Qualcomm doesn't get that nearly as easily because they are competing against the latest off all current x86 options, not a subset of older Intel options.
I'm hoping that changes with the newer Elites though. At least the performance seems to be getting there, if not the price yet.
As with pretty much all other ARM cpu vendors that pushed for their own kernel fork just to have drivers that did not need to be okayed by mainstream kernel, it was faster iteration to deliver something working to their clients; but it was also PITA to their clients, especially when industry started demanding longer support for their devices
This is no different from any other company that has "embraced" open source.
If FOSS support is motivated by a clear profit motive, then it'll be viewed positively by shareholders and stick around no matter who is in charge. If FOSS support comes from "turning over a new leaf", it could be dropped at a moment's notice in response to a leadership change.
IMO we will always see far better FOSS support from the private sector when the time they invest has a positive ROI that is obvious and easy to brag about in a quarterly earnings call.
In Tom Murphy's words:
> Energy transition aspirations are similar. The goal is powering modernity, not addressing the sixth mass extinction. Sure, it could mitigate the CO2 threat (to modernity), but why does the fox care when its decline ultimately traces primarily to things like deforestation, habitat fragmentation, agricultural runoff, pollution, pesticides, mining, manufacturing, or in short: modernity. Pursuit of a giant energy infrastructure replacement requires tremendous material extraction—directly driving many of these ills—only to then provide the energetic means to keep doing all these same things that abundant evidence warns is a prescription for termination of the community of life.
I think it would be much more honest to say we don't know so we shouldn't bet everything on one approach.
Humans care about survival and will impact the world. It is exactly what all other animals do, and there is a dynamic equilibrium: too many predators => reduced prey => less predators. I don't think it's fair to think we humans are special. Or should we blame the algae for one of the previous mass extinctions?
I do think it is reasonable to take more care about the environment (co2, pollution, etc.) than we do because we need it in order to live well (not because I just want a nice Earth). I think most people agree with that, and are slowly adapting. Will see if fast enough.
[1] https://tmurphy.physics.ucsd.edu/papers/limits-econ-final.pd...
The inputs and the outputs of the AI are always human-facing, so the goals vaguely resemble human values (even if the values are greed).
https://news.ycombinator.com/item?id=44335953
What gets to the top of the feed? Organic, rational arguments or the arguments with enough money behind them? Economics explains it, again.
Why? So far ARM laptops provide either vastly better battery life for the same performance or vastly better performance for the same battery life. Even versus discrete GPUs.
Within a couple years from now you're gonna look like an utter fool for buying x86 (and Nvidia / AMD / Intel GPU) unless Intel, AMD and Nvidia really pull their head out of the sand.
There's a few specific workloads like local LLM and legacy where you'd want a discrete GPU or x86, but otherwise it is looking like GG.
https://www.tuxedocomputers.com/en/Discontinuation-of-ARM-no...
For example https://www.pcworld.com/article/2463714/tested-intels-lunar-...
On another very reputable Dutch site, you can see the Snapdragon consistently lead the Lunar Lake laptop, and that's with Lunar Lake set to maximum performance[0]
There is also a general logic to it: Apple M-series still handily beat anything Intel has, and Qualcomm's Snapdragons beat the M-series they follow up.
Maybe Intel can truly push x86 to unseen heights, who knows? There's nothing technically stopping them but so far it hasn't beared out. Similar with Nvidia, their RTX 3090 power limited at 340W got beat by an M1 maxed out at 120W. Why isn't the RTX 4090 or 5090 half the TDP?
[0]https://tweakers.net/reviews/12482/lichte-krachtpatser-met-l...
https://www.microsoft.com/en-us/surface/devices/surface-lapt...
are there any linux phone projects that are actively maintained and used in 2025? i was under the impression that android kinda subsumed them all.
also, not to beat a horse that is by now six feet under, but
> No delays, no hurry-up-and-wait, no registration. Just go get the new features.
i'm so tired
i mention this because perhaps you'd like it too. in my case fedora 43 works just fine, and fast.
do you use macos at all, or do you do ~everything within a full-screened fedora instance?
I didn't have to do _anything_ weird: just grabbed the latest Fedora iso for aarch64 ( or arm64...i forget what it was named), and voila.
This changes the game. I’d rather use native Linux than Asahi (though the latter is amazing).
Those are all perfectly acceptable limitations for a POC. And the GPU drivers are particularly well-made. But it doesn't really come close to how seriously AMD and Intel take Linux.
even in the m1 there are 4 WIP in the support table, 2 TBA and 10 non mainline boxes for the M1 pro
Ships with aarch64 Ubuntu 24.04.
Tons of cores and RAM.
Very quiet and small
UEFI bootloader - I installed Ubuntu 25.10 and ESXi arm edition just by booting the ISO
usb-c power input (kinda cool)
Insane connectx 200GbE RoCE networking
10GbE Ethernet
Oh and an nvidia gpu with cuda and access to 128GB of unified memory
It would be perfect if it had some kind of BMC or IPMI/redfish and an exposed PCIE slot. But this thing is an awesome arm64 workstation no doubt.
May try to install to a USB drive and hang another gpu off the nvme port just to see what happens
Seems like the middle ground between SBCs and huge servers is a bit underserved in ARM...
AFAIU, the biggest challenge of running Linux on ARM machines is supporting the devicetree of each machine. After all, there is mainline kernel support for previous Qualcomm chips, yet very few machines with those chips can actually run Linux distros.
So this is good news, but in practical terms it's just a marketing piece.
They aren't targeting enthusiasts with this announcement.
[1] https://lore.kernel.org/kvm/20250424141341.841734-1-karim.ma...
[2] https://github.com/karim-manaouil/linux-next/tree/gunyah-kvm
KVM is available on current compute platforms (laptops) if you escape to EL2 via slbounce; and on Glymur (X2E) it will be available by default (yay!).
I just don't understand this argument of a separate interface. The only reason you want to do that is to decouple from the KVM community, but that introduces a shit tone of duplicated effort and needless fragmentation to the virtualisation software ecosystem hindering your users from enjoying the existing upstream tools they already know about. In other terms, vendor locking and shitty downstream experience.
The prototype impl at the time broke some Windows functionality
Are they already using Turnip / Mesa as their Vulkan implementation or not yet? If not, they should. Valve are using Turnip on their Steam Frame.
That would be another step of working with upstream, besides the kernel driver.
While it would be great for Qualcomm to "do the right thing" in supporting FOSS, I feel much more confident in that support being sustained long-term when it aligns with some profit motive.
IMO the best case is that Qualcomm sees dollar signs when they imagine their Oryon CPUs and Adreno GPUs dominating the consumer linux landscape. There is definitely room to shake up x86 (especially when it comes to perf/W and idle battery drain), and only a finite window for ARM to do so with RISC-V on the horizon.
And to whatever extent Qualcomm et al now view Linux as a relevant personal computing platform, I think a massive amount of credit goes to Valve. I seriously doubt Linux support even enters the conversation at these companies without the Steam Deck's success.
Sure doesn’t sound like mainstream consumer pc desktop is the target at all. Yes, they do provide instructions for how to run this on desktop but it’s far from accessible for the overwhelming majority of pc users.
I mean it’s still a good thing for Linux desktop to have this as an option, I’m not complaining. But to be realistic those benefits feel tangential to what Qualcomm is aiming at here.
Admittedly a hypothetical Arm-based Steam Deck or Framework Laptop were at the forefront of my mind, but I think any consumer product running linux qualifies, be it "IoT, automotive, audio or mobile".
Whether people are buying EVs with a slick linux-based infotainment screens, gaming handhelds running SteamOS, or smart-devices with fancy local AI features, I think the effect is the same. If Qualcomm predicts significant growth in demand for efficient, high perf devices running customized Linux distros, I think it could be great for FOSS at large.
On phone platforms.. probably not? Or Android might want it for pKVM..
The drivers might be up on LKML, but they're not mainlined yet. And this is just gen5. It would be great if you could fix your gen4 and 4.5 drivers, so that people building products with your chips weren't stuck on an orphaned vendor kernel that doesn't even upstream to your public fork.
Also your boot-chain is still closed and proprietary, and completely different than the one used by all other ARM vendors. Being the special snowflake is not helping your business or your customers.
And don't even get me started on Gunyah and GearVM, or on the proprietary, locked nature of your BSP, or how far behind TI and NXP you are on software quality and ease of use. Maybe also consider releasing some actual documentation on your chips.
I know multiple developers who have sworn off Qualcomm and will never design with your chips again at any price point. Your closed-off support model is 100% the culprit, and it hurts your core business. Any software support revenue that you managage to extract comes at the cost of goodwill and future chip sales.
Your chips are good - best in the industry. If you can up your software game to match, you'll really meet your potential.
Why does the boot-chain matter? Can't we just have a custom U-Boot implementation that interacts with the bespoke boot chain while providing standard UEFI support to the rest of the system? Isn't that how Asahi works?
A full-featured U-Boot implementation would be fine IMO. But for the generations that I've used, that's not on the table. What we get is a proprietary flow through a proprietary hypervisor into a fork of Android's bootloader (even if vanilla Linux is the target OS). There's no way to control startup boot options, and no way to use KVM, Xen or any hypervisor except the proprietary one that's also part of the boot chain.
This doesn't lend itself to flexible products, or to products that are easy for a company to design or support. That is why things like this happen: https://news.ycombinator.com/item?id=46008156
Go all in or go home, qualcomm.
Nowadays the standards for Linux support are much higher. This isn't the 1990s anymore. Releasing a half-assed support that will be obsolete in six months is pretty much useless.
Also, the fact that the drivers have not been upstreamed tells me they're most likely sub-par in terms of code quality and possibly stability.
What's the point of buying hardware whose softwares support is already deteriorating ?
Nowadays the entire thing until you land in EL1 needs to be signed by Qualcomm as well. This is without "Secure Boot" enabled. OEMs only get to run code under the hypervisor. And you might want to use a part of the hardware but someone decided the VM your code runs in shouldn't have access to that, too bad.
EL2 is still locked down for the chip this post is about, AFAIK. And everything else is is staying locked.
Lots of this is customer dependent but what you say is true for the typical android phone config that most use
It will be interesting to see what Google got from Qualcomm for the new Chromebooks (EL3 isn't even the highest level anymore, that's TME now).
The new AL BSP target for Hamoa, which is what's going to ship on the new Android laptops, runs KVM at EL2 instead of Gunyah. But it has (at least partially) Qualcomm-owned EL3.
This is much better than that. Not great yet, but much better than that in comparison.
I agree Qualcomm's support of open source is better, while still leaving a lot to be desired.
That said, though, Apple can't be best for embedded applications, they're plainly not competing in that space - or can you make e.g. a custom ticket vending machine with an Apple chip?
Gunyah is disappearing from new chips, slowly but surely.
X2 doesn't have it anymore, the IoT range has it as optional now. And it's going to be deployed less from there
Who benefits from having separate BUs maintain fully separate software stacks? It's duplicated, wasted effort on Qualcomm's part. Maybe it lets them double-charge their customers for this duplicate effort, but that feels short-sighted. It leaves a bad taste in their customers' mouths. And there's certainly no benefit in delivered software quality.
Qualcomm should be making it easy for everybody to buy and use their chips, not artificially segmenting every single customer. They could sweep the market so hard if they were just a little less greedy.
The problems seem rather similar, a while after release you need a dedicated build to actually get Linux working mostly right. Doesn't come close to the normal Linux experience. Then again, the X1 Extreme seems to have USB display and thunderbolt support, so they're better than Apple Silicon will probably ever be on Linux.
Having basic SoC support doesn't mean you can just flash a kernel and expect the device to boot, though.
The tooling itself actually does most of the work for you. Things like compiling the kernel and building and flashing the install image pretty much happen automatically once you've copied over a template and edited the necessary sources.
You can probably boot pmOS if you copy a template for a device with the same CPU but if there are no similar devices, you're on your own. Even if it does boot, there's a good chance you end up in a "no display, no USB, no wireless, no sound" scenario where the kernel runs but won't be doing anything useful. Just having CPU support isn't enough, you'll probably need the appropriate device tree definitions and possibly kernel drivers which you may be able to lift from the Android kernel if your device came with that.
Very few Android SoCs have upstream support that even comes close to what the Apple M1 has, let alone an amd64 CPU. The new Snapdragon Extreme chips are very different in terms of design and in terms of how Qualcomm approaches them, and even their support is lacking in practice.
I'm pretty keen to play around with Proton, FEX in a laptop that rivals the MBP
Yet 2 days ago, Tuxedo Computers announced they were abandoning Qualcomm due to crap support. (https://www.theregister.com/2025/11/26/tuxedo_axes_arm_lapto...).
In particular, the long battery runtimes – usually one of the strong arguments for ARM devices – were not achieved under Linux.
A viable approach for BIOS updates under Linux is also missing at this stage, as is fan control.
Virtualization with KVM is not foreseeable on our model, nor are the high USB4 transfer rates.
Video hardware decoding is technically possible, but most applications lack the necessary support.
Does Apple offer better support? Qualcomm offers commercial support. I guess Tuuxedo Computers didn't pay for the support?
Do AMD and Intel require Tuuxedo to pay for premium support in order to get working Linux drivers? No, of course not.
Qualcomm's support for Linux is embarrassing when you compare it to pretty much any processor manufacturer except Apple.
...and while they're standing away from GPL stuff, they do have a dedicated site for Open Source software: https://opensource.apple.com/
Go to releases, and see what they do there.
I don't expect any daily-driveable alternative operating systems on Apple systems since it's a continuously moving target, yet Apple doesn't have a such heavy-handed approach. They just do their thing and do not hinder things actively like NVIDIA and Qualcomm.
afaik you technically can, except that m1/m2 force pcie bars to be mapped as device memory (forbids unaligned r/w), so most gpu software (and drivers) that just issue memcpys to vram and expect the fabric to behave sanely will sigbus. it's possible to work around this, and some people indeed have with amdgpu, but it'd absolutely destroy performance to fix in the general case
so it doesn't really have anything to do with apple themselves blocking it but rather a niche implementation detail of the AS platform that's essentially an erratum
There's also an Apple VP saying unified memory on AS doesn't leave room for DGPUs and separate VRAM.
I think this is more than just an erratum, even with newer chips. It's monopolistic behavior all too common nowadays.
> There's also an Apple VP saying unified memory on AS doesn't leave room for DGPUs and separate VRAM
can you link to this? my intuition is that they're speaking on whether apple would include dgpus inside AS systems like they used to with nvidia and amd chips in macbooks, which i agree wouldn't make much sense atp
Whatever kernel or hardware facilities are available to Apple's own GPU driver, should be available to other GPU drivers. Anything else is myopic thinking, which I realize might be common for Apple, but it is also monopolistic.
Linux also allows userspace drivers with less performance I think, but I don't think DGPU use can be made performant because of AS hardware choices.
I am predisposed to ignoring link requests for things that can be easily googled.
It's exactly the stuff that they actually do themselves that Qualcomm has been making very hard.
So how about you give me a fucking break, Qualcomm? Call back when Snapdragon has first class support in major distros and you are serious about Linux.
let's stop being naive - qcom will not change.
Why is any of this needed when the kernel is full of platforms that are forward compatible with the Linux kernel and boot and generally operate on day one, without a huge pile of changes?
What does it benefit the user to have a huge pile of proprietary implementations of devices they frankly don't care about? Ex: just about anything related to power management? Why can't QC adhere to industry standards when they implement standard devices, ex: USB? Why can't these platforms adhere to industry standard firmware interfaces rather than custom mailbox interfaces?
imcritic•2mo ago
micw•2mo ago
ddtaylor•2mo ago
imcritic•2mo ago
cuu508•2mo ago
ronsor•2mo ago
boredatoms•2mo ago
TiredOfLife•2mo ago
https://en.wikipedia.org/wiki/Fall_of_the_Fascist_regime_in_...
https://en.wikipedia.org/wiki/Romanian_revolution
happosai•2mo ago
IshKebab•2mo ago
doublerabbit•2mo ago
imcritic•2mo ago
coffinbirth•2mo ago
sl-1•2mo ago
mathfailure•2mo ago
remix2000•2mo ago
fainpul•2mo ago
ddtaylor•2mo ago
TiredOfLife•2mo ago
tomhow•2mo ago
vanviegen•2mo ago
imcritic•2mo ago
tomhow•2mo ago
zimza•2mo ago
koiueo•2mo ago
zimza•2mo ago