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).
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: <a href="https://github.com/torvalds/linux/commit/3330b71caff6cdc387fdad68a895c9c81cc2f477" rel="nofollow">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.
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. <a href="https://armbian.com/" rel="nofollow">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.
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.
hurricanepootis · · focus · HN ↗
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).
avhception · · focus · HN ↗
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: <a href="https://github.com/torvalds/linux/commit/3330b71caff6cdc387fdad68a895c9c81cc2f477" rel="nofollow">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.
leoedin · · focus · HN ↗
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.
necovek · · focus · HN ↗
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.
pjmlp · · focus · HN ↗
avhception · · focus · HN ↗
a96 · · focus · HN ↗
opan · · focus · HN ↗
someonebaggy · · focus · HN ↗
everforward · · focus · HN ↗
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.
smashed · · focus · HN ↗
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.