I hope Qualcomm upstreams all the device tree kernel level stuff to Linux for every laptop model. One of the things I don't like about Arm Laptops is—for example—how even if a SoC is supported upstream, if the manufacturer does not upload a device tree for their device, then you're cooked.
I read that while these Snapdragon laptops do technically have UEFI + ACPI, the information they provide is not useful for Linux and is more coupled with Qualcomm's proprietary drivers on Windows. Therefore, device trees are needed on Linux (I could be wrong about the first part).
> Needing the kernel to be changed for each device is an Androidism
It's an Armish not an Androidism. It's an embedded legacy that really doesn't make sense anymore. But inertia is powerful enough that even Apple is still using device trees, even on their M series SoCs ( https://asahilinux.org/docs/fw/adt/ )
I wouldn't call it legacy as that implies something people inherited but didn't want. The common sentiment among kernel developers has always seemed to be that device trees are nicer to work with than the complicated PC abstractions, and that sentiment remains today. And IIRC Linux didn't always have device trees; it was an approach that came later as it was ported beyond x86, Alpha, and SPARC, and was welcomed.
I'm not a kernel developer, but it seems to be one of those things that's great when you're adding support for a particular device on a particular platform, but becomes a giant PITA in the aggregate for the downstream ecosystem. It's a mismatch of incentives and preferences.
There's no universally good solution for connecting varied kernels with varied hardware. Device tree is okay.
Kernels always have to be changed for different hardware, that's nothing new. x86 kernels don't run on ARM machines, full stop. Gameboy Advance kernels don't run on Switch 2. IBM mainframe kernels don't run on AWS EC2.
As part of good engineering practice we like to separate the parts that are volatile with regard to hardware changes from the parts that are nonvolatile. But that's a kernel implementation detail and we shouldn't pretend it means the combined kernel doesn't need to be changed.
We can also embed several volatile components for several different hardware configurations. That's called inefficiency, or bloat.
There were several attempts for hardware to incorporate the volatile component itself and be self-describing. ACPI (in ROM) is one; device-tree-in-ROM is another. Neither turned out to work well, because it turns out you actually want to evolve that code and so kernels contain lists of ROM patches anyway, which isn't much better than just including whatever was in the ROM to begin with.
Someone from Qualcomm posted a "DT-ACPI Hybrid Mode" set of patches a while back that let you call ACPI table functions, etc even while booting with the device tree, allowing you to control some things like keyboard lightning/power management independently. That would be a good first step but I'm not sure it went anywhere in the meantime. In theory supporting Device Tree by including the blob in a ROM somewhere shouldn't be much more work (if any) than including working ACPI tables, but we all know how that works out in practice!
> supporting Device Tree by including the blob in a ROM somewhere shouldn't be much more work (if any) than including working ACPI tables, but we all know how that works out in practice!
This is definitely a thing in some embedded systems I’ve used. There are some Marvell boards which do this. They all use U-boot though.
The problem is that the content of the device tree isn't really stable -- if a new kernel version has a driver with a new required parameter for instance, suddenly your ROM device tree is out of date and much less useful.
Oh, that's a good point I forgot about; I suppose DT interfaces aren't considered part of the stability contract for users... Really Device Tree is somewhat "Linux-specific"-enough and low level enough that issues like this aren't ideal. But if we could just get to the point that was a problem, I'd be happier than now, I suspect!
In theory device trees are supposed to be a OS-neutral stable ABI. Being able to put a device tree into unchangeable mask ROM is an often mentioned design goal.
However, there is a fatal flaw in the process that makes this a pipe dream in reality. In Linux, these rules only apply to reviewed and merged drivers. And during review any new DT interface will almost certainly be bikeshedded in some way.
So unless your chip vendor has upstreamed ALL their drivers before a device is manufactured, the device's firmware-provided DT will very likely work only against a vendor kernel and requires updating.
Not at all, that is how all computers used to be before IBM PC clones happened, and is the world we are going back, as so many seem keen in killing x86 PC legacy, for their beloved ARM and RISC-V boards.
This is exactly what they have already been doing for the past two months, directly from their devs, posted to Linux ARM MSM mailing list, and despite not having all of the specs from manufacturers. See the EC driver submission for Asus ZenBook A16 from this past week.
I believe the Orin AGX is in a similar position. It does a UEFI boot but you absolutely have to supply a correct dtb and if you don't then key peripherals like USB and ethernet can just completely not work, or in one case I experienced, subtly malfunction in a way that appears to be fine but throws off a bunch of extra radiation that fails a certification test.
This is actually misinformed, the discussion on the mailing list made it clear: there is NO full ACPI on these Windows ARM devices; they only use ACPI marginally and still require and provide device tree.
Phoronix should have revised that article, it's completely misleading.
One option would be to implement the custom non-standard Qualcomm drivers that technically it needs to implement anyway, but with support for the UEFI/ACPI interface.
On Windows, Qualcomm ships custom drivers that override normal ACPI platform logic in various places, IIRC
Not an easily feasible option notably because the firmware ACPI tables are in part stubs - but work on hybrid ACPI/DT instead is possible.
One of the reasons is that Qualcomm uses supplemental ACPI tables (think device tree overlays) shipped inside of the driver packages. Look at the .bin in plenty of the drivers carefully and you'll see that they're supplemental ACPI tables.
Windows doesn't have such a notion and it's implemented via having an ACPI table loader statically linked in to individual drivers.
_On top_ of that, Qualcomm uses PEP to intercept plenty of ACPI functions and implement them in native code instead.
I don't think that ARM Laptops have a chance in Linux land as long as each model requires stuff like a custom DT.
I'm typing this on a Thinkpad x13s Gen1, "21BX000XGE".
I really really like the device, best laptop I've owned so far, speaking strictly from a hardware perspective.
No vents mean I can use it on a pillow, and it's dead silent. It never runs hot, great battery life. Thin and light, yet has all the performance I need.
But would I recommend the laptop to any fellow Linux user? Absolutely not.
Even though it was released in 2022, the webcam still won't work.
I can't limit the battery charge to 80% like on my x86 Thinkpad.
There was a time when the graphics driver and Chromium didn't like each other and I had to wrangle Chromium into software rendering mode to avoid heavy artifacts on the screen (export force_gl_vendor="notfreedreno").
In fact, I still have the workaround in place. Not sure if it's still needed though. A fix was merged upstream last year, need to check whether it made it into Fedora yet.
I got the machine in 2025, and here are the workarounds and config changes I had to make just to get Fedora running last year, 3 years after release:
- extra kernel arguments ("arm64.nopauth" seems to be needed still in 2026, "clk_ignore_unused pd_ignore_unused" I have been able to remove at some point)
- initramfs modification, /etc/dracut.conf.d/x13s_firmware.conf: install_items+=" /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn.xz /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn.xz /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn.xz ". Not sure if these are still needed, they were at some point.
In late 2025, installing Fedora was still a pain in the butt.
There were custom-built ISOs for my device, but they didn't work because my firmware was too new. Stupid me ran a firmware update on the preinstalled windows.
I tried building my own ISO, but the firmware never recognized those as a boot device for some reason (I have successfully built custom ISOs for x86 many times).
In the end, I was able to use QEMU + chroot on my x86 machine to install Fedora ARM onto an external HDD, make the needed modifications in there, boot that on the laptop and run the anaconda installer, then make modifications to the install on the internal storage.
I just ran a quick `wc -w` on my installation and debug notes for the machine, and it's a cool 11180 words.
At some point, it turned out that the display my unit uses was not in the list of known displays for the x13s. Seems that was mostly inconsequential aside from a kernel warning and maybe slower wakeup. Helped upstream with that, which eventually resulted in this commit: https://github.com/torvalds/linux/commit/3330b71caff6cdc387f...
I'm no stranger to exotic architectures and machines, having used Gentoo on a ppc64le machine as a daily driver for 3+ years. And I do like the laptop. But w/o fundamental improvements to the way ARM bringup works, not just improvements for individual machines, I wouldn't recommend this stuff to any unsuspecting user.
I've been working on embedded systems using iMX8s, and it's equally awful. You have to maintain your own fork of UBoot. You have to spend hours tweaking device trees. The "NXP" kernel is out of date and never updated, the mainline kernel is missing loads of drivers.
Meanwhile in x86 land you can just download a distro and boot it. Secure boot works out of the box. It's night and day.
Yup. I remember my dismay when I started working with Linux on arm boards and realizing the absolute massive gap between the hardware vendor claims of "full linux support" and the reality.
Sometimes the SDK is a zip of the developer workspace in a pseudo working state with no clear records of all that's been patched.
Vendors providing binary only kernel and system images containing god knows what is not uncommon either.
I'm convinced now that arm hardware vendors are simply incapable of even understanding what proper software support is. I'm sure some of their devs do their best but management does not care. By the time the chip ships, efforts move to making the next thing so they never properly finish the software side.
Linaro is (or was, back when I was involved ~10 years ago) non-profit sponsored by SoC vendors to develop, maintain and upstream SoC support for Linux, along with running a comprehensive validation lab for all the boards they support.
A list of manufacturers did change a few times, and it was half-sponsored by ARM directly.
Every time I have watched Linaro presentations, I mostly got the feeling that their customers so top speak are embedded (Automobile and co) and Android OEMs, not so much people that would like to some day have GNU/Linux on ARM desktops/laptops.
Even rather mainstream stuff like the RPi can get wonky in places, and still people comment on why "idiots" buy RPis when this-or-that ARM board has 10% more bang for the buck.
Eh, yeah, of course. I'd love to only ever run RandomShenzenCorp's heavily patched vendor kernel from 2016.
I don’t hear people suggesting to replace an RPi with a similar device (OrangePi or what not).
What I hear a _lot_ is that the thing could have been an esp32 (or Arduino rarely).
That’s a way wider price gap. I can order Costco-sized lots of esp32’s for the price of a single RPi.
RPis pricing has really, really narrowed the space where their products make sense. Low power devices can be esp32, high power can be x86 NUC things (or interconnected esp32s if you need tons of pins).
I don’t encounter a ton of things in “too big for an esp32 but I’m positive I don’t even want the option of a beefier x86 CPU”.
No hate if it works for you. I don’t even dislike RPi, they’re just in a narrower band for me these days.
Just in case anyone unfamiliar reads this, the way to run ARM boards is e.g. https://armbian.com/ (or NetBSD, Debian, whatever you prefer) and never the vendor junk.
RockChip stuff tends to have good support, and in fact I'd trust it more to have good support than Raspberry Pi (Broadcom). When in doubt, check or wait before buying in any case. In many cases support will not meaningfully improve from how it was at release (learned this one the hard way) and most ARM devices are e-waste. Try not to get excited about theoretical hardware specs either, they might as well be fake because of how poorly the majority of ARM stuff actually works. Go for known good software support and then upgrade to new hardware when you find something newer with known good software support a few years later.
This is tragic to read. An ARM-based Thinkpad ultrabook running Fedora on it would be a "forever" device for me. I adore my X1 Carbon Gen7 but the battery life could definitely be better and I could stand for it to run a little cooler.
It's sorta funny, the existence of Windows' stranglehold has worsened so many generations of thinkpads. The push for the S0 mac-style standby made my 11th gen X1 carbon basically unusable for me in Linux.
The standby battery life is so bad, it will burn through half the battery overnight with the lid closed. The battery life actually seems better when using the laptop opposed to standby.
Other standby modes were removed on a firmware level by lenovo despite the processor supporting it.
I still have my 4th gen X1 carbon, it was an amazing machine for 8 years and I really thought I'd get another 8-year laptop buying the latest X1, but now it sits off and only comes out for specific uses. Bought an m4 air for day-to-day laptop use.
I also have an X13s and it's also the best laptop I've owned... Sort of.
I ran Windows on it up until a few months ago and it was as you said, delightful. Long battery life, fanless, great size, great screen. I put Ubuntu on it (where they've mainlined a good bit of things), and it's still just not very good. Sleep doesn't work (and never will without Qualcomm), certain things still just crash on occasion -- but I do think the webcam works.
I'll likely put Windows back on at some point, which is a shame, because the laptop is great, but Windows is terrible. I simply do not believe any claims Qualcomm has about future support, as much as I'd love to see a newer Thinkpad device with full ARM support.
This is depressing, I just got this x13s hoping to give this arm craze a try as supposedly it has fairly full Linux support. I will just ignore any claims about Qualcomm until Dell or Lenovo release models with Linux pre-installed and they get real world reports over time.
Whew, thank you for this summary. I just got this laptop as it seemed to have "good" Linux potential, but I've been stuck so far. And as further caution to others, hibernate doesn't work on Linux, and audio is glitchy. Even on windows 11 pro the shutdown menu is missing. It seems to sleep on windows but not sure about battery drain, which is reported to be 1-2%/hr in Linux.
In theory. This up to the manufacturers and they're not doing that, so it's quite different from non-ARM laptops, where this is basically standardized.
It's not necessarily any better on Windows. I've worked with Qualcomm based laptops that wouldn't work without a bespoke Windows image from the manufacturer. I also had one where the "generic" ARM Windows image wouldn't work with it even though it should've and the manufacturer never provided a bespoke image.
Even the Surface Pro doesn't work well with the generic image. I had to go get the Surface Recovery one to get it work enough to go through the install because there was no support for the touch screen or the official Surface keyboard on the generic one.
People in the thread who have actual experience on actual hardware and software are telling you how things actually work, not some farcical idea of how it theoretically works.
This sounds like a terrible situation, but I wonder if a weekend of Claude iterating could improve on any of these problems. They seem to have been pretty successful on the Mac M series.
I'm sure Claude would be capable to solve many of these. But the next machine probably requires the whole dance all over again, and it just doesn't scale very well, I feel.
> One of the things I don't like about Arm Laptops is—for example—how even if a SoC is supported upstream, if the manufacturer does not upload a device tree for their device, then you're cooked.
Why? Downstream vendor kernels generally use device trees and they can typically be easily extracted and decompiled for cases where the vendor is not GPL compliant and hasn't provided sources.
I've ported arm board device trees to mainline based Linux myself, porting the device tree has not really been the hard part in general...if mainline already has the necessary drivers.
The bigger issue tends to be that vendor kernels have a bunch of drivers that don't have upstream equivalents. I've been porting a lot of Allwinner ARM SoC drivers recently for the purpose of mainlining board support and it has been quite involved as Allwinner downstream kernels very heavily diverge from their mainline equivalent versions and are often based on 10 year old kernels. Even with Allwinner vendor sources(which are typically available in some form from BSP releases floating around on the internet) the drivers typically need to be fully rewritten due to Allwinner doing things in ways that mainline wouldn't accept. Luckily LLM's are quite good at this sort of porting work since they can ingest lots of garbage vendor driver code and create mainline variants(although there's usually substantial review/refactoring needed to get these merged upstream).
Often one also needs to port the drivers to uboot as well, in many cases one can mix a vendor uboot with mainline kernel but that doesn't always work properly(i.e. for Allwinner you generally can't boot a mainline kernel from vendor uboot and need to port uboot as well).
One other issue I've run into is that mainline Linux doesn't have great support for dynamic hardware probing which is often needed when vendors have different minor hardware variants that are all expected to use the same software builds. For example Allwinner on some SoC's will use a different co-packaged EPHY depending on the SoC revision which requires dynamic hardware detection via efuse probing. In other cases one may need to say detect a touchscreen device and driver by probing i2c addresses, mainline Linux has some support for this sort of thing but it's not particularly mature so sometimes one needs to do the hardware detection in uboot and patch or conditionally load device trees and/or device tree overlays which can be a bit involved.
Maybe I'm wrong, but I feel like creating device tree should be relatively straightforward if driver support is there. So while having official device tree is awesome, it's not something that's very hard to do. Now writing drivers without datasheets, using reverse-engineering is something that's hard to do.
I've been waiting for someone to write a DTS for a Snapdragon(R) X - X126100 - Qualcomm(R) Oryon(TM) CPU based laptop I bought over a year ago. Some people are trying but it can't be that easy ... Starting to look into doing it myself and AFAICT it requires reading the ACPI tables (written for Windows drivers), and manually converting it to devicetree, test, tweak, repeat.
This is one of those situations, even if they don't want to release specific code, they could at least release the specifications so that others could build the software stack for this.
I think a lot of people don't realize the level of performance Qualcomm has reached with these. This is the closest competition to Apple's M series that we have, for the laptop form factor at least. They are better than Intel and AMD's best. I'd love to buy an X2 laptop with Linux preinstalled and supported.
This. The X1 Elite laptops came out 2+ years ago, but you still need to use a special Ubuntu remix to get everything* working, and support is very dependent on which laptop you bought. You could say it’s not Qualcomm’s job to make audio or the camera work on every Lenovo/Dell/HP, but someone needs to do it…
*: I’m sure there’s some features that still aren’t working right.
I’m glad we’re finally getting more competitors to Intel/AMD.
Better for everyone. Apple gets lazy on top. And for those who don’t want a Mac, they should be able to have something great too. And since PC makers are far more willing to experiment with form factors, I’d like to see what they try.
If Apple was lazy, they wouldn’t have spent five years getting rid of Qualcomm modems, Qualcomm is also getting squeezed by the Chinese, Mediatek, Microsoft, Nvidia, Samsung and Apple worldwide.
It will be interesting. because Qualcomm doesn’t give away anything for free, so any of those Linux Distro’s who thinks it’s going to be a free lunch? Are gonna be in for a surprise.
They hate being under someone else’s thumb and Qualcomm had real control over that. They couldn’t stand it and wanted out. Which is just as well, because clearly Qualcomm could’ve been doing better. Apple cut the power usage of the chip and it’s reportedly better than the Qualcomm one.
> It will be interesting. because Qualcomm doesn’t give away anything for free, so any of those Linux Distro’s who thinks it’s going to be a free lunch? Are gonna be in for a surprise.
Care to postulate on what those nefarious reasons/surprises could be?
Onavo is correct: Qualcomm are extremely notorious for aggressive IP enforcement. They're the Oracle of hardware. In particular they held critical CDMA patents which were required for making a modem which worked in the US.
They (along with Intel) also ended up making most of the non-Apple ARM chips, which are not competitive with the Apple ones.
Imagine NVIDIA on steroids. Think bad documentation, opaque code, and everything being locked down. The customer gets squeezed for more money (especially egregious if you don't have enough scale they won't even bother engaging).
If Apple cared about quality, they wouldn't have gotten rid of Qualcomm modems, and forced people to use the inferior Intel modems. I always avoided by iPhone models with Intel modems starting around the 6S era.
A20 Pro P-Core is the largest jump in performance per watt in the past 5 years. I am not sure why Apple is lazy in their hardware front. Not the same could be said about their software though.
Let me appropriate and rephrase a sentence from earlier in the thread: "performance per watt doesn't matter at all if the combination of the machine's feature set, both in hardware and software, as well as form factor, is essentially useless to you".
I have seen this far too many times on HN. A design that put Performance Per Watt first is how you extract more multicore performance when you are fundamentally limited by cooling.
Gud lorde, don't be daft. PPW matters until it hits a point where any optimizations above that line are of much less importance to some people (e. g. me) than other specs. Not to speak of necessary attributes completely absent from your PPW dream machine, which indeed negates PPW considerations on a per device/device-class basis. Which excludes optimizations for microprocessor series. It ain't rocket science.
basically: "I want WSL for my overpriced toaster, I'm totally fine with the keyboard lacking most of the essential keys, pretty please. whispers expletive against Apple whilst making sure no one can hear him"
ARM is a fragmented mess compared to x86. Switching to ARM (right now at least) means losing the ease of x86 booting. In the x86 world, trying another Linux distro is as simple as downloading it and putting it on a USB stick. You can be 95% certain it will work. In the ARM world, nothing is standardised, nothing will ever work first time.
There are projects trying to tackle it, but compared to x86 it's a fragmented mess. That's what we're losing with ARM laptops - universal computing.
One key frustration is it’s typically not possible to have an arm distribution that boots across most arm boards, because they have incompatible boot loaders. Ie you have a raspberry pi image and a banana pi image and an orange pi image and the rock pi S image that are all different from each other. There have been some attempts at UEFI on arm that would address this, but it’s nowhere near as consistent or compatible as on the x86 platform side.
But that's not answering my question? What do you expect to get from today's ARM chips that's fundamentally impossible otherwise? And how is that a step forward?
I know I will never switch to ARM willingly. There is no advantage, only vendor lock-in. I feel that x86's openness was an accident, and we should try to keep x86 alive as long as possible.
It actually was an accident, enabled by IBM using off the self parts unlike their previous computers, and Compaq's clean room reverse engineering of the BIOS.
In the ARM world, that other part you are completely ignoring isn't standardised, even with device trees, they only help to alleviate the pain that each computer is its own OEM snowflake.
The comment you're replying to is implying that in an ARM world nothing is standard, portable, or compatible by default. Think about smartphones: Every single one a bespoke board with bespoke hardware.
In ARMland, there's no such thing as standard OS images you can install on any machine, or generic components that users can buy and install themselves.
I'm more on the Apple hater side, but they getting lazy is simply not true.
For many years Apple dominates the Laptop hardware scene, and while there is no comparably performing competitors threatening them, they keep releasing newer, faster, more efficient chips. After using many operating systems, I know that for sure I don't want MacOS, but the hardware itself is hard to beat.
>And since PC makers are far more willing to experiment with form factors
What are you thinking of here? ATX is from 1995 and ITX from 2001, since then we've had stuff like the lamp imac, trashcan mac pro and nowadays the finger-thin imac and tiny mac mini from Apple.
I had Fujutsu laptops that were far lighter and smaller than Airs, touchscreens in the late 90s, convertibles, 2 in ones, touch bars (Thinkpad). Plenty of designs that don't build around ATX type specs, and things that do (open frame cases, and the vast array of expansion cards that benefit from it). PCs that snap onto a monitor. Things Apple copied or hasn't gotten around to yet then claim then as revolutionary. Apple has more integration and can be more strategic (when they don't need bailing out), but as one company they do far less exploration.
There have been a few cool ideas from PC makers I'll grant you that, but looking at the offerings from the 4-5 largest PC makers today it basically looks like it did 20 years ago.
I'll also grant that Apple has gotten more boring with age - the G4 imac is still the coolest computer I've seen to this day. Just so outrageously out there. Current offerings are efficient but a bit boring. Apple Silicon could make something like the trashcan design work, when it basically failed with x86 PC components.
Having said all that I wouldn't mind seeing an ecosystem of ARM-based components even if they followed the ATX standard. Being able to buy an ARM-compatible motherboard and upgrade my ARM-based CPU and pair it with separate RAM and SSD's would be nice!
Is the M series that much better than a modern ADM/Intel? Or is it that they barely need cooling? I have an AMD laptop and Mac Mini, the Mac never makes any noise. Or is the M series just faster?
On paper, the M series is faster. It's not the same situation as when AMD and Intel were suprised by Apple, though. All of the tricks that made people go for the M1 Macs and think amd64 is dead are now also available on amd64.
Price-wise, you're still often better off with amd64. People like to compare the top-end chips, but the competition for a huge slab of amd64 is a small laptop running an iPhone CPU, not the M6 Ultra or whatever the latest and greatest is today. After Apple followed the rest of the industry, the launch price advantage of the Neo quickly grew smaller, especially outside of the USA. If you want a 15 inch laptop, you're pretty deep into high end prices the moment you consider a Macbook.
In practice, getting the M series to run Linux takes longer than it takes Qualcomm to release a Linux build that works, and amd64 takes a few months of actual vendor support rather than enthusiasts hacking away for free, so in that sense the M series is still behind.
With the help of vibe coding it might take a lot shorter time to get m series working on Linux. Though the quality of code is not guaranteed to be perfect.
We get to blame OpenAI et al for this one again. AMD is using their current allocation of TSMC 3nm production to make Epyc rather than Ryzen so Ryzen is jumping from 4nm to 2nm. But 2nm Ryzen is still a few months out, and the 4nm current ones are naturally at a disadvantage when Qualcomm is using 3nm.
M series just always perform better than you expect. I don’t know how to explain it tbh. We use them for live streaming at work and they’re just never pushed to their limits (24gb mac minis) even as we run 7 or 8 independent HD sources + iso recordings of each one. They don’t break a sweat.
I have an m1 16gb MBpro in our fleet for editing and it runs probably as fast as the day I got it (first wave of m1’s).
The low power draw is also very impressive. Fraction of my AMD rig at home.
From what I can tell, you can get more total performance from intel/amd, but at the cost of more power draw, which besides needing more cooling also means shorter battery life.
And even on my desktop, where battery life doesn't matter, I wouldn't mind my CPU needing less cooling.
I say this as someone who will probably never own a mac.
Yeah, I would say that historically low power draw and low heat just haven’t been dominant priorities in the x86 world. If it can be “fixed” by pushing the fans harder and building in a bigger battery (or PSU), that’s good enough.
This is a natural major conflict with the qualities of a laptop that’s good at being a laptop, but yeah, I’d prefer that my custom built tower be efficient, cool, inaudible, and a small as reasonably possible without severely impinging expandability.
I’ve heard of people building desktops around mobile x86 CPUs soldered onto ITX/mATX boards, which sounds like it might be the solution that mainstream manufacturers don’t want to give us. Even a modest desktop cooling solution is vastly more capable than what can be fit into a laptop and so should keep such a CPU chilly with ease.
I have a beefy AMD system and recently bought a macbook pro M5 pro. I'm still blown away by how much faster the M5 is than my AMD tower, while producing no heat or noise.
The Thinkpad T14s 2-in-1 with Intel Core Ultra 5 has great battery life: 10+ hours with moderate usage. I also have the Snapdragon T14s which gets about 14 hours, but I'm still waiting to get full Linux support for this two year old laptop.
Note however, since I've been using my Thinkpad 2-in-1 on battery almost everyday for a year, it is somewhat degraded. upower shows
A lot of people do see the graphs. But reality is - unless they cooperate with lkml and merge it there is no point. Ubuntu has the only beta ISO for it - works not very good for the Lenovo. Qualcomm does not provide any support. Then people won't buy.
Check this chart. Single core performance is where Apple has dominated the most. Qualcomm is above every non-Apple competitor including desktop chips, and only 5% behind the fastest M5 MacBook Air (this chip is going into Air-class laptops). Yes, M6 is coming, but X2 has been available for months already.
"Desktop chip" hasn't been a meaningful variable for single-thread performance in more than a decade. A single core can't use more than a given amount of power or it would melt and laptops have that much in their power budget.
Where a desktop's TDP is actually useful is for multi-thread performance, and naturally the multi-thread chart is topped by Threadrippers.
Moreover, Geekbench is rubbish in general. For example, it has Threadripper 9980X with a <50% higher multi-thread score than Ryzen 9 9950X even though it has twice the memory bandwidth and four times as many of the same cores and you have to look pretty hard to find a real multi-threaded workload where it's not significantly more than twice as fast:
Yes, where desktops differ is not so much the chips but rather the cooling capability. You have the space to have proper air flow and water cooling etc. So that do give quite a bit of performance.
For Geekbench in particular, expect to gain a few percent in Linux vs. Windows. Of course, you should always look at your workload. The thing that causes me to wait for my computer the most is build times, where the multi-core benchmarks are more interesting than single core benchmarks, and these look like they could make for interesting low power dev boxes when/if proper Linux support lands.
nothing wrong with it! looks fine! just: there should be other products with the nice core. i could really use a 10-14" tablet. i mean, after all, ROG Flow 13 with a Strix Halo was not even that late after launch! dense is doable!
20% slower than the M5 is still a great result. I'm still using an M1 macbook pro, and it's more than fast enough for editing film, browsing the internet and writing code.
OpenBSD developer Tobias Heider (tobhe@) has already committed the first pieces of OpenBSD/arm64 support for these Qualcomm Snapdragon X2 Elite laptops.
"This gets USB, keyboard and touchpad working in ACPI mode on the HP Elitebook X G2q."
Give me something that is 80% as efficient, 80% as good hw as the apple m-series but runs Debian (or Ubuntu) and I am happy to pay apple+ prices for pure linux experience. I say this as someone who just bought a new m5 machine. I have seen framework/sys76 but never pulled trigger.
I don't really care about raw performance, just want long battery life, decent screen, and a *nix environment to work in. 99% of workload is going to be on a remote machine anyways.
This already exists. I got a Thinkpad T14s 2-in-1 last year from Lenovo, and it shipped with Ubuntu, which made the price around $50 cheaper if I recall. I replaced it with Debian, of course, but the battery life is fine and it is a quiet machine.
I also purchased the T14s Snapdragon two years ago, and it gets longer battery life (if you just use a terminal only, the battery life remaining will sometimes say 20 hours, but it's more like 14-15 realistically). However, it can get uncomfortably hot on the left edge at the speaker. The T14s 2-in-1 (Intel) does not have any hot spots, though.
Look into something with the Intel Core Ultra Series 3. Performance is worse than the Apple M chips but you shouldn't have a problem running Linux and the battery life is good. I have a laptop with the previous generation of Intel chip (Core Ultra 258). The battery life is great, the computer never gets hot, and the fan rarely turns on (only if I'm doing like a long C++ compile or something, never for stuff like web browsing or watching videos).
I have an HP AMD laptop with a Ryzen and have nothing to complain about, other than the loud cooling solution. It's a fast non-nonsense system. Also a no-frills physical design. Ubuntu works fully without any additional steps needed from me. I'm not sure what you're hoping the market will provide, apart from quieter cooling.
Historically speaking, between average Android device and average Chromebook, latter is far easier to get mainline kernel + "normal" Linux distro running, e.g: 8 Chromebooks vs. only 1 Android device (and even that is a dev. board) in official Arch supported hardware list:
ALARM isn't official Arch, so this also isn't an "official Arch supported hardware list". Arch is currently still only x86_64 and everything else is at best unofficial if not just straight up unaffiliated.
(do note that this might change soon-ish™ considering [0], but I think they want to first get their automated build infrastructure ready)
So Arch on ARM is basically limited to an SoC with at most 8GB of RAM? It looks like we are still very far from a mainstream ARM motherboard with a socketed CPU, upgradable RAM and support for discrete GPUs. Until then, I see no reason to move away from x86.
> this work is focused on laptops with Snapdragon X2 Series. It does not currently cover desktop form factors, earlier Snapdragon X platforms, or other development boards. Readiness also varies by OEM design and Snapdragon X2 Series variant.
So same ARM BS as usual - AMD and Intel x64 are still the kings when it comes to out the door Linux support.
I'll buy a ARM PC when I can swap its motherboard CPU and GPU to a newer gen and my existing Linux install boots up without having to flash a new bootloader and custom vendor kernel with proprietary GPU blob.
"I'll buy a ARM PC when I can swap its motherboard CPU and GPU to a newer gen and my existing Linux install boots up without having to flash a new bootloader and custom vendor kernel with proprietary GPU blob."
add in swappable batteries like older laptops and phones, and I would as well. not now though.
I think this is huge. I thought about getting one of these chips a long time ago, but linux support was just a breaker. I ended up sticking to my current laptop and getting a macbook some years after
The "original" X Elite was also supposed to get good linux support but it unfortunately never happened.
Every single one of the "X" series had this identical announcement.
It's not huge because Qualcomm has proven that they'll continue to half-ass support until the next product is announced and then they'll disappear into the ether.
I've had a Snapdragon X Elite laptop for 2 years, constantly trying to get Linux off the ground on it. Didn't happen (well, technically, toward the end of that period, there was an unsupported port of Ubuntu but it lacked half the drivers). And yes, when I bought it there was a very similar announcement from Qualcomm promising first-class Linux support. So I wouldn't gamble on it (especially considering that prices are crazy) until there indeed is a supported distro.
Yeah, I've really wanted an ARM Linux laptop. But I've known ARM is a crapshoot because of my dealing with other devices. So I held off on the initial X release. Then I saw the X1P (or whatever it was) and Qualcomm put out the exact same "someday Linux up streamed!" Promise.
A competent FTC would be fining them for these false and misleading statements. Until that happens, nobody should buy these thinking Linux will ever be supported.
It potentially can be a good thing, but anyone who is jumping up and down celebrating better wait and see, Qualcomm is more of a lawyer/finance company than a tech company in short a patent troll at heart, so it will be interesting to see what type of fee they want to have the privilege of being on their hardware. In the telecom area historically, they like double dipping.
But they support Android right? Won't that mean kernel support is public already? It would have to be merged into mainline. Or is this about something else?
I mean it technically can run linux. But I think non one actually got any desktop or graphics working. I hope it just happens but you are sadly correct here.
interesting. I mean day-to-day usage is a requirement if you want to buy some of these machines for real. But good to know that graphics works now. Last time I checked it wasn't and that was significantly after launch
Unless Qualcomm steps in and makes every laptop with their chip work flawlessly, I don't see a reason to step into their ecosystem. Right now it is basically flipping a coin when you buy an X1 or X2 product, as you are basically locked to the vendor's idea of 'support'. Qualcomm should coerce and collaborate with vendors to ensure their products are synonymous with great Linux support so that when I see their brand I know it is a good product.
Qualcomm hired some developers back from Linaria and they have been providing support for a bunch of X2 laptops these past two, three months directly via Linux ARM MSM mailing list. I'm surprised it took them this long to announce this publicly.
Hopefully this means Framework releases an X2 mainboard as it would be a match made in heaven.
That's the dream. But I am quite sure Framework is looking into it, if not only because Windows on ARM is gaining traction, which means developers need an ARM machine to develop. I can imagine some would want two identical machines, one with X86_64, one with aarch64.
Qualcomm has been upstreaming Linux kernel support for the Snapdragon X for the past 2 years or so, but the community is still having issues with drivers and firmware on devices. I bought a surprisingly capable Lenovo mini PC with a Snapdragon X at a massive discount and it's stuck on Windows 11 for now.
> Qualcomm has been upstreaming Linux kernel support for the Snapdragon X for the past 2 years or so, but the community is still having issues with drivers and firmware on devices.
Is QCM slow to upstream or are they doing things in an incomplete manner or is there some other reason?
I'm trying to imagine a world where intel or amd releases a new platform/chip and it takes _two years_ to get linux booting on it
That's been my experience dealing with QCM based devices running linux in the past. Some OEM buys a batch of chips, gets a reference design and an old version of the linux kernel with a zillion out-of-tree hacks and patches that make updates impossible.
I generally advise clients to use rockchip as they have _very_ good mainline support and put any QCM modem at the end of a USB connection so it doesn't hold the product back.
That is why The Year of GNU/Linux desktop is never going to take off as such.
It was already proven by the whole netbooks, Android, WebOS, and ChromeOS.
Linux yes, as cost cut factor, and as means to power specific commercial products, running on top of WSL/Virtualisation Framework, or expensive racks on hyperscalers.
The whole community stuff, from OEMs point of view, only when it really has to be.
If the upstream is properly done (that is a big if), this can be a go-to choice for the Linux laptop because it has much smaller config variations compared to Intel-based laptops: Everything from wifi (and even modem?), to audio, to camera ISP is included in the single SoC. If it works it works.
People have had a lot of issues with drivers and locked-down firmware on Snapdragon devices, so even with official Linux support for the chipset, the devices themselves could still be a nightmare to get working.
I don't think so. Every device has locked down firmware really these days, it's not an issue (most peoples BIOS/UEFI/etc is very much not open source).
If the drivers are upstreamed and good, it should work well.
Android phones don't need (and often don't have) upstreamed "drivers". They use qualcomm's closed-source code. Also, Android user land driver (HAL) isn't useful for non-Android Linux distros.
Yes, with proprietary blobs. Oh, and also running a version of the Linux kernel that’s been out of support for years (on some devices, not all).
This is the danger when you don’t upstream your shit. Now you’re stuck on kernel 3 or 4 because your chip vendor is lazy. And Qualcomm has got to be one of the laziest.
Why only for these "desktop" socs? Why couldn't Qualcomm partner with Debian/Ubuntu to bring support to their mobile chipsets? Why can't Qualcomm partner with PostmarketOS to help recycle old devices and avoid e-waste?
Well, in case anyone else is wondering, I have the answer. That's because Google is maintaining a cartel, the "GMS" cartel in short. Due to intense lobbying and incredibly weak antitrust enforcement, this cartel still continues to operate globally, keeping soc makers like Qualcomm, Mediatek and Unisoc in chokehold. We won't see any real competition in the smartphone space unless it's destroyed, but market forces alone can't do that.
Google controls the Android ecosystem (restricts what OEMs can do) and employs various practices to ensure there's no alternative besides Apple (this duopoly suits both of them). Chipmakers essentially focus on ensuring they can sell access to BSPs which meet Google requirements, as there's no real alternative for smartphones. If you're not Apple, these chips are meant to be used with GMS Android, that's the expectation.
If there were alternatives (like on the desktop and for some parts of IoT) it would be more cost-efficient to upstream everything, but with the current situation it's fully up to Google.
When Google wanted them to move all their chip-specific code to modules (GKI), they had to do that. And if someone at Google randomly decided "hey, now you'll upstream this stuff", then guess what? They'd have to follow, it's how this monopoly works.
I think the GKI initiative is great, personally. I've worked with chip companies that are super-resistant to upstreaming their code, and just give me a fork-of-a-fork of the kernel and kind of say "welp, good luck maintaining that unless you pay us".
I don't love how much control Google is exerting over Android, and I don't love having to use their signed kernel. But I do prefer that vs. being stuck on an abandoned vendor kernel. If I have to accept low-quality proprietary kernel code, I'd rather keep it in small module-shaped boxes.
Companies like Qualcomm complain about this, but their historical practices are what drove Google to mandate it in the first place.
They give 2 separate dates for debian and ubuntu which looks to me they will just release drivers but haven't decided to be good citizen and have their drivers in the mainline kernel source tree.
In other words: it might be a trap and you could get screwed in n years if they stop maintaining it and some kernel changes make the driver not compilable on newer versions.
Up voting based on the title alone, though I'm not expecting much.
If we could have a similar experience to Intel-based ThinkPad Carbon X1 or T series with performance, graphics, Wi-Fi, battery life, suspend/resume, external displays, etc, that would be awesome!
Apple hardware is awesome but I want to run Linux.
It will take years for Linux users to trust Qualcomm again.
It has been so many attempts to run Linux on this chips without any collaboration from Qualcomm. Companies even drop support after years of development.
Qualcomm provided efficiency (battery life). But intel is catching up fast to make Qualcomm irrelevant.
Wayland is a protocol that can be implemented by a compositor. Since Wayland intentionally chose to only support a subset of the functionality of a display server like Xorg, it became possible to rip out the Xorg specific hardware drivers and make the X11-supporting Wayland compositor known as XWayland possible in the first place.
"We're stuck with just a protocol that can have arbitrary implementations including full backwards compatible X11 servers"
Sure, but all the software I want to run uses X instead of Wayland. And it would be cool if we could get reliable key remapping under systemd and wayland.
How open will the boot stack be for this chip? Qualcomm has historically been pretty bad about this: mandatory closed-source bootloaders, mandatory closed-source hypervisors, mandatory closed-source TEEs, forked UEFI, etc.
An open Linux is hobbled without the rest of the stack.
I very much want this, but I also do not trust Qualcomm /at all/. Would love to see a performant alternative to current-gen M series which runs Linux. Can you imagine a true ultrabook style laptop w/ great battery life, minimal heat output, and excellent performance in a compact form fanless form factor running Linux? Would be amazing. But Qualcomm has a long track record of bait n switch w/ Linux community and relying on proprietary blobs, no documentation, and aggressively enforcing IP in ways which are detrimental.
Finally, the dumb company woke up. On one hand, it’s good. On the other hand, bad Qualcomm is known as a patent troll. We shall see if they can mend their ways…
Part of this is probably motivated by the fact that Microsoft and Nvidia have teamed up.
Funny how Qualcomm is juggling three OSes to sell these chips while Apple just stuck a phone chip in the Neo and called it a day. Controlling the chip, the OS, and the actual computer is a huge advantage. Apple is more than one study case on competitive analysis.
This is entirely Qualcomm's doing. If they supported Arm SBSA/UEFI+ACPI like some other Arm chip companies (e.g. Ampere) you could boot a generic Linux (or indeed BSD) Arm distro on their chips no problem. Controlling the entire platform is not necessary, just follow the standards.
Qualcomm expects to be paid. a toll/fee by each one of the Linux Distro’s for the privilege of being on the hardware with their chips in the device that is their history and one of the reasons why Apple spent five years kicking them out, they very definitely don’t act as a charity, so in the end, it will be interesting because someone is gonna pay their fee. the end user maybe?
All they have to do is support Windows and get their stuff upstreamed in the Linux kernel, no need for specific distro support. I'll never understand why SoC manufactures insist on bespoke kernel/distro pairings.
>I'll never understand why SoC manufactures insist on bespoke kernel/distro pairings
So that if you want to use the next distro release you will be forced to buy their next-gen chip because that's the only supported one on that distro. D'uh.
What advantage? I'm always a bit shocked to see people say this without qualifying it at all.
On the contrary, Apple has to do a lot of greenfield work by refusing standards like UEFI, Vulkan and normal filesystems. They end up reinventing the wheel just to support the same featureset that Qualcomm, Nvidia, AMD and Intel all generally planned for.
Apple’s advantage is being the last vertical computer company from the 1980s speaks for itself. having control of the hardware and the operating system software with the ability to create new ecosystems is their advantage in comparison to hardware or software only companies, Note: the tech world would be a better place if Sun, SGI, Digital, Acorn, Motorola of Schaumburg, Illinois had been able to survive the Microsoft/Intel onslaught.
Even Apple forfeit x86's onslaught. MIPS was a dog's dinner compared to early x86 chips, and Steve Jobs knew this well since he worked at Pixar when they were preparing to throw away SGI machines to replace them with Linux boxes. Digital Domain, Dreamworks and Industrial Light & Magic all all abandoned UNIX workstations because they sucked. All of those companies deserved to die.
The tech world is a better place without full-stack UNIX grifters demanding a pound of flesh. Eventually macOS will be buried alongside them, as Apple has clearly has no intention to develop a fully-featured OS for Apple Silicon.
Apple didn't have to worry about that when they supported cross-industry standardization efforts. The only reason dGPUs are broken on macOS is because of Apple's software choices.
You sound very ridiculous. Why is Apple obligated? to follow Nvidia? or AMD? or Microsoft for that matter?
Intel said no to designing iPhone chips, IBM and Motorola couldn’t see a future of faster/better chips to meet the demands of future tech devices, Apple with that crazy CEO, Steve Jobs? Had to go it alone and the rest is history.
The Apple Silicon design group appears to be on a roll. What next? Bringing memory in house? I think they will. Because that will be the only way they can build the devices they want to build at a reasonable price going forward.
Before you yell no what is it about the last 28 years have you missed? They seem to be able to execute long-range projects when it comes to hardware and software in comparison to their tech peers, looking forward to the M7 ultra, in-house memory and the C3 modem.
I didn't say they were obligated. I just said that they didn't have these problems when Apple was a cooperative member of industry-spanning consortium efforts.
> What next? Bringing memory in house? I think they will.
It's okay to say that you don't know anything about chip fabrication, instead of making silly assumptions like this.
I really hope it's like 2031 and we're swimming in way too many of these. Running great Linux. How sick would that be. (And X4 is running mainline great too).
While I am somewhat negative on ARM/RISCV systems due to there being like 50 different boot systems and ASIC setups, I am cautiously optimistic that something like the A16 will end up unintentionally becoming sort of a standard via a large amount being sold.
I suspect in the next 5 years something like this will come up.
Yeah, I’m already trying to avoid that blob as well, pretty much - not easy, I know, there are great reasons to follow their dogma .. but Snapdragon-level SOC’s are for me, as a long-time ARM user/developer with record shipping SKU’s, kind of a dime a dozen, kind of thing .. and also the tax of the MS/Nvidia commoditization, well, stings a bit ..
I am thoroughly enjoying the trouncing that Apple is giving everyone in terms of exploiting ARM - it is bothersome however in many ways true — I just am not so sure the open-ness of things has been fulfilled as much as, say, the good ol’ OpenPandora days, if you catch my drift ..
Everything has to be open. No blobs, compilers everywhere as a first-class application, well managed open source repo’s for everything, updates free of charge around a namespace that is large and wide for many, many communities of developer/user interactions occur, unimpeded by needing to ask permission to sign things, but rather just letting everyone sign things together easily from user to developer-level, and let ship new apps from well-oiled repositories ...
No, I think the tooling in the MS/NVidia domain is going to be pretty much the lynchpin. I really, really prefer 100% open source, to the extent it is feasible..
They decided that instead of having an Android runtime on top of ChromeOS they would port the ChromeOS desktop features to Android. A Googlebook boots Android.
This really is about business strategy than any technical effort these days. Porting code should be among the easiest things for the llms to do these days
Man I’m hoping this support extends to older Snapdragon X2 stuff as well as the current crop of chips. There’s a lot of VR/AR headsets out there otherwise running proprietary operating systems and left to rot that a generic Linux distro like Debian could rescue, though Qualcomm’s history makes me doubt those chips will ever see the same support their newer, AI-focused ones are with this announcement.
Still keeping my fingers crossed that in the near future we can throw Linux onto an HTC Vive Focus or a Meta Quest and re-take ownership of our data and devices, but it’s strictly hopium at this point.
It's horrifying that anyone takes Qualcomm seriously after their long history of broken promises.
Remember the Snapdragon Insider phone that was almost instantly abandoned? I think it never even got a single major release update.
They took everything that was open about Atheros WiFi and closed-sourced it by putting everything into binary blobs.
Most of the laptops from the last year or two are still not usable. Audio and webcams will almost certainly never be fully supported, or even supported well enough to be usable.
I hope Qualcomm upstreams all the device tree kernel level stuff to Linux for every laptop model. One of the things I don't like about Arm Laptops is—for example—how even if a SoC is supported upstream, if the manufacturer does not upload a device tree for their device, then you're cooked.
I read that while these Snapdragon laptops do technically have UEFI + ACPI, the information they provide is not useful for Linux and is more coupled with Qualcomm's proprietary drivers on Windows. Therefore, device trees are needed on Linux (I could be wrong about the first part).
Needing the kernel to be changed for each device is an Androidism that encourages ewaste and we should fight against it.
Instead Qualcomm should improve their ACPI implementation and improve the kernels handling of it
> Needing the kernel to be changed for each device is an Androidism
It's an Armish not an Androidism. It's an embedded legacy that really doesn't make sense anymore. But inertia is powerful enough that even Apple is still using device trees, even on their M series SoCs ( https://asahilinux.org/docs/fw/adt/ )
I wouldn't call it legacy as that implies something people inherited but didn't want. The common sentiment among kernel developers has always seemed to be that device trees are nicer to work with than the complicated PC abstractions, and that sentiment remains today. And IIRC Linux didn't always have device trees; it was an approach that came later as it was ported beyond x86, Alpha, and SPARC, and was welcomed.
I'm not a kernel developer, but it seems to be one of those things that's great when you're adding support for a particular device on a particular platform, but becomes a giant PITA in the aggregate for the downstream ecosystem. It's a mismatch of incentives and preferences.
There's no universally good solution for connecting varied kernels with varied hardware. Device tree is okay.
Kernels always have to be changed for different hardware, that's nothing new. x86 kernels don't run on ARM machines, full stop. Gameboy Advance kernels don't run on Switch 2. IBM mainframe kernels don't run on AWS EC2.
As part of good engineering practice we like to separate the parts that are volatile with regard to hardware changes from the parts that are nonvolatile. But that's a kernel implementation detail and we shouldn't pretend it means the combined kernel doesn't need to be changed.
We can also embed several volatile components for several different hardware configurations. That's called inefficiency, or bloat.
There were several attempts for hardware to incorporate the volatile component itself and be self-describing. ACPI (in ROM) is one; device-tree-in-ROM is another. Neither turned out to work well, because it turns out you actually want to evolve that code and so kernels contain lists of ROM patches anyway, which isn't much better than just including whatever was in the ROM to begin with.
> Kernels always have to be changed for different hardware
Isn't there a way to have loadable device drivers that live outside the kernel?
That's just a form of building the kernel for several configurations at once.
Someone from Qualcomm posted a "DT-ACPI Hybrid Mode" set of patches a while back that let you call ACPI table functions, etc even while booting with the device tree, allowing you to control some things like keyboard lightning/power management independently. That would be a good first step but I'm not sure it went anywhere in the meantime. In theory supporting Device Tree by including the blob in a ROM somewhere shouldn't be much more work (if any) than including working ACPI tables, but we all know how that works out in practice!
> supporting Device Tree by including the blob in a ROM somewhere shouldn't be much more work (if any) than including working ACPI tables, but we all know how that works out in practice!
This is definitely a thing in some embedded systems I’ve used. There are some Marvell boards which do this. They all use U-boot though.
The problem is that the content of the device tree isn't really stable -- if a new kernel version has a driver with a new required parameter for instance, suddenly your ROM device tree is out of date and much less useful.
Oh, that's a good point I forgot about; I suppose DT interfaces aren't considered part of the stability contract for users... Really Device Tree is somewhat "Linux-specific"-enough and low level enough that issues like this aren't ideal. But if we could just get to the point that was a problem, I'd be happier than now, I suspect!
In theory device trees are supposed to be a OS-neutral stable ABI. Being able to put a device tree into unchangeable mask ROM is an often mentioned design goal.
However, there is a fatal flaw in the process that makes this a pipe dream in reality. In Linux, these rules only apply to reviewed and merged drivers. And during review any new DT interface will almost certainly be bikeshedded in some way.
So unless your chip vendor has upstreamed ALL their drivers before a device is manufactured, the device's firmware-provided DT will very likely work only against a vendor kernel and requires updating.
Not at all, that is how all computers used to be before IBM PC clones happened, and is the world we are going back, as so many seem keen in killing x86 PC legacy, for their beloved ARM and RISC-V boards.
This is exactly what they have already been doing for the past two months, directly from their devs, posted to Linux ARM MSM mailing list, and despite not having all of the specs from manufacturers. See the EC driver submission for Asus ZenBook A16 from this past week.
I believe the Orin AGX is in a similar position. It does a UEFI boot but you absolutely have to supply a correct dtb and if you don't then key peripherals like USB and ethernet can just completely not work, or in one case I experienced, subtly malfunction in a way that appears to be fine but throws off a bunch of extra radiation that fails a certification test.
There was a recent proposal to make use of ACPI on ARM
https://www.phoronix.com/news/DT-ACPI-Hybrid-Mode-Linux
This is actually misinformed, the discussion on the mailing list made it clear: there is NO full ACPI on these Windows ARM devices; they only use ACPI marginally and still require and provide device tree.
Phoronix should have revised that article, it's completely misleading.
One option would be to implement the custom non-standard Qualcomm drivers that technically it needs to implement anyway, but with support for the UEFI/ACPI interface.
On Windows, Qualcomm ships custom drivers that override normal ACPI platform logic in various places, IIRC
Not an easily feasible option notably because the firmware ACPI tables are in part stubs - but work on hybrid ACPI/DT instead is possible.
One of the reasons is that Qualcomm uses supplemental ACPI tables (think device tree overlays) shipped inside of the driver packages. Look at the .bin in plenty of the drivers carefully and you'll see that they're supplemental ACPI tables.
Windows doesn't have such a notion and it's implemented via having an ACPI table loader statically linked in to individual drivers.
_On top_ of that, Qualcomm uses PEP to intercept plenty of ACPI functions and implement them in native code instead.
I was thinking essentially about Linux equivalent of PEP.
Of course my preferred setup would be for systems to actually ship compliant UEFI instead of Qualcomm shitshow
There is also ARM SystemReady which is an existing spec for this mainly intended for servers. But it’s not being followed well.
It’s crazy to need a million device trees on server or laptop class devices.
https://news.ycombinator.com/item?id=45086346
I don't think that ARM Laptops have a chance in Linux land as long as each model requires stuff like a custom DT.
I'm typing this on a Thinkpad x13s Gen1, "21BX000XGE". I really really like the device, best laptop I've owned so far, speaking strictly from a hardware perspective. No vents mean I can use it on a pillow, and it's dead silent. It never runs hot, great battery life. Thin and light, yet has all the performance I need. But would I recommend the laptop to any fellow Linux user? Absolutely not.
Even though it was released in 2022, the webcam still won't work. I can't limit the battery charge to 80% like on my x86 Thinkpad. There was a time when the graphics driver and Chromium didn't like each other and I had to wrangle Chromium into software rendering mode to avoid heavy artifacts on the screen (export force_gl_vendor="notfreedreno"). In fact, I still have the workaround in place. Not sure if it's still needed though. A fix was merged upstream last year, need to check whether it made it into Fedora yet.
I got the machine in 2025, and here are the workarounds and config changes I had to make just to get Fedora running last year, 3 years after release:
- extra kernel arguments ("arm64.nopauth" seems to be needed still in 2026, "clk_ignore_unused pd_ignore_unused" I have been able to remove at some point)
- GRUB config (GRUB_DEFAULT_DTB=/boot/dtb/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb)
- initramfs modification, /etc/dracut.conf.d/x13s_firmware.conf: install_items+=" /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn.xz /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn.xz /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn.xz ". Not sure if these are still needed, they were at some point.
In late 2025, installing Fedora was still a pain in the butt. There were custom-built ISOs for my device, but they didn't work because my firmware was too new. Stupid me ran a firmware update on the preinstalled windows. I tried building my own ISO, but the firmware never recognized those as a boot device for some reason (I have successfully built custom ISOs for x86 many times). In the end, I was able to use QEMU + chroot on my x86 machine to install Fedora ARM onto an external HDD, make the needed modifications in there, boot that on the laptop and run the anaconda installer, then make modifications to the install on the internal storage.
I just ran a quick `wc -w` on my installation and debug notes for the machine, and it's a cool 11180 words. At some point, it turned out that the display my unit uses was not in the list of known displays for the x13s. Seems that was mostly inconsequential aside from a kernel warning and maybe slower wakeup. Helped upstream with that, which eventually resulted in this commit: https://github.com/torvalds/linux/commit/3330b71caff6cdc387f...
I'm no stranger to exotic architectures and machines, having used Gentoo on a ppc64le machine as a daily driver for 3+ years. And I do like the laptop. But w/o fundamental improvements to the way ARM bringup works, not just improvements for individual machines, I wouldn't recommend this stuff to any unsuspecting user.
I've been working on embedded systems using iMX8s, and it's equally awful. You have to maintain your own fork of UBoot. You have to spend hours tweaking device trees. The "NXP" kernel is out of date and never updated, the mainline kernel is missing loads of drivers.
Meanwhile in x86 land you can just download a distro and boot it. Secure boot works out of the box. It's night and day.
Yup. I remember my dismay when I started working with Linux on arm boards and realizing the absolute massive gap between the hardware vendor claims of "full linux support" and the reality.
Sometimes the SDK is a zip of the developer workspace in a pseudo working state with no clear records of all that's been patched.
Vendors providing binary only kernel and system images containing god knows what is not uncommon either.
I'm convinced now that arm hardware vendors are simply incapable of even understanding what proper software support is. I'm sure some of their devs do their best but management does not care. By the time the chip ships, efforts move to making the next thing so they never properly finish the software side.
Have you looked at SoCs supported by Linaro?
Linaro is (or was, back when I was involved ~10 years ago) non-profit sponsored by SoC vendors to develop, maintain and upstream SoC support for Linux, along with running a comprehensive validation lab for all the boards they support.
A list of manufacturers did change a few times, and it was half-sponsored by ARM directly.
Every time I have watched Linaro presentations, I mostly got the feeling that their customers so top speak are embedded (Automobile and co) and Android OEMs, not so much people that would like to some day have GNU/Linux on ARM desktops/laptops.
Even rather mainstream stuff like the RPi can get wonky in places, and still people comment on why "idiots" buy RPis when this-or-that ARM board has 10% more bang for the buck. Eh, yeah, of course. I'd love to only ever run RandomShenzenCorp's heavily patched vendor kernel from 2016.
I don’t hear people suggesting to replace an RPi with a similar device (OrangePi or what not).
What I hear a _lot_ is that the thing could have been an esp32 (or Arduino rarely).
That’s a way wider price gap. I can order Costco-sized lots of esp32’s for the price of a single RPi.
RPis pricing has really, really narrowed the space where their products make sense. Low power devices can be esp32, high power can be x86 NUC things (or interconnected esp32s if you need tons of pins).
I don’t encounter a ton of things in “too big for an esp32 but I’m positive I don’t even want the option of a beefier x86 CPU”.
No hate if it works for you. I don’t even dislike RPi, they’re just in a narrower band for me these days.
Just in case anyone unfamiliar reads this, the way to run ARM boards is e.g. https://armbian.com/ (or NetBSD, Debian, whatever you prefer) and never the vendor junk.
RockChip stuff tends to have good support, and in fact I'd trust it more to have good support than Raspberry Pi (Broadcom). When in doubt, check or wait before buying in any case. In many cases support will not meaningfully improve from how it was at release (learned this one the hard way) and most ARM devices are e-waste. Try not to get excited about theoretical hardware specs either, they might as well be fake because of how poorly the majority of ARM stuff actually works. Go for known good software support and then upgrade to new hardware when you find something newer with known good software support a few years later.
RasPi just enshittified, pushing out a firmware upgrade that bricks the Pi if it detects you've upgraded the RAM yourself.
This is tragic to read. An ARM-based Thinkpad ultrabook running Fedora on it would be a "forever" device for me. I adore my X1 Carbon Gen7 but the battery life could definitely be better and I could stand for it to run a little cooler.
It's sorta funny, the existence of Windows' stranglehold has worsened so many generations of thinkpads. The push for the S0 mac-style standby made my 11th gen X1 carbon basically unusable for me in Linux.
The standby battery life is so bad, it will burn through half the battery overnight with the lid closed. The battery life actually seems better when using the laptop opposed to standby.
Other standby modes were removed on a firmware level by lenovo despite the processor supporting it.
I still have my 4th gen X1 carbon, it was an amazing machine for 8 years and I really thought I'd get another 8-year laptop buying the latest X1, but now it sits off and only comes out for specific uses. Bought an m4 air for day-to-day laptop use.
So get a newer, better, and cooler CPU? That really has nothing to do with ARM or x86.
Apparently vendors refuse to make (cheap) x86 CPUs that can run fanless, so it has everything to do with that.
The Snapdragon X2 laptops are typically not fanless, either. Fanless just results in thermal throttling if you ever do push on it.
Fanless just means slower.
I also have an X13s and it's also the best laptop I've owned... Sort of.
I ran Windows on it up until a few months ago and it was as you said, delightful. Long battery life, fanless, great size, great screen. I put Ubuntu on it (where they've mainlined a good bit of things), and it's still just not very good. Sleep doesn't work (and never will without Qualcomm), certain things still just crash on occasion -- but I do think the webcam works.
I'll likely put Windows back on at some point, which is a shame, because the laptop is great, but Windows is terrible. I simply do not believe any claims Qualcomm has about future support, as much as I'd love to see a newer Thinkpad device with full ARM support.
This is depressing, I just got this x13s hoping to give this arm craze a try as supposedly it has fairly full Linux support. I will just ignore any claims about Qualcomm until Dell or Lenovo release models with Linux pre-installed and they get real world reports over time.
For what it's worth, aside from the hacks I had to apply and having to ignore the webcam, I'm really happy day-to-day with my x13s on Fedora.
Whew, thank you for this summary. I just got this laptop as it seemed to have "good" Linux potential, but I've been stuck so far. And as further caution to others, hibernate doesn't work on Linux, and audio is glitchy. Even on windows 11 pro the shutdown menu is missing. It seems to sleep on windows but not sure about battery drain, which is reported to be 1-2%/hr in Linux.
This makes me pretty sad. But I'm still hoping i can have a linux arm laptop in my lifetime; maybe in 10-20 years.
Asahi + M2 Macbook air is the best laptop I have ever owner. I would highly recommend the combo if you're in the market.
> I don't think that ARM Laptops have a chance in Linux land as long as each model requires stuff like a custom DT.
Why? In theory the UEFI firmware can pass Linux a devicetree. Not much different to different laptops having different ACPI tables.
In theory. This up to the manufacturers and they're not doing that, so it's quite different from non-ARM laptops, where this is basically standardized.
It's not necessarily any better on Windows. I've worked with Qualcomm based laptops that wouldn't work without a bespoke Windows image from the manufacturer. I also had one where the "generic" ARM Windows image wouldn't work with it even though it should've and the manufacturer never provided a bespoke image.
Even the Surface Pro doesn't work well with the generic image. I had to go get the Surface Recovery one to get it work enough to go through the install because there was no support for the touch screen or the official Surface keyboard on the generic one.
Well, in theory, I don't even care. I want to download an ISO from randomdistro.org and boot it.
People in the thread who have actual experience on actual hardware and software are telling you how things actually work, not some farcical idea of how it theoretically works.
This sounds like a terrible situation, but I wonder if a weekend of Claude iterating could improve on any of these problems. They seem to have been pretty successful on the Mac M series.
I'm sure Claude would be capable to solve many of these. But the next machine probably requires the whole dance all over again, and it just doesn't scale very well, I feel.
It probably will help you maintain a better local fork, but getting all things upstreamed is the bottleneck and won't help too much here.
> One of the things I don't like about Arm Laptops is—for example—how even if a SoC is supported upstream, if the manufacturer does not upload a device tree for their device, then you're cooked.
Why? Downstream vendor kernels generally use device trees and they can typically be easily extracted and decompiled for cases where the vendor is not GPL compliant and hasn't provided sources.
I've ported arm board device trees to mainline based Linux myself, porting the device tree has not really been the hard part in general...if mainline already has the necessary drivers.
The bigger issue tends to be that vendor kernels have a bunch of drivers that don't have upstream equivalents. I've been porting a lot of Allwinner ARM SoC drivers recently for the purpose of mainlining board support and it has been quite involved as Allwinner downstream kernels very heavily diverge from their mainline equivalent versions and are often based on 10 year old kernels. Even with Allwinner vendor sources(which are typically available in some form from BSP releases floating around on the internet) the drivers typically need to be fully rewritten due to Allwinner doing things in ways that mainline wouldn't accept. Luckily LLM's are quite good at this sort of porting work since they can ingest lots of garbage vendor driver code and create mainline variants(although there's usually substantial review/refactoring needed to get these merged upstream).
Often one also needs to port the drivers to uboot as well, in many cases one can mix a vendor uboot with mainline kernel but that doesn't always work properly(i.e. for Allwinner you generally can't boot a mainline kernel from vendor uboot and need to port uboot as well).
One other issue I've run into is that mainline Linux doesn't have great support for dynamic hardware probing which is often needed when vendors have different minor hardware variants that are all expected to use the same software builds. For example Allwinner on some SoC's will use a different co-packaged EPHY depending on the SoC revision which requires dynamic hardware detection via efuse probing. In other cases one may need to say detect a touchscreen device and driver by probing i2c addresses, mainline Linux has some support for this sort of thing but it's not particularly mature so sometimes one needs to do the hardware detection in uboot and patch or conditionally load device trees and/or device tree overlays which can be a bit involved.
Maybe I'm wrong, but I feel like creating device tree should be relatively straightforward if driver support is there. So while having official device tree is awesome, it's not something that's very hard to do. Now writing drivers without datasheets, using reverse-engineering is something that's hard to do.
I've been waiting for someone to write a DTS for a Snapdragon(R) X - X126100 - Qualcomm(R) Oryon(TM) CPU based laptop I bought over a year ago. Some people are trying but it can't be that easy ... Starting to look into doing it myself and AFAICT it requires reading the ACPI tables (written for Windows drivers), and manually converting it to devicetree, test, tweak, repeat.
This sounds like something that LLM assistance might actually be ideal for.
This is one of those situations, even if they don't want to release specific code, they could at least release the specifications so that others could build the software stack for this.
The curse of open source is that any missing feature is always your own fault, because you didn't do it yourself.
The device trees either exist in the proprietary blobs, or can be written.
and speed doesnt matter at all if no drivers work
I think a lot of people don't realize the level of performance Qualcomm has reached with these. This is the closest competition to Apple's M series that we have, for the laptop form factor at least. They are better than Intel and AMD's best. I'd love to buy an X2 laptop with Linux preinstalled and supported.
I want to believe. It's just that we've seen similar announcements in the past and then nothing come of them.
This. The X1 Elite laptops came out 2+ years ago, but you still need to use a special Ubuntu remix to get everything* working, and support is very dependent on which laptop you bought. You could say it’s not Qualcomm’s job to make audio or the camera work on every Lenovo/Dell/HP, but someone needs to do it…
*: I’m sure there’s some features that still aren’t working right.
I’m glad we’re finally getting more competitors to Intel/AMD.
Better for everyone. Apple gets lazy on top. And for those who don’t want a Mac, they should be able to have something great too. And since PC makers are far more willing to experiment with form factors, I’d like to see what they try.
If Apple was lazy, they wouldn’t have spent five years getting rid of Qualcomm modems, Qualcomm is also getting squeezed by the Chinese, Mediatek, Microsoft, Nvidia, Samsung and Apple worldwide.
It will be interesting. because Qualcomm doesn’t give away anything for free, so any of those Linux Distro’s who thinks it’s going to be a free lunch? Are gonna be in for a surprise.
They hate being under someone else’s thumb and Qualcomm had real control over that. They couldn’t stand it and wanted out. Which is just as well, because clearly Qualcomm could’ve been doing better. Apple cut the power usage of the chip and it’s reportedly better than the Qualcomm one.
> It will be interesting. because Qualcomm doesn’t give away anything for free, so any of those Linux Distro’s who thinks it’s going to be a free lunch? Are gonna be in for a surprise.
Care to postulate on what those nefarious reasons/surprises could be?
Onavo is correct: Qualcomm are extremely notorious for aggressive IP enforcement. They're the Oracle of hardware. In particular they held critical CDMA patents which were required for making a modem which worked in the US.
They (along with Intel) also ended up making most of the non-Apple ARM chips, which are not competitive with the Apple ones.
Imagine NVIDIA on steroids. Think bad documentation, opaque code, and everything being locked down. The customer gets squeezed for more money (especially egregious if you don't have enough scale they won't even bother engaging).
I'd have assumed Qualcom are looking at the Steam Deck / Steam Machine and Steam OS, and thinking: "I might want some of that."
And looking at the direction Microsoft is going, and thinking: "Shackling our laptop and desktop chip sales to this is a bad idea."
The entire landscape outside of the Raspberry Pi is a shitshow in terms of "Just download a distro for your device class and arch and it'll work."
Arm SystemReady appears to be a slow push in the right direction from the opposite end.
They must think they will sell more chips to OEMs that want to offer Linux. It's not like they're going to be shaking down Debian for cash.
If Apple cared about quality, they wouldn't have gotten rid of Qualcomm modems, and forced people to use the inferior Intel modems. I always avoided by iPhone models with Intel modems starting around the 6S era.
What specific quality issues did you notice? I haven’t heard of any, but I wasn’t paying close attention at the time.
The Qualcomm models were faster. I’m not sure if they were better in low signal conditions.
The Intel models were worse, but they weren’t bad as far as I know.
> Apple gets lazy on top.
A20 Pro P-Core is the largest jump in performance per watt in the past 5 years. I am not sure why Apple is lazy in their hardware front. Not the same could be said about their software though.
Let me appropriate and rephrase a sentence from earlier in the thread: "performance per watt doesn't matter at all if the combination of the machine's feature set, both in hardware and software, as well as form factor, is essentially useless to you".
I have seen this far too many times on HN. A design that put Performance Per Watt first is how you extract more multicore performance when you are fundamentally limited by cooling.
Well, since an adequate cooling solution is a part of a machine's feature set for me, my point still stands.
Well I guess you could summarise your point as "Performance doesn't matter".
Which is fine. Have a great day.
Gud lorde, don't be daft. PPW matters until it hits a point where any optimizations above that line are of much less importance to some people (e. g. me) than other specs. Not to speak of necessary attributes completely absent from your PPW dream machine, which indeed negates PPW considerations on a per device/device-class basis. Which excludes optimizations for microprocessor series. It ain't rocket science.
basically: "I want WSL for my overpriced toaster, I'm totally fine with the keyboard lacking most of the essential keys, pretty please. whispers expletive against Apple whilst making sure no one can hear him"
I wasn’t thinking hardware, more software. But either way the closer a competitor is the harder they’ll run, even if still on top.
Those that dream of an ARM ecosystem don't realise what they are getting.
Finally the end of IBM PC clones is taking shape.
And how exactly does that matter? How close do you have your head to x86 assembly for the instructions set to matter?
ARM is a fragmented mess compared to x86. Switching to ARM (right now at least) means losing the ease of x86 booting. In the x86 world, trying another Linux distro is as simple as downloading it and putting it on a USB stick. You can be 95% certain it will work. In the ARM world, nothing is standardised, nothing will ever work first time.
There are projects trying to tackle it, but compared to x86 it's a fragmented mess. That's what we're losing with ARM laptops - universal computing.
It's an Acorn microcomputer, I know this!
What makes you think if one ARM manufacturer gets popular ‘clones’ won’t pop-up again?
One key frustration is it’s typically not possible to have an arm distribution that boots across most arm boards, because they have incompatible boot loaders. Ie you have a raspberry pi image and a banana pi image and an orange pi image and the rock pi S image that are all different from each other. There have been some attempts at UEFI on arm that would address this, but it’s nowhere near as consistent or compatible as on the x86 platform side.
People bought IBM clones to run the same software, not for the love of the architecture.
If ARM processors are regularly incompatible and segmented, we all lose out and end up in isolated silos.
A computer is much more than an CPU chip, e.g. "PC 99 System Design Guide", among several other references.
But that's not answering my question? What do you expect to get from today's ARM chips that's fundamentally impossible otherwise? And how is that a step forward?
I know I will never switch to ARM willingly. There is no advantage, only vendor lock-in. I feel that x86's openness was an accident, and we should try to keep x86 alive as long as possible.
It actually was an accident, enabled by IBM using off the self parts unlike their previous computers, and Compaq's clean room reverse engineering of the BIOS.
Again, a computer isn't a chip with nothing else.
In the ARM world, that other part you are completely ignoring isn't standardised, even with device trees, they only help to alleviate the pain that each computer is its own OEM snowflake.
The comment you're replying to is implying that in an ARM world nothing is standard, portable, or compatible by default. Think about smartphones: Every single one a bespoke board with bespoke hardware.
In ARMland, there's no such thing as standard OS images you can install on any machine, or generic components that users can buy and install themselves.
I'm more on the Apple hater side, but they getting lazy is simply not true.
For many years Apple dominates the Laptop hardware scene, and while there is no comparably performing competitors threatening them, they keep releasing newer, faster, more efficient chips. After using many operating systems, I know that for sure I don't want MacOS, but the hardware itself is hard to beat.
Me too. Not a fan of Qualcomm, though.
>And since PC makers are far more willing to experiment with form factors
What are you thinking of here? ATX is from 1995 and ITX from 2001, since then we've had stuff like the lamp imac, trashcan mac pro and nowadays the finger-thin imac and tiny mac mini from Apple.
I had Fujutsu laptops that were far lighter and smaller than Airs, touchscreens in the late 90s, convertibles, 2 in ones, touch bars (Thinkpad). Plenty of designs that don't build around ATX type specs, and things that do (open frame cases, and the vast array of expansion cards that benefit from it). PCs that snap onto a monitor. Things Apple copied or hasn't gotten around to yet then claim then as revolutionary. Apple has more integration and can be more strategic (when they don't need bailing out), but as one company they do far less exploration.
There have been a few cool ideas from PC makers I'll grant you that, but looking at the offerings from the 4-5 largest PC makers today it basically looks like it did 20 years ago.
I'll also grant that Apple has gotten more boring with age - the G4 imac is still the coolest computer I've seen to this day. Just so outrageously out there. Current offerings are efficient but a bit boring. Apple Silicon could make something like the trashcan design work, when it basically failed with x86 PC components.
Having said all that I wouldn't mind seeing an ecosystem of ARM-based components even if they followed the ATX standard. Being able to buy an ARM-compatible motherboard and upgrade my ARM-based CPU and pair it with separate RAM and SSD's would be nice!
Couldn't agree more. I would LOVE a linux based laptop with the performance of the M series.
Intel panther lake is already very close. Good enough for me to be happy with it.
Is the M series that much better than a modern ADM/Intel? Or is it that they barely need cooling? I have an AMD laptop and Mac Mini, the Mac never makes any noise. Or is the M series just faster?
On paper, the M series is faster. It's not the same situation as when AMD and Intel were suprised by Apple, though. All of the tricks that made people go for the M1 Macs and think amd64 is dead are now also available on amd64.
Price-wise, you're still often better off with amd64. People like to compare the top-end chips, but the competition for a huge slab of amd64 is a small laptop running an iPhone CPU, not the M6 Ultra or whatever the latest and greatest is today. After Apple followed the rest of the industry, the launch price advantage of the Neo quickly grew smaller, especially outside of the USA. If you want a 15 inch laptop, you're pretty deep into high end prices the moment you consider a Macbook.
In practice, getting the M series to run Linux takes longer than it takes Qualcomm to release a Linux build that works, and amd64 takes a few months of actual vendor support rather than enthusiasts hacking away for free, so in that sense the M series is still behind.
With the help of vibe coding it might take a lot shorter time to get m series working on Linux. Though the quality of code is not guaranteed to be perfect.
We get to blame OpenAI et al for this one again. AMD is using their current allocation of TSMC 3nm production to make Epyc rather than Ryzen so Ryzen is jumping from 4nm to 2nm. But 2nm Ryzen is still a few months out, and the 4nm current ones are naturally at a disadvantage when Qualcomm is using 3nm.
M series just always perform better than you expect. I don’t know how to explain it tbh. We use them for live streaming at work and they’re just never pushed to their limits (24gb mac minis) even as we run 7 or 8 independent HD sources + iso recordings of each one. They don’t break a sweat.
I have an m1 16gb MBpro in our fleet for editing and it runs probably as fast as the day I got it (first wave of m1’s).
The low power draw is also very impressive. Fraction of my AMD rig at home.
From what I can tell, you can get more total performance from intel/amd, but at the cost of more power draw, which besides needing more cooling also means shorter battery life.
And even on my desktop, where battery life doesn't matter, I wouldn't mind my CPU needing less cooling.
I say this as someone who will probably never own a mac.
Yeah, I would say that historically low power draw and low heat just haven’t been dominant priorities in the x86 world. If it can be “fixed” by pushing the fans harder and building in a bigger battery (or PSU), that’s good enough.
This is a natural major conflict with the qualities of a laptop that’s good at being a laptop, but yeah, I’d prefer that my custom built tower be efficient, cool, inaudible, and a small as reasonably possible without severely impinging expandability.
I’ve heard of people building desktops around mobile x86 CPUs soldered onto ITX/mATX boards, which sounds like it might be the solution that mainstream manufacturers don’t want to give us. Even a modest desktop cooling solution is vastly more capable than what can be fit into a laptop and so should keep such a CPU chilly with ease.
I have a beefy AMD system and recently bought a macbook pro M5 pro. I'm still blown away by how much faster the M5 is than my AMD tower, while producing no heat or noise.
when it comes to Laptop Battery life afaik there isn't even a competition.
I'd buy one because I want a Lenovo Thinkpad with an onboard ethernet port and really good battery life for Linux.
The Thinkpad T14s 2-in-1 with Intel Core Ultra 5 has great battery life: 10+ hours with moderate usage. I also have the Snapdragon T14s which gets about 14 hours, but I'm still waiting to get full Linux support for this two year old laptop.
Note however, since I've been using my Thinkpad 2-in-1 on battery almost everyday for a year, it is somewhat degraded. upower shows
But I still get more than 10 hours on a charge.I would have been totally interested in the snapdragon if Linux support was good and the hardware wasn't old at this point. I'd like a 24h laptop!
T14 gen7?
Nah, I want serious all-day battery life.
Notebookcheck¹ measured 17.5h of wifi+websurfing battery life and 12.5h at 500+ nits, how long are the days on your planet effectively?
Also, that's on Ryzen AI 7 PRO 450, you might be getting even more out of the Panther Lake alternative.
¹ https://www.notebookcheck.net/Excellent-business-laptop-with...
A lot of people do see the graphs. But reality is - unless they cooperate with lkml and merge it there is no point. Ubuntu has the only beta ISO for it - works not very good for the Lenovo. Qualcomm does not provide any support. Then people won't buy.
They'd still have the >99% or so of their customers who prefer Windows or will put up with it for the smartphone-grade battery life.
Are you sure? Snapdragon laptops have worst sales in Windows world. Or are you a MS ARM guy?
> closest competition to Apple's M series that we have,
Not very close at all, not even to the two-year-old model, it appears
https://wccftech.com/snapdragon-x2-plus-loses-to-m4-in-4-out...
Check this chart. Single core performance is where Apple has dominated the most. Qualcomm is above every non-Apple competitor including desktop chips, and only 5% behind the fastest M5 MacBook Air (this chip is going into Air-class laptops). Yes, M6 is coming, but X2 has been available for months already.
https://browser.geekbench.com/processor-benchmarks
"Desktop chip" hasn't been a meaningful variable for single-thread performance in more than a decade. A single core can't use more than a given amount of power or it would melt and laptops have that much in their power budget.
Where a desktop's TDP is actually useful is for multi-thread performance, and naturally the multi-thread chart is topped by Threadrippers.
Moreover, Geekbench is rubbish in general. For example, it has Threadripper 9980X with a <50% higher multi-thread score than Ryzen 9 9950X even though it has twice the memory bandwidth and four times as many of the same cores and you have to look pretty hard to find a real multi-threaded workload where it's not significantly more than twice as fast:
https://www.phoronix.com/review/amd-threadripper-9970x-9980x...
Yes, where desktops differ is not so much the chips but rather the cooling capability. You have the space to have proper air flow and water cooling etc. So that do give quite a bit of performance.
For Geekbench in particular, expect to gain a few percent in Linux vs. Windows. Of course, you should always look at your workload. The thing that causes me to wait for my computer the most is build times, where the multi-core benchmarks are more interesting than single core benchmarks, and these look like they could make for interesting low power dev boxes when/if proper Linux support lands.
that's x2 plus. look for benchmarks of the x2 elite extreme, which currently is selling with 48gb ram for $1370: https://www.bestbuy.com/product/asus-zenbook-a16-16-3k-oled-...
i wish that wasn't literally the only X2 EE system we could buy! (as i said a while ago in this submission, https://news.ycombinator.com/item?id=49823752)
nothing wrong with it! looks fine! just: there should be other products with the nice core. i could really use a 10-14" tablet. i mean, after all, ROG Flow 13 with a Strix Halo was not even that late after launch! dense is doable!
OK, i did.
https://browser.geekbench.com/v6/cpu/19122559
https://browser.geekbench.com/v6/cpu/14591329
yup... still laughably behind by nearly 20%. And that is behind the M5, not even the current M6
> still laughably behind by nearly 20%
20% slower than the M5 is still a great result. I'm still using an M1 macbook pro, and it's more than fast enough for editing film, browsing the internet and writing code.
Especially when it is significantly faster than literally every non-Apple competitor. Including Intel and AMD's best desktop chips.
> laughably behind by nearly 20%
I think we have a different definition of what laughably means. Especially since A16 is 25% ahead of M5 in multithreaded.
You're still trying to deliver your original point after you were told you use the wrong reference and you're not doing a good job.
20% behind that's actually very impressive and if it will support Linux that's more impressive.
better than the closest linux alternative (M3 on asahi)
I was hearing a lot of hype with regards to the Nuvia acquisition prior to these coming out, happy to see it turned out well.
I considered getting a Snapdragon X2E laptop, but the prices were so unattractive for otherwise similar specs that I went with X86.
Benchmarks?
OpenBSD developer Tobias Heider (tobhe@) has already committed the first pieces of OpenBSD/arm64 support for these Qualcomm Snapdragon X2 Elite laptops.
"This gets USB, keyboard and touchpad working in ACPI mode on the HP Elitebook X G2q."
https://marc.info/?l=openbsd-cvs&m=178891082169317&w=2
Tobias (who also works for Canonical) recently demoed Ubuntu on mastodon and confirmed ARM EL2 works, meaning KVM support unlike previous generations.
bsd.network/@tobhe/117122761215052773
(I'd love to get my hands on one of these X2 Elite machines, hmu qcom.)
Give me something that is 80% as efficient, 80% as good hw as the apple m-series but runs Debian (or Ubuntu) and I am happy to pay apple+ prices for pure linux experience. I say this as someone who just bought a new m5 machine. I have seen framework/sys76 but never pulled trigger.
I don't really care about raw performance, just want long battery life, decent screen, and a *nix environment to work in. 99% of workload is going to be on a remote machine anyways.
This already exists. I got a Thinkpad T14s 2-in-1 last year from Lenovo, and it shipped with Ubuntu, which made the price around $50 cheaper if I recall. I replaced it with Debian, of course, but the battery life is fine and it is a quiet machine.
I also purchased the T14s Snapdragon two years ago, and it gets longer battery life (if you just use a terminal only, the battery life remaining will sometimes say 20 hours, but it's more like 14-15 realistically). However, it can get uncomfortably hot on the left edge at the speaker. The T14s 2-in-1 (Intel) does not have any hot spots, though.
I also had the X1 Snapdragon T14s and it felt like going back to 2008 linux.
No wifi, no bluetooth, no fingerprint reader, no hardware accelerated 3D..
There is a special version of Ubuntu that largely works (it's a bit old) and if you dist-upgrade to a new version it will break.
I spent about a week trying to get it working and just gave up, awful experience.
Look into something with the Intel Core Ultra Series 3. Performance is worse than the Apple M chips but you shouldn't have a problem running Linux and the battery life is good. I have a laptop with the previous generation of Intel chip (Core Ultra 258). The battery life is great, the computer never gets hot, and the fan rarely turns on (only if I'm doing like a long C++ compile or something, never for stuff like web browsing or watching videos).
I'm 90% sure a laptop with Intel core ultra 300 series processors would suit you well.
I have an HP AMD laptop with a Ryzen and have nothing to complain about, other than the loud cooling solution. It's a fast non-nonsense system. Also a no-frills physical design. Ubuntu works fully without any additional steps needed from me. I'm not sure what you're hoping the market will provide, apart from quieter cooling.
framework 13 pro might fit this. Saying from someone who just migrated from m4 macbook pro 14.
In case anyone else is wondering what they mean by linux support;
> We're upstreaming core drivers for Snapdragon X2 Series — including the Hexagon NPU and Adreno GPU — to open the door to developers and partners.
Glad this isn't going to be some semi-proprietary thing like support for chromebooks. Hopefully it continues.
> semi-proprietary thing like support for chromebooks
Many Chromebooks have better linux support today than any of Qualcomms laptops from the last few years.
Android is another famous example.
Historically speaking, between average Android device and average Chromebook, latter is far easier to get mainline kernel + "normal" Linux distro running, e.g: 8 Chromebooks vs. only 1 Android device (and even that is a dev. board) in official Arch supported hardware list:
https://archlinuxarm.org/platforms
Alas, new Chromebooks are no more. "Successor" Googlebooks are all Android.
> in official Arch supported hardware list:
ALARM isn't official Arch, so this also isn't an "official Arch supported hardware list". Arch is currently still only x86_64 and everything else is at best unofficial if not just straight up unaffiliated.
(do note that this might change soon-ish™ considering [0], but I think they want to first get their automated build infrastructure ready)
[0]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests...
So Arch on ARM is basically limited to an SoC with at most 8GB of RAM? It looks like we are still very far from a mainstream ARM motherboard with a socketed CPU, upgradable RAM and support for discrete GPUs. Until then, I see no reason to move away from x86.
As is WebOS, Raspberry PI, Beagle Boards, netbooks, PS2Linux, PS3 OtherOS,....
Regular OEMs will never give their differentiation factor freely.
Even Linux OEMs like Tuxedo apparently cannot get access to hardware specifications, and have to reverse engineer their own devices.
> this work is focused on laptops with Snapdragon X2 Series. It does not currently cover desktop form factors, earlier Snapdragon X platforms, or other development boards. Readiness also varies by OEM design and Snapdragon X2 Series variant.
So same ARM BS as usual - AMD and Intel x64 are still the kings when it comes to out the door Linux support.
I'll buy a ARM PC when I can swap its motherboard CPU and GPU to a newer gen and my existing Linux install boots up without having to flash a new bootloader and custom vendor kernel with proprietary GPU blob.
"I'll buy a ARM PC when I can swap its motherboard CPU and GPU to a newer gen and my existing Linux install boots up without having to flash a new bootloader and custom vendor kernel with proprietary GPU blob."
add in swappable batteries like older laptops and phones, and I would as well. not now though.
Makes me wonder how long until Framework starts shipping ARM-based motherboards. They already sell a RISC-V-based motherboard for the 13.
I think this is huge. I thought about getting one of these chips a long time ago, but linux support was just a breaker. I ended up sticking to my current laptop and getting a macbook some years after
The "original" X Elite was also supposed to get good linux support but it unfortunately never happened.
So hopefully the X2 will actually happen!
Every single one of the "X" series had this identical announcement.
It's not huge because Qualcomm has proven that they'll continue to half-ass support until the next product is announced and then they'll disappear into the ether.
This!
I've had a Snapdragon X Elite laptop for 2 years, constantly trying to get Linux off the ground on it. Didn't happen (well, technically, toward the end of that period, there was an unsupported port of Ubuntu but it lacked half the drivers). And yes, when I bought it there was a very similar announcement from Qualcomm promising first-class Linux support. So I wouldn't gamble on it (especially considering that prices are crazy) until there indeed is a supported distro.
Yeah, I've really wanted an ARM Linux laptop. But I've known ARM is a crapshoot because of my dealing with other devices. So I held off on the initial X release. Then I saw the X1P (or whatever it was) and Qualcomm put out the exact same "someday Linux up streamed!" Promise.
A competent FTC would be fining them for these false and misleading statements. Until that happens, nobody should buy these thinking Linux will ever be supported.
Yeah, this just sucks imo. I mean I think for the copilot button there was something upstreamed, but the useful stuff wasn't
It potentially can be a good thing, but anyone who is jumping up and down celebrating better wait and see, Qualcomm is more of a lawyer/finance company than a tech company in short a patent troll at heart, so it will be interesting to see what type of fee they want to have the privilege of being on their hardware. In the telecom area historically, they like double dipping.
But they support Android right? Won't that mean kernel support is public already? It would have to be merged into mainline. Or is this about something else?
I mean it technically can run linux. But I think non one actually got any desktop or graphics working. I hope it just happens but you are sadly correct here.
Nah, on many community-supported laptops, basically everything (including graphics) works fine with the exception of a few small issues and unoptimized power management. E.g. https://github.com/jglathe/linux_ms_dev_kit/discussions/36#d...
But it can be annoying to use day-to-day since a lot of stuff is not upstreamed or not integrated into the major distros.
interesting. I mean day-to-day usage is a requirement if you want to buy some of these machines for real. But good to know that graphics works now. Last time I checked it wasn't and that was significantly after launch
This is great news - the Snapdragon X2 Elite Extreme X2E-96-100 isn't too far off the Apple M5 Pro.
[1] https://browser.geekbench.com/processors/snapdragon-x2-elite...
[2] https://browser.geekbench.com/macs/macbook-pro-14-inch-2026-...
Sure, not too far, but single core perf is still. And also still very much behind the new M6 in single core and multi core https://browser.geekbench.com/v7/cpu/389219
For the record, X2E-96-100 is not available in any SKU at this point, only X2E-94-100 is.
Actually, my bad, it is available in the US, but seemingly not Europe.
27k and 33k, in x86 this usually the difference between last gen and current gen.
Yeah, heard that 2 years ago for the Snapdragon X Elite
yeah everyone was hyped and it was said to be getting linux support. Some things were upstreamed into the kernel, but it never really got there
Unless Qualcomm steps in and makes every laptop with their chip work flawlessly, I don't see a reason to step into their ecosystem. Right now it is basically flipping a coin when you buy an X1 or X2 product, as you are basically locked to the vendor's idea of 'support'. Qualcomm should coerce and collaborate with vendors to ensure their products are synonymous with great Linux support so that when I see their brand I know it is a good product.
https://canonical.com/blog/ubuntu-coming-soon-to-qualcomm-sn...
Qualcomm hired some developers back from Linaria and they have been providing support for a bunch of X2 laptops these past two, three months directly via Linux ARM MSM mailing list. I'm surprised it took them this long to announce this publicly.
Hopefully this means Framework releases an X2 mainboard as it would be a match made in heaven.
> Hopefully this means Framework releases an X2 mainboard as it would be a match made in heaven.
My friend showed me his brand new Framework the other day, but I couldn't hear his spiel about its features over the noise of its fan!
Was that Framework 13 Pro? I thought these were supposed to have Panther and be much more efficient and quiet?
Ooh, an X2 Elite Extreme Framework laptop with Linux supported would be very tempting.
Yeah - especially if it could drop into existing framework laptop shells.
That's the dream. But I am quite sure Framework is looking into it, if not only because Windows on ARM is gaining traction, which means developers need an ARM machine to develop. I can imagine some would want two identical machines, one with X86_64, one with aarch64.
*Linaro, sorry for the typo
Didn't they say something similar about the first ones?
Consider me cautiously optimistic.
Qualcomm has been upstreaming Linux kernel support for the Snapdragon X for the past 2 years or so, but the community is still having issues with drivers and firmware on devices. I bought a surprisingly capable Lenovo mini PC with a Snapdragon X at a massive discount and it's stuck on Windows 11 for now.
> Qualcomm has been upstreaming Linux kernel support for the Snapdragon X for the past 2 years or so, but the community is still having issues with drivers and firmware on devices.
Is QCM slow to upstream or are they doing things in an incomplete manner or is there some other reason?
I'm trying to imagine a world where intel or amd releases a new platform/chip and it takes _two years_ to get linux booting on it
With x1 it was worse. They were literally demoing them running Debian because windows was not ready, but after release silence.
Yeah there was a blog post about it but seems not much came from the effort
> but seems not much came from the effort
That's been my experience dealing with QCM based devices running linux in the past. Some OEM buys a batch of chips, gets a reference design and an old version of the linux kernel with a zillion out-of-tree hacks and patches that make updates impossible.
I generally advise clients to use rockchip as they have _very_ good mainline support and put any QCM modem at the end of a USB connection so it doesn't hold the product back.
> Consider me cautiously optimistic.
Consider me dangerously pessimistic
https://www.qualcomm.com/developer/blog/2026/09/announcing-l...
Thanks. This link has more detail about Linux support. I submitted it separately for discussion.
https://news.ycombinator.com/item?id=49824189
Sounds good, as long as a standard Linux distro can replace whatever operating system ships with these machines.
If they want their platform to be a first-class citizen of Linux, they should commit on a mandatory device-tree release for all products.
Not some flaky "one release sometime after launch", a fully integrated release-chain for all components needed to boot Linux on any X2 series device
That's not a full solution... proper platform would have backward compatibility, so an OS from today will work on hardware released in 5 years.
That is why The Year of GNU/Linux desktop is never going to take off as such.
It was already proven by the whole netbooks, Android, WebOS, and ChromeOS.
Linux yes, as cost cut factor, and as means to power specific commercial products, running on top of WSL/Virtualisation Framework, or expensive racks on hyperscalers.
The whole community stuff, from OEMs point of view, only when it really has to be.
If the upstream is properly done (that is a big if), this can be a go-to choice for the Linux laptop because it has much smaller config variations compared to Intel-based laptops: Everything from wifi (and even modem?), to audio, to camera ISP is included in the single SoC. If it works it works.
People have had a lot of issues with drivers and locked-down firmware on Snapdragon devices, so even with official Linux support for the chipset, the devices themselves could still be a nightmare to get working.
I wonder how long someone can spend a pile of tokens and start shredding these firmwares down to their actual instructions/code.
I don't think so. Every device has locked down firmware really these days, it's not an issue (most peoples BIOS/UEFI/etc is very much not open source).
If the drivers are upstreamed and good, it should work well.
Aren't all the Android Snapdragon phones already mostly there?
Android phones don't need (and often don't have) upstreamed "drivers". They use qualcomm's closed-source code. Also, Android user land driver (HAL) isn't useful for non-Android Linux distros.
Yes, with proprietary blobs. Oh, and also running a version of the Linux kernel that’s been out of support for years (on some devices, not all).
This is the danger when you don’t upstream your shit. Now you’re stuck on kernel 3 or 4 because your chip vendor is lazy. And Qualcomm has got to be one of the laziest.
Why only for these "desktop" socs? Why couldn't Qualcomm partner with Debian/Ubuntu to bring support to their mobile chipsets? Why can't Qualcomm partner with PostmarketOS to help recycle old devices and avoid e-waste?
Well, in case anyone else is wondering, I have the answer. That's because Google is maintaining a cartel, the "GMS" cartel in short. Due to intense lobbying and incredibly weak antitrust enforcement, this cartel still continues to operate globally, keeping soc makers like Qualcomm, Mediatek and Unisoc in chokehold. We won't see any real competition in the smartphone space unless it's destroyed, but market forces alone can't do that.
Tell us more about how it's Google who is preventing Qualcomm and Mediatek from upstreaming all their drivers?
Google controls the Android ecosystem (restricts what OEMs can do) and employs various practices to ensure there's no alternative besides Apple (this duopoly suits both of them). Chipmakers essentially focus on ensuring they can sell access to BSPs which meet Google requirements, as there's no real alternative for smartphones. If you're not Apple, these chips are meant to be used with GMS Android, that's the expectation.
If there were alternatives (like on the desktop and for some parts of IoT) it would be more cost-efficient to upstream everything, but with the current situation it's fully up to Google.
When Google wanted them to move all their chip-specific code to modules (GKI), they had to do that. And if someone at Google randomly decided "hey, now you'll upstream this stuff", then guess what? They'd have to follow, it's how this monopoly works.
I think the GKI initiative is great, personally. I've worked with chip companies that are super-resistant to upstreaming their code, and just give me a fork-of-a-fork of the kernel and kind of say "welp, good luck maintaining that unless you pay us".
I don't love how much control Google is exerting over Android, and I don't love having to use their signed kernel. But I do prefer that vs. being stuck on an abandoned vendor kernel. If I have to accept low-quality proprietary kernel code, I'd rather keep it in small module-shaped boxes.
Companies like Qualcomm complain about this, but their historical practices are what drove Google to mandate it in the first place.
When can I buy one ?
I want the stuff to work, I want Qualcomm to provide an easy process to grab a X2 Elite Windows Laptop and install Linux.
No magical binary blob extraction. I want everything tested.
With SteamFrame out we might even get decent gaming !
They give 2 separate dates for debian and ubuntu which looks to me they will just release drivers but haven't decided to be good citizen and have their drivers in the mainline kernel source tree.
In other words: it might be a trap and you could get screwed in n years if they stop maintaining it and some kernel changes make the driver not compilable on newer versions.
Getting linux on the Surface laptop series would be amazing. Good battery life on a small laptop running linux is my ideal device.
The build quality of Surface seems quite good, seems like unibody aluminum.
Up voting based on the title alone, though I'm not expecting much.
If we could have a similar experience to Intel-based ThinkPad Carbon X1 or T series with performance, graphics, Wi-Fi, battery life, suspend/resume, external displays, etc, that would be awesome!
Apple hardware is awesome but I want to run Linux.
It will take years for Linux users to trust Qualcomm again.
It has been so many attempts to run Linux on this chips without any collaboration from Qualcomm. Companies even drop support after years of development.
Qualcomm provided efficiency (battery life). But intel is catching up fast to make Qualcomm irrelevant.
Welcome, but too late.
Hmm... no news on whether there's X11 support or if we're stuck with just wayland.
Wayland is a protocol that can be implemented by a compositor. Since Wayland intentionally chose to only support a subset of the functionality of a display server like Xorg, it became possible to rip out the Xorg specific hardware drivers and make the X11-supporting Wayland compositor known as XWayland possible in the first place.
"We're stuck with just a protocol that can have arbitrary implementations including full backwards compatible X11 servers"
The words "full backwards compatible" are not entirely true in my experience.
X11 is ancient history and not a fit for tiling GPUs found in mobiles socs
Sure, but all the software I want to run uses X instead of Wayland. And it would be cool if we could get reliable key remapping under systemd and wayland.
How open will the boot stack be for this chip? Qualcomm has historically been pretty bad about this: mandatory closed-source bootloaders, mandatory closed-source hypervisors, mandatory closed-source TEEs, forked UEFI, etc.
An open Linux is hobbled without the rest of the stack.
KVM works this time. For the rest you need to calibrate your expectations against mainstream laptops not RMStops.
I very much want this, but I also do not trust Qualcomm /at all/. Would love to see a performant alternative to current-gen M series which runs Linux. Can you imagine a true ultrabook style laptop w/ great battery life, minimal heat output, and excellent performance in a compact form fanless form factor running Linux? Would be amazing. But Qualcomm has a long track record of bait n switch w/ Linux community and relying on proprietary blobs, no documentation, and aggressively enforcing IP in ways which are detrimental.
Support is coming because of Googlebooks, not because Qualcomm out of the pureness of their hearts is embracing GNU/Linux.
Expect binary drivers for specific releases of Ubuntu and Debian.
Also here is an answer to other day's why people still use Ubuntu.
Finally, the dumb company woke up. On one hand, it’s good. On the other hand, bad Qualcomm is known as a patent troll. We shall see if they can mend their ways…
Part of this is probably motivated by the fact that Microsoft and Nvidia have teamed up.
The Snapdragon X chips are already wonderful with Windows 11 ARM64, so I'm pretty excited to see how much Linux will be able to squeeze out of those!
I always imagined a world where the steam frame used an ARM chip as an ultimate f you for not only microsoft, but intel and amd.
yeah, heard that before...2 years ago.
I'd buy one on its public release date if it is linux ready.
A x2 based workstation will also be very cool.
Funny how Qualcomm is juggling three OSes to sell these chips while Apple just stuck a phone chip in the Neo and called it a day. Controlling the chip, the OS, and the actual computer is a huge advantage. Apple is more than one study case on competitive analysis.
This is entirely Qualcomm's doing. If they supported Arm SBSA/UEFI+ACPI like some other Arm chip companies (e.g. Ampere) you could boot a generic Linux (or indeed BSD) Arm distro on their chips no problem. Controlling the entire platform is not necessary, just follow the standards.
Qualcomm expects to be paid. a toll/fee by each one of the Linux Distro’s for the privilege of being on the hardware with their chips in the device that is their history and one of the reasons why Apple spent five years kicking them out, they very definitely don’t act as a charity, so in the end, it will be interesting because someone is gonna pay their fee. the end user maybe?
I don't think that would help with GPU or NPU, which another comment states are the drivers that Qualcomm are upstreaming.
AFAIk this has nothing to do with Qualcomm but with vendors and Microsoft.
All they have to do is support Windows and get their stuff upstreamed in the Linux kernel, no need for specific distro support. I'll never understand why SoC manufactures insist on bespoke kernel/distro pairings.
>I'll never understand why SoC manufactures insist on bespoke kernel/distro pairings
So that if you want to use the next distro release you will be forced to buy their next-gen chip because that's the only supported one on that distro. D'uh.
> I'll never understand why SoC manufactures insist on bespoke kernel/distro pairings.
Because getting your stuff upstreamed in Linux is more work than releasing a custom kernel.
What advantage? I'm always a bit shocked to see people say this without qualifying it at all.
On the contrary, Apple has to do a lot of greenfield work by refusing standards like UEFI, Vulkan and normal filesystems. They end up reinventing the wheel just to support the same featureset that Qualcomm, Nvidia, AMD and Intel all generally planned for.
Apple’s advantage is being the last vertical computer company from the 1980s speaks for itself. having control of the hardware and the operating system software with the ability to create new ecosystems is their advantage in comparison to hardware or software only companies, Note: the tech world would be a better place if Sun, SGI, Digital, Acorn, Motorola of Schaumburg, Illinois had been able to survive the Microsoft/Intel onslaught.
Even Apple forfeit x86's onslaught. MIPS was a dog's dinner compared to early x86 chips, and Steve Jobs knew this well since he worked at Pixar when they were preparing to throw away SGI machines to replace them with Linux boxes. Digital Domain, Dreamworks and Industrial Light & Magic all all abandoned UNIX workstations because they sucked. All of those companies deserved to die.
The tech world is a better place without full-stack UNIX grifters demanding a pound of flesh. Eventually macOS will be buried alongside them, as Apple has clearly has no intention to develop a fully-featured OS for Apple Silicon.
Is it more work to support a completely proprietary boot path or three different "standard" boot paths?
Hint: you would know the answer if you are familiar with the Windows, Linux and OSX boot process.
Advantage of commitment and integration. Apple doesn't need to worry about critical vendors not cooperating because sticking with x86 is less risky.
Apple didn't have to worry about that when they supported cross-industry standardization efforts. The only reason dGPUs are broken on macOS is because of Apple's software choices.
You sound very ridiculous. Why is Apple obligated? to follow Nvidia? or AMD? or Microsoft for that matter?
Intel said no to designing iPhone chips, IBM and Motorola couldn’t see a future of faster/better chips to meet the demands of future tech devices, Apple with that crazy CEO, Steve Jobs? Had to go it alone and the rest is history.
The Apple Silicon design group appears to be on a roll. What next? Bringing memory in house? I think they will. Because that will be the only way they can build the devices they want to build at a reasonable price going forward.
Before you yell no what is it about the last 28 years have you missed? They seem to be able to execute long-range projects when it comes to hardware and software in comparison to their tech peers, looking forward to the M7 ultra, in-house memory and the C3 modem.
I didn't say they were obligated. I just said that they didn't have these problems when Apple was a cooperative member of industry-spanning consortium efforts.
> What next? Bringing memory in house? I think they will.
It's okay to say that you don't know anything about chip fabrication, instead of making silly assumptions like this.
Omg, words can't describe how completely botched the Snapdragon X series chip launches have been.
You hold them up to the Apple M series rollout and its just hilarious how far "the competition" is behind when it comes to laptop low power CPUs
Yay!
Please sell >1 model of computer with X2 EE (elite extreme) please please please. Not that #1 was bad at all but more please! https://www.notebookcheck.net/Asus-Zenbook-A16-Laptop-Review...
I really hope it's like 2031 and we're swimming in way too many of these. Running great Linux. How sick would that be. (And X4 is running mainline great too).
While I am somewhat negative on ARM/RISCV systems due to there being like 50 different boot systems and ASIC setups, I am cautiously optimistic that something like the A16 will end up unintentionally becoming sort of a standard via a large amount being sold.
I suspect in the next 5 years something like this will come up.
Ironically that's being fixed by Microsoft forcing UEFI.
Unironically, the serious reason I don't want to embrace Snapdragon, is because: Qualcomm.
If Microsoft and Nvidia team up work out, you won’t have to.
Yeah, I’m already trying to avoid that blob as well, pretty much - not easy, I know, there are great reasons to follow their dogma .. but Snapdragon-level SOC’s are for me, as a long-time ARM user/developer with record shipping SKU’s, kind of a dime a dozen, kind of thing .. and also the tax of the MS/Nvidia commoditization, well, stings a bit ..
I am thoroughly enjoying the trouncing that Apple is giving everyone in terms of exploiting ARM - it is bothersome however in many ways true — I just am not so sure the open-ness of things has been fulfilled as much as, say, the good ol’ OpenPandora days, if you catch my drift ..
Everything has to be open. No blobs, compilers everywhere as a first-class application, well managed open source repo’s for everything, updates free of charge around a namespace that is large and wide for many, many communities of developer/user interactions occur, unimpeded by needing to ask permission to sign things, but rather just letting everyone sign things together easily from user to developer-level, and let ship new apps from well-oiled repositories ...
No, I think the tooling in the MS/NVidia domain is going to be pretty much the lynchpin. I really, really prefer 100% open source, to the extent it is feasible..
Lenovo has one (it's a Yoga, not a Thinkpad though).
Their Elite is not the 'Extreme', just a regular one, X2E-88-100, with a significant performance difference.
You mean, Snapdragon X2 series support is coming to Linux.
Unless they're enforcing signed boot from the factory, it's up to software to run on hardware.
> Snapdragon X2 Series is expanding to Linux, adding support alongside Windows and Googlebook
Is Googlebook a new name for chrome os? Or is it a typo?
They decided that instead of having an Android runtime on top of ChromeOS they would port the ChromeOS desktop features to Android. A Googlebook boots Android.
Fascinating. I did actually do a quick search and all the results were for google books, not a computer os.
Is it all upstream? Is there a newer part coming with upstream support on day 1 like every Intel laptop I’ve had for the last decade+?
Betteridge's law. The answer is 'no'.
LLM these days should make it easy for Qualcomm to add such support.
aarch64 driver situation is still an unsolved mess. How far behind is thunderbolt support?
No Thunderbolt support is mentioned for Snapdragon X2 [1].
[1] https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets...
It's called USB4 now.
6 years since M series and arm PC still hasn't picked up
[dead]
This really is about business strategy than any technical effort these days. Porting code should be among the easiest things for the llms to do these days
Man I’m hoping this support extends to older Snapdragon X2 stuff as well as the current crop of chips. There’s a lot of VR/AR headsets out there otherwise running proprietary operating systems and left to rot that a generic Linux distro like Debian could rescue, though Qualcomm’s history makes me doubt those chips will ever see the same support their newer, AI-focused ones are with this announcement.
Still keeping my fingers crossed that in the near future we can throw Linux onto an HTC Vive Focus or a Meta Quest and re-take ownership of our data and devices, but it’s strictly hopium at this point.
It's horrifying that anyone takes Qualcomm seriously after their long history of broken promises.
Remember the Snapdragon Insider phone that was almost instantly abandoned? I think it never even got a single major release update.
They took everything that was open about Atheros WiFi and closed-sourced it by putting everything into binary blobs.
Most of the laptops from the last year or two are still not usable. Audio and webcams will almost certainly never be fully supported, or even supported well enough to be usable.
Looks like they're learning!
i've been using a snapdragon x elite and loving it, albeit on Windows. 32GB ram
I have a 64gb ram one, love it.
Three cookie banners. I bet the announcement is slop that doesn't even answer relevant questions.
Weird, I only see one, even with ublock origin disabled.
Is your computer compromised? I see no banners.
very good!
Now if only Linux were to conquer the desktop as well ...
Beauty, I want beauty.
[dead]
Linux evry where haha washing_machine to trafic light evry single sector