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.
The Snapdragon Chromebooks use older chips that didn't have the locked down boot-chain yet. Even if you didn't have the official EL3 unlock that Google got, you could still get into EL3 trivially if you wanted to.
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).
> 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.
> ... 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?
It matters when you're doing custom hardware, or when you're designing a product where boot speed matters, or when you need to implement something special.
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
Aside from the sibling comments, it also matters that you need to be able to review it if you need to build a truly "secure" product. History is littered with broken, unfixable secure boot implementations.
Because a computer isn't just a processor. It has to interact with an EC, IO controllers, and whatnot, and if you don't have control over the boot chain, all of that stuff becomes an even bigger PITA than it already is.
Awesome, that's great to hear. Now if Qualcomm would only relax the walls between their business units, their other customers could benefit as well.
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.
If I was to guess, id say someone did this as a side project at QC because maybe they like FOSS and want to give something back. Given the partnership between QC and MSFT for laptops and Google for android, I won't be surprised if we never see interest from QC for any real linux hardware.
I guess you were specifically replying to the last paragraph; that wasn't clear to me at all. A quote would've helped :)
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?
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.
White label reseller isn't really the right term. They don't design most of their components and buy them wholesale, but they do assemble them and most relevant to this particular comment thread, they do a lot of the device firmware and support stuff.
It's exactly the stuff that they actually do themselves that Qualcomm has been making very hard.
Apple doesn't actively lock and act hostile towards the reverse engineering folks. They just do their thing and sometimes do small jests to allow these folks to boot anything they want and play with the hardware.
...and while they're standing away from GPL stuff, they do have a dedicated site for Open Source software: https://opensource.apple.com/
if you are in the business of buying parts, assembling them, and selling the assembly under your brand (as tuxedo and others like them are), then Apple is a indeed not an option. Their chips might be the best, but you still can only get them in Apple devices, in the specs Apple provides and with no official support for any OS beside macOS / iOS.
That's true. What I wanted to point out is the fact that the most tightly integrated and arguably the most locked down platform on the market is more open than a platform designed to be adapted by others and sold by many.
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.
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.
Incentives trump feelings for publicly traded companies 99 times out of 100. People constantly anthropomorphize them, but they aren't people (regardless of similarities in the law), and they definitely don't act like people, at least normal ones. At best, you can view them as something like a sociopath. I wouldn't look at a sociopath acting nicer and think "oh, they turned over a new leaf" because they aren't just going to change how their mind works, I'd think "oh, they found a reason to act in a way I like for the time being. I hope it isn't short lived."
I like to call them slow-AI. They are paperclip optimizing AIs. No single component wants the larger outcomes, yet they happen. These slow-AIs are terraforming our planet into a less habitable one in order to make GDP number go up, at any cost.
People changed environment even before these optimizations. I think now it's more a problem of fast enough "catch-up and converge", for example for CO2 : https://ourworldindata.org/grapher/co-emissions-per-capita?c... - if the rich countries would reduce a bit faster (using better technologies) then those technologies could be used by the others and impact would be reduced.
It would be great if we could engineer our way out of this situation, but we can't. For many years I strongly believed in our cleverness, after all I was clever and in the narrow domain I worked in - tech - cleverness was enough to overcome most issues. So why not human climate change?
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.
> It would be great if we could engineer our way out of this situation, but we can't.
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.
Our viewpoints don't seem that far apart and thanks for the nuanced take. Personally I believe we know that technology can't fix this by definition because the problem is of social, cultural and economic nature. Our lifestyles are woefully incompatible with a 100k year horizon, even a 100 year horizon in many areas. Our perception of wealth depends on never ending growth, our welfare systems depend on never ending growth, our economies depend on never ending growth. It seems implausible to the point of impossibility that our economies can grow forever [1]. Technology is good at reaching goals e.g. going to the moon is unlikely without science and technology. But in this case the problem is the goal itself. Technology won't motivate us to let go of our conveniences.
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.
Driver update depends on your OEM. Both ARM and Qualcomm send driver updates for their premium and upper highend Socs. The support reaching your phone is on the OEM. Google has started to push direct GPU driver updates starting with Pixel 10. So, hopefully others may follow too.
Usually GPU vendors (Nvidia, Intel, AMD) provide a way to download and install drivers manually (on Windows), including specific versions or older versions. Qualcomm is an outlier in this case.
Note that those drivers usually only work well in desktops, on laptops the GPU might have gone through OEM adaptations on the motherboard integration, and a driver from GPU vendors might have issues.
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.
It might be more fair to say that there's simply no standard way to do power management for discrete GPUs in a laptop, or to integrate such power management with Windows and whatever power management it's trying to do. And the lack of a clear "right" way to do things means laptop OEMs use this area for product differentiation with their own shitty special sauce software and firmware hacks.
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.
I've used basically every Windows on Arm machine - I actually quite like my X Elite ThinkPad T14s Gen6, compared the the X13s - feels like they got everything right, that the X13s got wrong
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.
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.
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
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.
In the case of Linux, that issue is solely because of non-upstreamed drivers. With that, it can be a first class citizen just like any other processor.
It's second class on Windows because it doesn't support game DRM and generally performs worse for the price than an x86 laptop. About the thing it really has going for it is better battery life. Using Linux doesn't really change either of those problems, though it does get you away from the mess that is Windows 11.
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.
10y old laptops are still powerful enough for my usage. So a bit more battery life wouldn't hurt me if performance of an arm system provides at least as much in term of performance.
I am pretty sure 99% of the population is in the same situation.
The situation was 99% of Windows laptops sold ended up being the much cheaper x86 ones or similarly priced ones with more performance.
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.
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.
Software-wise: Ubuntu Touch, PostmarketOS, and Mobian are all actively maintained. Ubuntu Touch uses Lomiri as its UI which is somewhat bespoke (though they're working on disentangling it from the distro for packaging elsewhere), the others use various mobile Linux UIs (and there's a surprisingly large variety of options there).
> 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.
Well, in your article it already clearly states performance tanks as soon as you go on battery. By 20-40%..
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?
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.
Fully agree. When I said "consumer linux landscape" & "personal computing platform" I was thinking much more broadly than desktop PCs.
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.
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).
This might sound silly question, but those of you who have digits/spark machine, has anyone run Fedora on it? I kind of ran away from Ubuntu back to Fedora because reasons. Bonus question, far-fetched, steam and games with FEX?
Steam gaming with FEX is possible on the DGX Spark. The GPU is approximately a mobile 5070 with much less memory bandwidth. The CPU cores are relatively weak, especially after the instruction set translation overhead. There's a lot of stuff that's playable, but the performance is laughably bad for a $4000 machine.
FEX wouldn't affect GPU side of things though. Also, it's a machine that fits into one and a half hand. I'd call it alright for what it is actually in the context of the size.
FEX is relevant to real use cases because a lot of things that would be GPU-limited on an x86 machine can become CPU-limited when running on DGX Spark. The overhead of x86 to ARM translation, plus the low performance of the ARM cores, plus the overhead of WINE all add up to Windows games running on DGX Spark sometimes being CPU-limited and under-utilizing the GPU.
My microcenter has nvidia OEM flavor in stock. There are also flavors from all the other OEMs that differ slightly on cooling but mainly on chassis design.
I don't think this changes the game as much as you think.
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.
The drivers, while impressively reverse-engineered, are basically alpha-quality by Linux standards. Even well-studied M1 machines will have spotty support in comparison to what an OEM can provide officially.
Those that are implemented have been very reliable in my experience, I think that labeling them “alpha-quality by Linux standards” is a ridiculous claim
Then you need an Intel or AMD laptop as a frame of reference. M1 is implemented as-is with much of the silicon's onboard accelerators entirely dark. Hardware accelerated video encode/decode is a lost cause, Thunderbolt will likely never happen, NEON is your fastest SIMD accelerator and cpuidle is still not really figured out.
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.
Asahi is also still a platform with a huge pile of out of tree patches on top because the platform itself is pretty unusual, requiring for example, a 16K page size kernel which is unlike pretty much every other arm Linux platform.
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.)
Maybe eventually, but Valve don't tend to update their hardware very often so it'll probably be a while. They went over 6 years between their last VR headsets, and the Deck is over 3 years old now with no hint of a successor coming (the OLED version is more recent but that was a minor iteration with mostly the same specs).
I care a lot more about the screen resolution than the chip. The Steam Frame would make a really cool Linux workstation if the pixels per degree on the display matched typical monitors. Unfortunately, the resolution would have to be much higher than it is.
The 8 Gen 3 also still uses the previous tile-based A7x GPU architecture, while newer chips use the "A8x family of GPUs based on the new Slice architecture".
They are, but that's hardly unique to Qualcomm. Tons of hardware with "proper" upstream Linux drivers still requires closed-source firmware blobs, and in particular with anything wireless that's probably an unwinnable battle due to regulatory constraints.
Closed source firmware is one thing that actually runs outside the Linux system... but there's also the user space libraries that are needed to interact with the drivers (eg libgl etc... or the vendor partition in most Android phones)
I don't think anyone expects non specialized os images to run on this hardware. That would require a standardized userspace abstraction layer like the one Android has been building out. The kernel is just a tiny piece of what's necessary because drivers have effectively moved into userspace. Graphics is the only area that has embraced this properly in "desktop Linux"
>That would require a standardized userspace abstraction layer like the one Android has been building out
Can you expound on this? And can desktop linux take advantage of it or do something similar?
The android hal situation is tied to binder and a lot of androidisms. It would be a pretty big shift in culture to adopt that stuff into desktop linux. ChromeOS is likely rebasing on top of android in part to take advantage of the bsp layer abstractions android provides. A proper organization needs to be formed to take on this challenge and I'm not sure any of the existing players are well equipped to lead the charge. Valve and other os distributors who want to ship arm products should be sufficiently motivated though. Most just end up choosing to build on top of Android though because it's easier.
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.
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 think the performance of x86 VMs would be pretty poor anyway due to the high overhead of TSO emulation. Windows ARM doesn't have the benefit of hardware assistance like macOS does, and the tricks that Microsoft came up with to mitigate the impact rely on metadata that only MSVC emits, so anything compiled with GCC or LLVM would always hit their emulators slow path.
> Windows ARM doesn't have the benefit of hardware assistance like macOS does
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.
Yeah it does seem backwards that Apple was the most on the ball with this, when their MO is to force developers to migrate to their newest platform in short order, while Microsoft will be stuck dealing with x86 backwards compatibility for the next 25 years.
560g is fine. But I wouldn't want to work on a 11.5" device. Something between 13" and 14" is my preferred size.
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.
PureOS has minimal differences from Debian in that they (a) remove all non-free components to get the FSF endorsement and (b) add not yet upstreamed drivers and features, https://puri.sm/posts/how-to-be-upstream-first. So Debian should work sooner or later.
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.
i'm using Linux just fine on an ARM desktop for a long time, via Apple Silicon hypervisor enabled via the UTM macos app (which wraps both Qemu, which i don't use, and Apple Silicon hypervisor, which i do use, configurable when instantiating a new image from an iso).
i mention this because perhaps you'd like it too. in my case fedora 43 works just fine, and fast.
I'm using both fedora desktop and fedora kde and they look entirely normal, graphical desktops. i suspect (haven't verified) the UTM app wrapper is presenting access to the underlying Metal framework etc, so Fedora thinks its running on normal devices about which it already knew.
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.
i used the UTM app from the App Store, and when creating a new instance, i select the Linux icon, which exposes the selection to enable Apple Silicon hypervisor rather than Qemu. it works perfectly. and it's fast. just great. I had used Asahi before, dual booting, which was a pain in the neck. this meanwhile is perfect.
battery life seems totally fine. i believe the benefit over Asahi, for example, is that by using Apple Silicon hypervisor and the UTM macos app wrapping such, low level device drivers (including power management) are still Apple implementations.
tbh I don't mind it so much on corporate blogs, it mainly grinds my gears when people choose to do it in (what would otherwise be) more personal writing.
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.
I worked at Linaro, who was contracting for Qualcomm. Qualcomm were pushing for some protected hypervisor called Gunyah (which had its own Linux interface and needed a new qemu port) that apparently no one liked. I tried to port it to KVM [1], but upstream folks (mostly Google) outright rejected the port. Otherwise KVM would have been available on QCOM boards. You can still try it. I have a Linux kernel and a Qemu port on my github [2,3]
Upstream would accept a patchset that exposed an independent Gunyah-specific UAPI (why not the same one as downstream — crosvm already supports that) instead of pretending to be KVM (it's not a "port", you can't port a hypervisor to a hypervisor).
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!).
That's not how operating systems work. KVM is both an interface and a hypervisor. Just as we have different hypervisor implementations for amd, intel, arm and others all abstracted behind the same KVM interface, there is no reason the same can't be done for Gunyah. Userspace does not have to know anything about that. KVM already supports svm and vmx for amd and intel on x86. Why is something similar can't be done for Arm? Plus now there is pKVM.
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.
MS Windows had an exclusive period for X1, but Google will support Android and ChromeOS on Qualcomm X2-based devices in 2026, which would require the pKVM/KVM hypervisor used by Android, https://news.ycombinator.com/item?id=45368167
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.
I explored their site, but they only list supported devices, not supported CPUs, which leaves me guessing, whether their OS even works on this CPU. And since I don't really know that, it seems to be a lot of effort needed to use their tooling for non-supported devices, to make an installation image. Though I have not tried that yet. It only made me doubt, whether I could succeed that way.
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.
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?
Oryon v3 is designed for actual PC usage, not phones. But they aren't shipping until H1 next year. This is just a heads-up memo about Linux support, in that regard. Which is nice, I guess?
Yeah, that's the model laptop I've got. It's only where it's at because of a small group of community members working on it, it took ages to get where it's at now and I still get random reboots when doing basic things on Linux. It doesn't inspire much hope for future snapdragon laptops.
Interesting. What kernel and distro are you running? It's been my stable daily driver with Linux 6.15/6.16/6.17 under Void Linux. It happily runs KDE and Vivaldi for me, with a few PWA's (Slack, Zoom) to bridge the gap of no closed-source software targeting aarch64.
Ubuntu 25.10 and kernel 6.17, which was advertised to support this laptop. I'm not doing anything crazy with it when it randomly reboots. Just mundane things like file management.
I can't say that I've ever seen that on mine, but it seems to be a real crap-shoot with the x13s. Some people in #aarch64-laptops have random crashes all the time, others (like me) have a completely reliable system. It could be something weird that Ubuntu is doing with the kernel.
Just in case anyone's tempted to buy one of these now: Support is alright after heroic (and continuing) efforts to improve platform support, but it's flaky. M1/M2 devices offer better performance and the state of Asahi drivers is much better, particularly around audio.
> 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.
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?
EL2 is coming by default on Glymur (X2E) (yaaaay), can be enabled in config on some IoT platforms, and can be booted into via Secure Launch on previous compute platforms (Hamoa/Purwa aka X1E/X1P, SC8280XP), search for slbounce.
On phone platforms.. probably not? Or Android might want it for pKVM..
I was going to write a snarky comment, but in the "if any of Qualcomm leadership is listening" I'm going ask a question:
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?
Qualcomm actually contributes code whereas Apple's contributions begin and end at "you can boot software not signed by Apple". It's hardly a comparison.
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.
Snapdragon X Elite laptops have been out for the last two years, if not more. How much has Qualcomm did over this time to make Linux work on those devices - almost nothing. As of 2 months ago, the best you could do was a special cut of Ubuntu that kinda sorta booted on those machines and required Windows to be present in order to pull some drivers.
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.
Eh. The CPU might be supported in Linux, but all of the rest of the hardware to make a laptop is left dangling in the wind. Look at the X1E laptops to see how far "upstream Linux support for a CPU" gets you.
They aren't targeting enthusiasts with this announcement.
X1E laptops have fully working DisplayPort+USB3+USB2+PD over USB-C unlike Asahi Macbooks :p There really aren't that many gaps in X1E laptop support left.
Please don't engage in political battle on HN. As moderators we make an effort to protect people in all countries from being attacked for the actions of their government, no matter which country they're in. We think it's important for HN to be a place where people can be respected as an individual and not treated as an avatar for national stereotypes or the actions of their government. With that in mind, please don't initiate these kinds of battles here. We wouldn't tolerate others initiating this kind of thing against you, and we equally can't allow you to initiate it against others.
Please don't perpetuate political battle or make personal attacks on people on HN, no matter how right you are or feel you are. The topic of this thread is "Same-day upstream Linux support for Snapdragon 8 Elite Gen 5 mobile platform". Let's keep comments on that topic, and definitely not pollute it with personal attacks on individuals over the actions of their government. In case there's any perception that I'm "taking sides", I've replied to the commenter who initiated this subthread too, but it's not OK to reply to a bad comment with another bad one.
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.
not all true. And Qualcomm taking over EL2 is optional now
What is not true?
EL2 is still locked down for the chip this post is about, AFAIK. And everything else is is staying locked.
AFAIK Google runs their own EL3 on the Snapdragon Chromebooks. (And KVM at EL2)
Lots of this is customer dependent but what you say is true for the typical android phone config that most use
The Snapdragon Chromebooks use older chips that didn't have the locked down boot-chain yet. Even if you didn't have the official EL3 unlock that Google got, you could still get into EL3 trivially if you wanted to.
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).
> 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.
> ... 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?
It matters when you're doing custom hardware, or when you're designing a product where boot speed matters, or when you need to implement something special.
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
Aside from the sibling comments, it also matters that you need to be able to review it if you need to build a truly "secure" product. History is littered with broken, unfixable secure boot implementations.
Because a computer isn't just a processor. It has to interact with an EC, IO controllers, and whatnot, and if you don't have control over the boot chain, all of that stuff becomes an even bigger PITA than it already is.
> And don't even get me started on Gunyah and
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
Awesome, that's great to hear. Now if Qualcomm would only relax the walls between their business units, their other customers could benefit as well.
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.
Thanks for the constructive framing. My gut reaction was "great job, you're doing the minimum"
If I was to guess, id say someone did this as a side project at QC because maybe they like FOSS and want to give something back. Given the partnership between QC and MSFT for laptops and Google for android, I won't be surprised if we never see interest from QC for any real linux hardware.
They hired Linaro (Linux Consultancy) for it so not just a side project
Second best, after Apple.
Apple, whose FOSS support is reliant on volunteers reverse engineering their shit?
This is much better than that. Not great yet, but much better than that in comparison.
Comparing the chips, not the software, Apple's chips are better than Qualcomm's.
I agree Qualcomm's support of open source is better, while still leaving a lot to be desired.
I guess you were specifically replying to the last paragraph; that wasn't clear to me at all. A quote would've helped :)
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?
https://en.wikipedia.org/wiki/Qualcomm#2015–2024:_NXP,_Broad...
Yeah that page smells like a pr stunt.
Go all in or go home, qualcomm.
You'd rather have nothing it seems.
It doesn't matter much anyway, at least at this point.
Qualcomm did this in 2024. They pushed some patches to LKML, and issued a press release to brag about it. (https://www.qualcomm.com/developer/blog/2024/05/upstreaming-...)
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.Interestingly, Valve hired Igalia to reverse engineer (successfully) Qualcomm's shit for their upcoming VR headset.
Isn't Tuxedo jus a white label reseller?
White label reseller isn't really the right term. They don't design most of their components and buy them wholesale, but they do assemble them and most relevant to this particular comment thread, they do a lot of the device firmware and support stuff.
It's exactly the stuff that they actually do themselves that Qualcomm has been making very hard.
>Yet 2 days ago, Tuxedo Computers announced they were abandoning Qualcomm due to crap support. (
Does Apple offer better support? Qualcomm offers commercial support. I guess Tuuxedo Computers didn't pay for the support?
Apple is a non-sequitur. Tuuxedo is giving up on Qualcomm in favor of AMD and Intel.
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.
Apple doesn't actively lock and act hostile towards the reverse engineering folks. They just do their thing and sometimes do small jests to allow these folks to boot anything they want and play with the hardware.
...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.
if you are in the business of buying parts, assembling them, and selling the assembly under your brand (as tuxedo and others like them are), then Apple is a indeed not an option. Their chips might be the best, but you still can only get them in Apple devices, in the specs Apple provides and with no official support for any OS beside macOS / iOS.
That's true. What I wanted to point out is the fact that the most tightly integrated and arguably the most locked down platform on the market is more open than a platform designed to be adapted by others and sold by many.
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.
Your expectations are so comically low that I hold you in direct contempt as a user of "Hacker" News.
I would not make ad-hominem attacks to people who I don’t know anything about.
Macs have an open bootloader that allows users to run an unsigned OS like Asahi Linux (without having it degrade security when you do boot MacOS).
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:
- 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'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.
Incentives trump feelings for publicly traded companies 99 times out of 100. People constantly anthropomorphize them, but they aren't people (regardless of similarities in the law), and they definitely don't act like people, at least normal ones. At best, you can view them as something like a sociopath. I wouldn't look at a sociopath acting nicer and think "oh, they turned over a new leaf" because they aren't just going to change how their mind works, I'd think "oh, they found a reason to act in a way I like for the time being. I hope it isn't short lived."
I like to call them slow-AI. They are paperclip optimizing AIs. No single component wants the larger outcomes, yet they happen. These slow-AIs are terraforming our planet into a less habitable one in order to make GDP number go up, at any cost.
The slow AIs are driven by consumer behavior. Paperclip optimizers die pretty quickly without demand for paperclips.
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).
Corporate propaganda is driven by consumer-blaming.
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.
I've said for years that the market itself is the best real-world parallel to skynet, not some AGI or superintelligent machine.
People changed environment even before these optimizations. I think now it's more a problem of fast enough "catch-up and converge", for example for CO2 : https://ourworldindata.org/grapher/co-emissions-per-capita?c... - if the rich countries would reduce a bit faster (using better technologies) then those technologies could be used by the others and impact would be reduced.
It would be great if we could engineer our way out of this situation, but we can't. For many years I strongly believed in our cleverness, after all I was clever and in the narrow domain I worked in - tech - cleverness was enough to overcome most issues. So why not human climate change?
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.
> It would be great if we could engineer our way out of this situation, but we can't.
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.
Our viewpoints don't seem that far apart and thanks for the nuanced take. Personally I believe we know that technology can't fix this by definition because the problem is of social, cultural and economic nature. Our lifestyles are woefully incompatible with a 100k year horizon, even a 100 year horizon in many areas. Our perception of wealth depends on never ending growth, our welfare systems depend on never ending growth, our economies depend on never ending growth. It seems implausible to the point of impossibility that our economies can grow forever [1]. Technology is good at reaching goals e.g. going to the moon is unlikely without science and technology. But in this case the problem is the goal itself. Technology won't motivate us to let go of our conveniences.
[1] https://tmurphy.physics.ucsd.edu/papers/limits-econ-final.pd...
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.
Driver update depends on your OEM. Both ARM and Qualcomm send driver updates for their premium and upper highend Socs. The support reaching your phone is on the OEM. Google has started to push direct GPU driver updates starting with Pixel 10. So, hopefully others may follow too.
Usually GPU vendors (Nvidia, Intel, AMD) provide a way to download and install drivers manually (on Windows), including specific versions or older versions. Qualcomm is an outlier in this case.
No more: https://www.qualcomm.com/developer/blog/2025/05/introducing-...
Note that those drivers usually only work well in desktops, on laptops the GPU might have gone through OEM adaptations on the motherboard integration, and a driver from GPU vendors might have issues.
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.
It might be more fair to say that there's simply no standard way to do power management for discrete GPUs in a laptop, or to integrate such power management with Windows and whatever power management it's trying to do. And the lack of a clear "right" way to do things means laptop OEMs use this area for product differentiation with their own shitty special sauce software and firmware hacks.
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.
I've used basically every Windows on Arm machine - I actually quite like my X Elite ThinkPad T14s Gen6, compared the the X13s - feels like they got everything right, that the X13s got wrong
The very first they got wrong is how hard it is to buy Dell XPS with Linux on most European countries.
Naturally nowhere to be found on PC stores, and online I never found it on sale in the Dell store.
Why would you want to do that anyway?
Because that is how normies buy computers, duh?
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.
Why would normies want to buy a Linux laptop?
Year of Desktop Linux beyond 3% after 30 years.
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.
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
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.
In the case of Linux, that issue is solely because of non-upstreamed drivers. With that, it can be a first class citizen just like any other processor.
It's second class on Windows because it doesn't support game DRM and generally performs worse for the price than an x86 laptop. About the thing it really has going for it is better battery life. Using Linux doesn't really change either of those problems, though it does get you away from the mess that is Windows 11.
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.
10y old laptops are still powerful enough for my usage. So a bit more battery life wouldn't hurt me if performance of an arm system provides at least as much in term of performance.
I am pretty sure 99% of the population is in the same situation.
The situation was 99% of Windows laptops sold ended up being the much cheaper x86 ones or similarly priced ones with more performance.
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.
A businesss decision would be great. What would suck would be a marketing decision.
Today’s marketing decisions are tomorrow’s business decisions.
Today's marketing decisions are tomorrow's deprecations.
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.
> Microsoft leads the adoption of the Snapdragon X, having integrated the platform across much of its Surface lineup
https://www.microsoft.com/en-us/surface/devices/surface-lapt...
it makes some sense for embedded stuff, linux is only continuing to gain ground there.
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.
Software-wise: Ubuntu Touch, PostmarketOS, and Mobian are all actively maintained. Ubuntu Touch uses Lomiri as its UI which is somewhat bespoke (though they're working on disentangling it from the distro for packaging elsewhere), the others use various mobile Linux UIs (and there's a surprisingly large variety of options there).
Librem5 and Jolla are actively developed
> 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.
Can't say about windows, but Linux is spotty despite the loud announcement about official upstream Linux support
https://www.tuxedocomputers.com/en/Discontinuation-of-ARM-no...
Are you sure? I've recently watched a video where presenter mentioned how Lunar Lake based laptops are better then any Snapdragon.
For example https://www.pcworld.com/article/2463714/tested-intels-lunar-...
Well, in your article it already clearly states performance tanks as soon as you go on battery. By 20-40%..
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...
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.
Fully agree. When I said "consumer linux landscape" & "personal computing platform" I was thinking much more broadly than desktop PCs.
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.
Many of those markets have no issues already, as they have NDAs and deals in place.
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).
Get a DGX spark.
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
This might sound silly question, but those of you who have digits/spark machine, has anyone run Fedora on it? I kind of ran away from Ubuntu back to Fedora because reasons. Bonus question, far-fetched, steam and games with FEX?
Steam gaming with FEX is possible on the DGX Spark. The GPU is approximately a mobile 5070 with much less memory bandwidth. The CPU cores are relatively weak, especially after the instruction set translation overhead. There's a lot of stuff that's playable, but the performance is laughably bad for a $4000 machine.
FEX wouldn't affect GPU side of things though. Also, it's a machine that fits into one and a half hand. I'd call it alright for what it is actually in the context of the size.
FEX is relevant to real use cases because a lot of things that would be GPU-limited on an x86 machine can become CPU-limited when running on DGX Spark. The overhead of x86 to ARM translation, plus the low performance of the ARM cores, plus the overhead of WINE all add up to Windows games running on DGX Spark sometimes being CPU-limited and under-utilizing the GPU.
Fedora boots ootb
And, any other options or recommendations if I don't need the huge GPU?
Seems like the middle ground between SBCs and huge servers is a bit underserved in ARM...
Oh that's a good shout. A friend did get one of these so I'll go take a look at it and see what it's like.
Is it easy to buy a DGX Spark?
My microcenter has nvidia OEM flavor in stock. There are also flavors from all the other OEMs that differ slightly on cooling but mainly on chassis design.
It seems incredible but uhm, way out of my mitteleuropaishe budget
Does this actually translate into any kind of probability of a manufacturer making a device with this chip?
I don't think this changes the game as much as you think.
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.
How is Asahi not native?
The drivers, while impressively reverse-engineered, are basically alpha-quality by Linux standards. Even well-studied M1 machines will have spotty support in comparison to what an OEM can provide officially.
Those that are implemented have been very reliable in my experience, I think that labeling them “alpha-quality by Linux standards” is a ridiculous claim
Then you need an Intel or AMD laptop as a frame of reference. M1 is implemented as-is with much of the silicon's onboard accelerators entirely dark. Hardware accelerated video encode/decode is a lost cause, Thunderbolt will likely never happen, NEON is your fastest SIMD accelerator and cpuidle is still not really figured out.
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.
There's a big difference between saying that many of the drivers are missing entirely, and saying that the drivers that exist are alpha-quality.
+1. Been running Asahi Linux for half a year now. Everything that's advertized as working is working great.
my dude no. https://asahilinux.org/docs/platform/feature-support/m1/#tab...
even in the m1 there are 4 WIP in the support table, 2 TBA and 10 non mainline boxes for the M1 pro
> Those that are implemented
Asahi is also still a platform with a huge pile of out of tree patches on top because the platform itself is pretty unusual, requiring for example, a 16K page size kernel which is unlike pretty much every other arm Linux platform.
Presumably OP meant a Linux distro using a normal upstream kernel?
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.)
Qualcomm has several full time employees working on Mesa (Freedreno/Turnip). They probably must have access to some documentation now..
They've been working on better mainline Linux support for a while now, but their last generation is still catching up on the driver side of things.
I hope they succeed but the last generation has only recently become mostly usable for specific distros. General support may take a while.
I just checked: Frame is Gen 3 and the article is Gen 5.
I am really hoping Valve will release a Frame Pro with Elite Gen 5 later :(
Maybe eventually, but Valve don't tend to update their hardware very often so it'll probably be a while. They went over 6 years between their last VR headsets, and the Deck is over 3 years old now with no hint of a successor coming (the OLED version is more recent but that was a minor iteration with mostly the same specs).
I care a lot more about the screen resolution than the chip. The Steam Frame would make a really cool Linux workstation if the pixels per degree on the display matched typical monitors. Unfortunately, the resolution would have to be much higher than it is.
The frame uses X Elite, their SoC designed or Laptops. These drivers are for mobile Line. Yeah the naming can be quite confusing.
the frame is using a standard mobile snapdragon 8 gen 3 with ARM designed cortex cores.
The 8 Gen 3 also still uses the previous tile-based A7x GPU architecture, while newer chips use the "A8x family of GPUs based on the new Slice architecture".
It wouldn't surprise me if they're full of binary blobs
They are, but that's hardly unique to Qualcomm. Tons of hardware with "proper" upstream Linux drivers still requires closed-source firmware blobs, and in particular with anything wireless that's probably an unwinnable battle due to regulatory constraints.
Closed source firmware is one thing that actually runs outside the Linux system... but there's also the user space libraries that are needed to interact with the drivers (eg libgl etc... or the vendor partition in most Android phones)
I don't think anyone expects non specialized os images to run on this hardware. That would require a standardized userspace abstraction layer like the one Android has been building out. The kernel is just a tiny piece of what's necessary because drivers have effectively moved into userspace. Graphics is the only area that has embraced this properly in "desktop Linux"
>That would require a standardized userspace abstraction layer like the one Android has been building out Can you expound on this? And can desktop linux take advantage of it or do something similar?
The android hal situation is tied to binder and a lot of androidisms. It would be a pretty big shift in culture to adopt that stuff into desktop linux. ChromeOS is likely rebasing on top of android in part to take advantage of the bsp layer abstractions android provides. A proper organization needs to be formed to take on this challenge and I'm not sure any of the existing players are well equipped to lead the charge. Valve and other os distributors who want to ship arm products should be sufficiently motivated though. Most just end up choosing to build on top of Android though because it's easier.
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.
They had to hire Igalia to have decent GPU drivers.
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?
https://www.windowscentral.com/software-apps/how-well-does-w...
Apparently WSL2 does work, it pulls a native ARM64 Linux distro and then proceeds as usual.
I have the 8 gen 3 and wsl and hyperv work fine just can't really use x86 binaries / containers / operating systems.
I think the performance of x86 VMs would be pretty poor anyway due to the high overhead of TSO emulation. Windows ARM doesn't have the benefit of hardware assistance like macOS does, and the tricks that Microsoft came up with to mitigate the impact rely on metadata that only MSVC emits, so anything compiled with GCC or LLVM would always hit their emulators slow path.
> Windows ARM doesn't have the benefit of hardware assistance like macOS does
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.
Yeah it does seem backwards that Apple was the most on the ball with this, when their MO is to force developers to migrate to their newest platform in short order, while Microsoft will be stuck dealing with x86 backwards compatibility for the next 25 years.
> As far as I know, there currently are no options for lightweight tablets that support Linux.
Does this count? https://puri.sm/products/librem-11
560g is fine. But I wouldn't want to work on a 11.5" device. Something between 13" and 14" is my preferred size.
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.
PureOS has minimal differences from Debian in that they (a) remove all non-free components to get the FSF endorsement and (b) add not yet upstreamed drivers and features, https://puri.sm/posts/how-to-be-upstream-first. So Debian should work sooner or later.
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.
The Linux support on the X1E today is lacking. I’m much more optimistic for the X2E.
The hardware is great, though, I love the 12” Surface with the X1E. WSL2 works great!
> Hardware-accelerated video playback of H.264 (AVC), H.265 (HEVC) and VP9 video streams
> 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.
The Qualcomm marketing spec sheet mentions AV1 decoding: https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets...
Maybe that part of the driver isn't finished yet?
Yes. It is on the mailing list: https://lore.kernel.org/all/20251001-av1_irisdecoder-v1-0-9f...
It actually introduces new things into the UAPI because no one else did fully-stateful AV1 decode before.
Or licensed.
Isn't the whole point of AV1 that it's royalty free, as opposed to H264/265/etc?
For the codec, sure. But there can always be more restrictions on the IP block, driver code, etc.
Yeah, and the main problem with HEVC/H265 is the patent encumbrance. Very odd, but hopefully it's just coming a bit later.
It started like that. But now there are at least 2 different patent pools that want rent.
Have they successfully gotten any?
AV1 is designed to be license free, so unless they outsourced their driver development to another company I don't think there's anything to license.
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.
I wish this signup box did not cover the text, or at least there was some way to close/remove it.
I use uBlock Origin blocked the container element, problem solved.
yeah i had to inspect element and delete the html node. theres a double-space in the first line of the top summary section.
presentation is half the message!
the year of linux on the arm desktop cannot come soon enough
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'm using Linux just fine on an ARM desktop for a long time, via Apple Silicon hypervisor enabled via the UTM macos app (which wraps both Qemu, which i don't use, and Apple Silicon hypervisor, which i do use, configurable when instantiating a new image from an iso).
i mention this because perhaps you'd like it too. in my case fedora 43 works just fine, and fast.
How does Fedora handle the graphics and audio when running under hypervisor? Or is it strictly a command-line thing?
I'm using both fedora desktop and fedora kde and they look entirely normal, graphical desktops. i suspect (haven't verified) the UTM app wrapper is presenting access to the underlying Metal framework etc, so Fedora thinks its running on normal devices about which it already knew.
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.
Ooh, thank you for this, I might try it on my m4 mac. Any tips or anything I should be aware of?
i used the UTM app from the App Store, and when creating a new instance, i select the Linux icon, which exposes the selection to enable Apple Silicon hypervisor rather than Qemu. it works perfectly. and it's fast. just great. I had used Asahi before, dual booting, which was a pain in the neck. this meanwhile is perfect.
Oh wow very simple, thank you
what's the battery life like?
do you use macos at all, or do you do ~everything within a full-screened fedora instance?
battery life seems totally fine. i believe the benefit over Asahi, for example, is that by using Apple Silicon hypervisor and the UTM macos app wrapping such, low level device drivers (including power management) are still Apple implementations.
the year of linux desktop is called steamdeck
tbh I don't mind it so much on corporate blogs, it mainly grinds my gears when people choose to do it in (what would otherwise be) more personal writing.
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.
I worked at Linaro, who was contracting for Qualcomm. Qualcomm were pushing for some protected hypervisor called Gunyah (which had its own Linux interface and needed a new qemu port) that apparently no one liked. I tried to port it to KVM [1], but upstream folks (mostly Google) outright rejected the port. Otherwise KVM would have been available on QCOM boards. You can still try it. I have a Linux kernel and a Qemu port on my github [2,3]
[1] https://lore.kernel.org/kvm/20250424141341.841734-1-karim.ma...
[2] https://github.com/karim-manaouil/linux-next/tree/gunyah-kvm
[3] https://github.com/karim-manaouil/qemu-for-gunyah
Upstream would accept a patchset that exposed an independent Gunyah-specific UAPI (why not the same one as downstream — crosvm already supports that) instead of pretending to be KVM (it's not a "port", you can't port a hypervisor to a hypervisor).
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!).
That's not how operating systems work. KVM is both an interface and a hypervisor. Just as we have different hypervisor implementations for amd, intel, arm and others all abstracted behind the same KVM interface, there is no reason the same can't be done for Gunyah. Userspace does not have to know anything about that. KVM already supports svm and vmx for amd and intel on x86. Why is something similar can't be done for Arm? Plus now there is pKVM.
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.
MS Windows had an exclusive period for X1, but Google will support Android and ChromeOS on Qualcomm X2-based devices in 2026, which would require the pKVM/KVM hypervisor used by Android, https://news.ycombinator.com/item?id=45368167
The original Oryon systems allowed you to boot directly into EL2 and skip Gunyah via BIOS settings. I assume this will be the same.
Which ones, where? On X1 laptops that shipped with Windows, you can only escape into EL2 via Secure Launch: https://github.com/TravMurav/slbounce
Didn't ship externally/OEMs didn't take it, but the CRDs had the option.
The prototype impl at the time broke some Windows functionality
I appreciate the gesture, but... just release the docs!
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.
Tried postmarketOS yet?
I explored their site, but they only list supported devices, not supported CPUs, which leaves me guessing, whether their OS even works on this CPU. And since I don't really know that, it seems to be a lot of effort needed to use their tooling for non-supported devices, to make an installation image. Though I have not tried that yet. It only made me doubt, whether I could succeed that way.
There's a list of SoC's here: https://wiki.postmarketos.org/wiki/Mainlining#Supported_SoCs
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.
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?
Oryon v3 is designed for actual PC usage, not phones. But they aren't shipping until H1 next year. This is just a heads-up memo about Linux support, in that regard. Which is nice, I guess?
I'm still mad about their lack of support for the 8cx gen 3. It's one of the first laptop SKUs they put out and support still isn't great.
The Lenovo x13s works pretty nicely these days, EL2 support aside. What problems have you faced?
Yeah, that's the model laptop I've got. It's only where it's at because of a small group of community members working on it, it took ages to get where it's at now and I still get random reboots when doing basic things on Linux. It doesn't inspire much hope for future snapdragon laptops.
Interesting. What kernel and distro are you running? It's been my stable daily driver with Linux 6.15/6.16/6.17 under Void Linux. It happily runs KDE and Vivaldi for me, with a few PWA's (Slack, Zoom) to bridge the gap of no closed-source software targeting aarch64.
Ubuntu 25.10 and kernel 6.17, which was advertised to support this laptop. I'm not doing anything crazy with it when it randomly reboots. Just mundane things like file management.
I can't say that I've ever seen that on mine, but it seems to be a real crap-shoot with the x13s. Some people in #aarch64-laptops have random crashes all the time, others (like me) have a completely reliable system. It could be something weird that Ubuntu is doing with the kernel.
Just in case anyone's tempted to buy one of these now: Support is alright after heroic (and continuing) efforts to improve platform support, but it's flaky. M1/M2 devices offer better performance and the state of Asahi drivers is much better, particularly around audio.
See qebspil for filling the gap for the EL2 side
> 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.
Mesa MR for a8xx is coming. It's just not done yet. But they have full time employees working on Mesa.
Oh, that's good!
Of course, there would exist something like Qualcomm Linux,
https://www.qualcomm.com/developer/software/qualcomm-linux
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?
As far as I know, at least the modem support is half-baked or still non-functional.
ex-qcom engineer here, asking qcom for open source support is like asking financial advices in a casino.
let's stop being naive - qcom will not change.
Actual bare metal Linux or under a hypervisor? I thought Qualcomm used a hypervisor to isolate the Linux environment that is taken for granted on x86.
EL2 is coming by default on Glymur (X2E) (yaaaay), can be enabled in config on some IoT platforms, and can be booted into via Secure Launch on previous compute platforms (Hamoa/Purwa aka X1E/X1P, SC8280XP), search for slbounce.
On phone platforms.. probably not? Or Android might want it for pKVM..
_Current_ phone platforms still use Gunyah.
How far away are we from being able to use new snapdragon laptops with Linux?
I'm pretty keen to play around with Proton, FEX in a laptop that rivals the MBP
I’d like to see the chips powering the new Surface devices in a Framework laptop at some point. Feel like they would be perfect for the Framework 12
I was going to write a snarky comment, but in the "if any of Qualcomm leadership is listening" I'm going ask a question:
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?
How does it compare to Apple ARM M series and did they slap on a decent GPU? If not, they still got a long way to go...
Qualcomm actually contributes code whereas Apple's contributions begin and end at "you can boot software not signed by Apple". It's hardly a comparison.
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.
What's the use case here? Mobile that can use Linux instead of Android? Is that possible?
Since OpenMoko, the thing is that the market doesn't care.
https://en.wikipedia.org/wiki/Openmoko
Snapdragon X Elite laptops have been out for the last two years, if not more. How much has Qualcomm did over this time to make Linux work on those devices - almost nothing. As of 2 months ago, the best you could do was a special cut of Ubuntu that kinda sorta booted on those machines and required Windows to be present in order to pull some drivers.
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.
Eh. The CPU might be supported in Linux, but all of the rest of the hardware to make a laptop is left dangling in the wind. Look at the X1E laptops to see how far "upstream Linux support for a CPU" gets you.
They aren't targeting enthusiasts with this announcement.
X1E laptops have fully working DisplayPort+USB3+USB2+PD over USB-C unlike Asahi Macbooks :p There really aren't that many gaps in X1E laptop support left.
Docs though?
[flagged]
[flagged]
This makes no sense. Just imagine you would get handcuffed tomorrow. Collateral damage. Blame some guy. Or a gal.
[flagged]
Man, if only it were so easy to leave a country that starts wars. It's not as if the average citizen has little control over that or anything.
http://www.gutenberg.org/ebooks/26184
The price is that of a VPN subscription
https://en.wikipedia.org/wiki/Revolution
https://en.wikipedia.org/wiki/Fall_of_the_Fascist_regime_in_...
https://en.wikipedia.org/wiki/Romanian_revolution
I'd be glad it's just handcuffs and not a bomb dropping on my head.
/shrug. Try being from the UK, we don't even get imgur.
Well, that's not the same, that's well-deserved.
Because other people do bad things these people aren't allowed to share ideas.
[flagged]
[flagged]
Does it even matter with such a logic?
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
Please don't engage in political battle on HN. As moderators we make an effort to protect people in all countries from being attacked for the actions of their government, no matter which country they're in. We think it's important for HN to be a place where people can be respected as an individual and not treated as an avatar for national stereotypes or the actions of their government. With that in mind, please don't initiate these kinds of battles here. We wouldn't tolerate others initiating this kind of thing against you, and we equally can't allow you to initiate it against others.
I tried to get it on archive.is but it say in a loop forever.
Even when it's not blocked, the layout is broken...
[flagged]
Please don't perpetuate political battle or make personal attacks on people on HN, no matter how right you are or feel you are. The topic of this thread is "Same-day upstream Linux support for Snapdragon 8 Elite Gen 5 mobile platform". Let's keep comments on that topic, and definitely not pollute it with personal attacks on individuals over the actions of their government. In case there's any perception that I'm "taking sides", I've replied to the commenter who initiated this subthread too, but it's not OK to reply to a bad comment with another bad one.
[dead]