Qualcomm announced an early developer preview of Linux on Snapdragon X2 Series in September 2026, and the phrasing of that announcement tells you where the hard part lives. The post describes a validated reference environment of a Debian 13 user space on a custom kernel, and it lists what is already in the mainline tree: boot and system bring-up through UEFI plus systemd-boot, core I/O for USB, PCIe and the QUP peripherals, graphics work in Mesa through Freedreno, Turnip and Rusticl, and fastRPC driver upstreaming that opens up the Hexagon NPU.
Read that list again and notice what it is. Every one of those items is a hardware enablement problem, and every one of them has a technical answer that somebody can write and review. Drivers land. Device trees get reviewed. Kernel configuration options get set. The project has a public mailing list, a review process, and a definition of done that everyone involved already agrees on. If that were the whole story, then bringing a new ARM laptop into a distribution would be a matter of waiting for the next kernel release.
It is not the whole story, and the people who actually ship images on these machines have said so in print. The AArch64 Laptops community guide for distribution integrators opens with a blunt question about why this is so much harder than it looks, given the seemingly good kernel support, and then answers it. Some of the difficulty is technical, some of it is organizational, and a meaningful part of it is licensing. Recognizing which of those three you are looking at is what separates a bring-up that takes an afternoon from one that consumes a month.
The Kernel Side Is Now Boring, Which Is the Good News
Start with the part that works, because it sets the baseline for everything else. The AArch64 Laptops device status page has been tracking per-laptop feature checklists for years. A Snapdragon 850 laptop from 2018 has every box ticked: boot into the bootloader, boot the kernel from the rootfs partition, text console, SD card storage, USB, a framebuffer desktop, keyboard, touchpad, touchscreen, on-board UFS storage, WiFi, Bluetooth, LTE, accelerated graphics, and audio.
That list is unglamorous and it is exactly the point. The kernel team behind these machines has spent the intervening years pushing patches for each subsystem, and the pattern repeats across generations. Qualcomm posted the first Snapdragon X Elite patchset one day after announcing the platform in October 2023. By the Linux 6.8 and 6.9 cycle, the merged list already included pinctrl, interconnect, clocks, power domains, the SMMU, the QUP serial engine block, system cache, the PMIC sound machine driver, USB DWC3, reference board support, the ADSP and CDSP coprocessors, multimedia clocks, PCIe and eDP and USB PHYs, and NVMe over PCIe. The next cycle added USB host, on-board display, GPU, memory DVCS, CPU frequency, audio capture, external DisplayPort, suspend and resume, camera, and video decode.
For the X2 generation the staged plan continues in the same shape. The initial enablement stage covers boot through systemd-boot, low and high speed I/O including UART, I2C and SPI on the QUP block, the Mesa graphics work, fastRPC for local inference, and system-wide power and thermal management. The expanded enablement stage targets broader peripheral coverage and better reliability, described as the point where building and testing real workloads becomes practical rather than experimental.
Qualcomm's own framing of why they invest here is worth quoting in substance: out-of-tree patches may help early bring-up, but mainline support is what distribution maintainers and long-term developers can build on across kernel releases. That sentence is the thesis of this article expressed in one line. A vendor can enable their own reference device with a private tree and get a working demo. What they cannot do that way is make the platform something a distribution is willing to carry.
Device Trees Move the Problem Instead of Solving It
The first genuinely hard thing is the hardware description. On x86 the firmware describes the machine through ACPI, and the kernel walks the firmware's own description of power rails, controllers and buses. On most ARM platforms the kernel instead consumes a device tree, a much lower level document that does not contain arbitrary logic and therefore requires Linux to know far more detail about the board.
The consequence is spelled out in the distribution integrator guide. When an ACPI system powers up a USB controller, the firmware handles the sequencing and the kernel does not need to model every rail involved. On a device tree system the kernel models those rails and drives them itself. Components that x86 firmware programs invisibly, like the USB signal repeaters on a laptop mainboard, have to be described in the device tree and have a driver written for them, wired up correctly to receive events. If you enable the repeater driver in the kernel but leave the module out of the initramfs, you get a machine that boots from its internal disk and cannot boot from a USB drive, which is a memorable way to discover your mistake during an encrypted-disk install.
The guide's second structural point is that device trees and kernels do not separate cleanly the way ACPI and kernels do. Device trees are meant to be forward and backward compatible with kernel versions, and in practice they are not always, because drivers and the tree fragments that describe their hardware frequently land in the same patch series. If the tree describing your panel predates DisplayPort alt-mode support, a newer kernel will not conjure that feature, because the description itself is the input.
There is a third point in that guide which is the most uncomfortable one for anyone who has debugged peripheral failures. The ACPI that Qualcomm laptops ship with is not supported by Linux and probably will not be for the current generation, and the vendors do not ship a device tree in firmware as an alternative. So a distribution has to install device tree files into the EFI system partition and pick the right one at boot based on which laptop is actually running.
That selection problem has no clean answer. The guide describes two working approaches. In systemd version 257 and later, a unified kernel image can embed multiple device trees and select one by matching EFI hardware IDs, with the practical benefit that the device tree lives inside the signed PE binary and therefore survives secure boot validation. The alternative is a separate EFI driver that loads device trees from a well-known directory on the ESP using its own internal hardware ID database, the approach used by the generic ARM64 EFI target in postmarketOS. Both work. Neither is a standard, and a distribution has to pick one and maintain the device list.
Firmware That Cannot Be Redistributed
Here is the part that stops being an engineering problem. Many of the useful properties of these systems come from coprocessors, and those coprocessors run firmware. Some of that firmware is packaged in linux-firmware, but for most devices there is no clear license and packaging is not possible. The firmware therefore has to be pulled off the Windows partition, which means the only supported way for a user to get firmware updates is to keep dual booting, periodically boot back into Windows for the update, and copy the new firmware across.
The distribution guide states this plainly and admits that solving the licensing problem is outside its scope. The practical advice it gives is to build a manual or semi-manual process that users can follow to extract the firmware during or after installation, because that is the best option available today.
Tooling exists for the extraction step, and it is interesting precisely because of how many special cases it encodes. One widely used script mounts a Windows system partition, plain NTFS or BitLocker, locates the Qualcomm DSP firmware files under the Windows driver store directory, and builds a Debian package that installs them into the firmware updates directory before rebuilding the initramfs. It chooses the firmware set by reading the device tree model string and matching it against a hardcoded table.
That table is the artifact worth reading. It contains exact device strings for laptops from Acer, ASUS, Dell, HP, Lenovo, Medion, Microsoft and Samsung, and the script aborts with an error if your model is not listed, with a comment instructing you to extend the case statement to add support. The firmware files themselves are a grab bag of DSP images and JSON descriptors with names that encode SoC variants. The limitations section is equally blunt about scope: only NVMe devices are scanned automatically, and the script assumes an arm64 Debian or Ubuntu target with initramfs-tools present.
So the "just install Linux" path on these machines includes a step where you extract proprietary binaries from your Windows install, wrap them in a distribution package whose device list a volunteer maintained by hand, and then rebuild your initramfs so the display and audio coprocessors can come up on the next boot. None of that is a kernel bug. All of it is real work that every distribution has to either duplicate or depend on somebody else to maintain.
import subprocess, json
from pathlib import Path
DT_MODEL = Path("/proc/device-tree/model")
FW_DB = Path("/usr/share/qcom-firmware-extract/devices.json")
def read_model() -> str:
# device-tree model strings carry a trailing NUL byte
return DT_MODEL.read_bytes().rstrip(b"\x00").decode("utf-8")
def firmware_dir_for(model: str, db: dict) -> str | None:
# the shipped table matches on exact or prefix strings such as
# "x1e80100/LENOVO/21N1" and "glymur/ASUSTeK/UX3407NA"
for entry in db["devices"]:
if model == entry["model"] or model.startswith(entry["model"]):
return entry["firmware_dir"]
return None
def main() -> int:
model = read_model()
db = json.loads(FW_DB.read_text(encoding="utf-8"))
fw_dir = firmware_dir_for(model, db)
if fw_dir is None:
# upstream behaviour: abort instead of guessing a firmware set
print(f"unsupported device: {model}", file=sys.stderr)
return 2
return subprocess.call(["/usr/libexec/qcom-firmware-extract", "-d", fw_dir])
if __name__ == "__main__":
raise SystemExit(main())
Configuration Work That Never Ends
The middle layer between kernel and firmware is kernel configuration, and the distribution guide treats it as its own discipline rather than a footnote. The upstream mandate is that the arm64 defconfig should carry everything needed to boot at least the well-supported laptops like the ThinkPad T14s and the X13s, and distributions are advised to derive their kernel configuration from that defconfig so new device support trickles down without anyone making a deliberate decision.
That advice sounds straightforward until you try to work out what your laptop needs on top of it. The guide offers a technique that is refreshingly honest about its own limits. The kernel ships a script that maps device tree nodes to the drivers and kernel config options that could bind to them, so you can feed it a compiled config and get back a list of options that are switched off but probably should be on. The example output pairs a clock controller node with its compatible string, the driver file that matches it, and the config symbol that enables it, which tells you the symbol's current value is off and needs to change.
The guide follows that technique with a warning that the tool produces incorrect and spurious output for some generic nodes, that its output should be validated against a second source of truth, and that options mentioning other vendors are probably false matches. It recommends falling back to searching the device tree for your panel, finding its compatible strings, grepping the driver directory for those strings, and then opening the Makefile to read off the config symbol. When all of that fails there is the deferred devices debug directory, which lists hardware that did not probe, and an IRC channel where people will help translate an error message into a symbol name.
Two details from the porting checklist explain why these machines are fragile in ways that look like bugs but are not. First, the guide advises always using the newest available kernel, because Snapdragon laptops pick up fixes and features with every release rather than stabilizing once. Second, it advises passing two command line options that tell the kernel to keep clocks and power domains running even when it believes nothing is using them, on the grounds that the schematics are usually unavailable and some of these resources are modeled incorrectly. That second item is a striking admission: on some devices the working configuration is one where you deliberately over-provision power rails because the description you have is wrong and you cannot see the hardware to correct it.
# map device tree nodes to the driver symbols that should be enabled
scripts/dtc/dt_to_config \
--config .config \
--exclude-flag n \
--include-flag y \
--short-name \
arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
# find the config symbol for a panel by its compatible string
grep -rnwI drivers -e "samsung,atna45dc02"
# -> drivers/gpu/drm/panel/panel-samsung-atna33xc20.c
grep -n "atna33xc20" drivers/gpu/drm/panel/Makefile
# -> obj-<CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20> += panel-samsung-atna33xc20.o
The Initramfs Is Where Bring-Up Gets Honest
If you want a single artifact that captures what is unusual about these platforms, it is the initramfs. On a typical x86 machine the set of modules needed to reach the root filesystem is generic and small, and initramfs generators have gotten good at inferring it. On an ARM laptop the list is longer and stranger, because basic things like display output and keyboard input depend on drivers that a generic machine would never need at that stage.
The guide's recommendation is to sidestep the inference entirely during bring-up: put every kernel module into the initramfs, accept the size cost, and remove them later once the machine works. The reason given is that partially populated initramfs causes race conditions and probe failures that are not retried, which turns a configuration mistake into an intermittent hardware failure that is much harder to diagnose. Only after everything works does the guide suggest using a script to compute the list of modules that are actually loaded and hardware specific.
There is a second-order consequence that the guide mentions in passing and that deserves more attention than it gets. The bare necessities for full disk encryption include being able to see a prompt and type into it, which on these machines means the display and input drivers must be present before the encrypted root can be decrypted at boot. A distribution that gets this wrong ships an installer that works on a reference device and bricks the experience on a laptop with a panel driver it did not include. The hardware is fine. The packaging was incomplete in a way that only shows up on real hardware.
# assemble a bootable image the way the bring-up guides do it:
# kernel image, device tree blob, and initramfs concatenated
cat arch/arm64/boot/Image.gz \
arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dtb \
> Image.gz+dtb
mkbootimg --kernel Image.gz+dtb \
--cmdline "ignore_loglevel earlycon clk_ignore_unused pd_ignore_unused" \
--ramdisk final-initramfs.cpio.gz \
--base 0x80000000 --pagesize 4096 \
--output boot.img
What the X2 Announcement Actually Promises
Go back to the launch framing and the pieces line up. Qualcomm's stated target audience for the developer preview is distribution maintainers, toolchain developers, kernel contributors and hardware enablement engineers, and the post explicitly says that a turnkey install-and-go experience comes later, when distributions adopt what lands upstream. The reference environment is Debian 13 with a custom kernel, the build path starts from upstream sources, and the resources listed are kernel repositories, a Debian image recipe, the arm-msm mailing list, and a developer forum.
That is a vendor doing the part it is uniquely positioned to do, which is making the hardware describable and the drivers available upstream, and then declining to do the part that belongs to distributions. Meanwhile the consumer commitments are separate and have their own timeline, with partners planning Linux support in their devices in the first part of 2027.
The practical lesson for anyone who maintains packages, installers, or internal images for these machines is to stop treating ARM laptop support as a kernel project that will eventually complete. The kernel side is largely a solved and steadily improving problem. The remaining work is a configuration surface that changes with every kernel release, a device tree selection problem with two competing non-standard answers, a firmware distribution problem that licensing has pushed onto end users and their Windows partitions, and an initramfs completeness requirement where a single missing module turns into a laptop that will not boot to its login screen.
None of that gets closed by a release announcement. It gets closed by distributions writing down how they handle device tree selection, packaging the extraction tooling, documenting which modules must be in the initramfs, and sharing the device specific details that make the next laptop cheaper to support than the last one. The guide says as much near the end, in a sentence that reads like a description of the entire field: while there is plenty of work happening in the kernel, a lot of effort is still needed in distributions and middleware to make these devices properly nice to install and use. That sentence is the roadmap, and it does not contain the word upstream anywhere in it.
Originally published on Dispatch.
Top comments (0)