alt Hacker NewsI 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).
Replies
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
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.
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.
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.
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.
and speed doesnt matter at all if no drivers work
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