Hacker News Reader

Comment by hurricanepootis | Hacker News Reader

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).

View on HN

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

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.

> 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.

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

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

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.

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.

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.

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.

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.

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.

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.

> 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 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.

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.

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.

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.

> 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

Reply on news.ycombinator.com