If anybody in Qualcomm leadership is reading this thread: this is a good start, and I applaud you for it. There is also a lot more to do if you're serious about growing your market penetration beyond phones.
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.
> Also your boot-chain is still closed and proprietary
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.
> ... 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. ...
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?
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.
There is nothing in this press release to suggest they've changed.
As someone who uses Mobile Linux, I am pretty excited to see this, but I can't help but wonder if this is only a "Business decision" and not necessarily Qualcomm turning over a new leaf for being FOSS friendly:
I'm personally rooting for "business decision" over "turning over a new leaf".
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.
Snapdragon does poorly I think because it's a bet if it works or not. Windows runs things seamlessly other than OpenGL (it can run that too but it's not anything strait forward - needs the gl to dx store app thing) but the other reason is cost. for the premium business laptop most buyers (business) won't budge off Intel even because of the "no one got fired for buying IBM" mentality at the big Enterprises Ive been at.
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.
Of course it's a "business decision". Companies don't do things for any other reason. They see a benefit to upstreaming in this instance, and will do it again (or not) depending on whether or not they expect to see benefits in the future.
This is no different from any other company that has "embraced" open source.
It'll probably be as much of a second class citizen elsewhere (the real problem is the hardware hasn't as good as Apple Silicon laptops but has been in the same price class at the bottom) but it's good they chase everywhere rather than just one use case.
I'd imagine it's purely because not doing it turned out to be PITA in the long term.
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
Their problem was that they had the performance claims and marketing of Apple but the implementation of Microsoft Teams. Apple M1 was shaky but all the groundwork was there and it took off. Qualcomm was highly questionable at best.
> Their Snapdragon X laptop didn't do very well, and they likely realize an ARM Windows laptop will always be a second class citizen
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.
Woah, this is amazing. I’ve been looking for an ARM Linux machine for a while and ended up about to get M2 Pros in a rack running Asahi. It has been near impossible to get a Snapdragon Elite machine. The IdeaCentre or whatever is 2x the cost / performance and as far as I know is poorly supported.
This changes the game. I’d rather use native Linux than Asahi (though the latter is amazing).
I hope this is motivated by shrewd decision-making in response to market pressure, as opposed to being strictly a perception thing.
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.
> When you get new hardware and new features, you don’t want them sitting idle while you wait for patches to get upstreamed. Whether you develop for IoT, automotive, audio or mobile, when you get new features in a system-on-chip (SoC), you want to take advantage of them right now.
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.
Has Qualcomm seen the light after working with Valve on Steam Frame? The news that Steam Frame would be running an open source Adreno GPU driver really caught me by surprise.
My impression from the emulation folks is that the proprietary drivers are chock full of problems. I suspect it was open source drivers or nothing (i.e., back to an AMD x86 solution like the Steam Deck).
(And I don't think Qualcomm has seen the light - my understanding is that the Turnip drivers are purely reverse engineered.)
Does that mean that one will be able to purchase tablets with this chip and replace the OS with Linux?
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?
I really hope this is the case because I’d love to have an arm64 laptop for work. Then binaries in my laptop will work on my embedded systems, generally.
Sorry. I don't trust these guys. Some of my Linux laptops use their wireless hardware and the drivers are so poor that, YEARS later, Wi-Fi still doesn't work right.
> The Adreno user mode driver (UMD) from Qualcomm Technologies is available as a downloadable Debian package and provides Vulkan 1.4 API support as well as the necessary GPU-related firmware.
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.
Does KVM hypervisor work? Previous Qualcomm CPUs have locked hypervisor mode behind Qualcomm proprietary blobs, and only allowed HyperV to use it - this was definitely the case for WOS laptops.
While we are at Snapdragon processors ... Does anyone know what (not so technical-)user friendly distro runs without too many issues on a Snapdragon 850? I found Mobian listing Snapdragon 845, but I don't know at all, if that is almost the same or not compatible at all.
Can you buy this chip or is it only for Android phones? They have bad support for what you can buy (X Elite) but now they're touting upstreaming the chip you can't buy?
I don't know much about ARM SoCs, is this something you would built a phone with? With all the talk about Google locking down Android, can Pine64 please go and make a Pinephone with this if that brings us closer to a Linux phone?
[+] [-] nrclark|3 months ago|reply
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.
[+] [-] flto|3 months ago|reply
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.
[+] [-] zozbot234|3 months ago|reply
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?
[+] [-] my123|3 months ago|reply
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
[+] [-] ryukoposting|3 months ago|reply
[+] [-] modeless|3 months ago|reply
[+] [-] znpy|3 months ago|reply
Go all in or go home, qualcomm.
[+] [-] 0xbadcafebee|3 months ago|reply
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...).
There is nothing in this press release to suggest they've changed.[+] [-] tvshtr|3 months ago|reply
[+] [-] TiredOfLife|3 months ago|reply
[+] [-] DeathArrow|3 months ago|reply
Does Apple offer better support? Qualcomm offers commercial support. I guess Tuuxedo Computers didn't pay for the support?
[+] [-] kop316|3 months ago|reply
- 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.
[+] [-] h14h|3 months ago|reply
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.
[+] [-] hypercube33|3 months ago|reply
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.
[+] [-] kelnos|3 months ago|reply
This is no different from any other company that has "embraced" open source.
[+] [-] zamadatix|3 months ago|reply
[+] [-] PunchyHamster|3 months ago|reply
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
[+] [-] alganet|3 months ago|reply
[+] [-] gessha|3 months ago|reply
[+] [-] musicale|3 months ago|reply
https://www.microsoft.com/en-us/surface/devices/surface-lapt...
[+] [-] a-dub|3 months ago|reply
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.
[+] [-] jorvi|3 months ago|reply
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.
[+] [-] arjie|3 months ago|reply
This changes the game. I’d rather use native Linux than Asahi (though the latter is amazing).
[+] [-] h14h|3 months ago|reply
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.
[+] [-] ninth_ant|3 months ago|reply
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.
[+] [-] modeless|3 months ago|reply
[+] [-] daemonologist|3 months ago|reply
(And I don't think Qualcomm has seen the light - my understanding is that the Turnip drivers are purely reverse engineered.)
[+] [-] jeroenhd|3 months ago|reply
I hope they succeed but the last generation has only recently become mostly usable for specific distros. General support may take a while.
[+] [-] bsimpson|3 months ago|reply
[+] [-] RobotToaster|3 months ago|reply
[+] [-] tvshtr|3 months ago|reply
[+] [-] unknown|3 months ago|reply
[deleted]
[+] [-] mg|3 months ago|reply
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?
[+] [-] jsheard|3 months ago|reply
Apparently WSL2 does work, it pulls a native ARM64 Linux distro and then proceeds as usual.
[+] [-] hypercube33|3 months ago|reply
[+] [-] fsflover|3 months ago|reply
Does this count? https://puri.sm/products/librem-11
[+] [-] throwaway173738|3 months ago|reply
[+] [-] miyuru|3 months ago|reply
> 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.
[+] [-] binkHN|3 months ago|reply
[+] [-] freehorse|3 months ago|reply
[+] [-] tensegrist|3 months ago|reply
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
[+] [-] shmerl|3 months ago|reply
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.
[+] [-] summa_tech|3 months ago|reply
[+] [-] zelphirkalt|3 months ago|reply
[+] [-] ori_b|3 months ago|reply
[+] [-] peppersghost93|3 months ago|reply
[+] [-] wmf|3 months ago|reply
[+] [-] tw1984|3 months ago|reply
let's stop being naive - qcom will not change.
[+] [-] pjmlp|3 months ago|reply
https://www.qualcomm.com/developer/software/qualcomm-linux
[+] [-] maufl|3 months ago|reply