Qualcomm put a developer preview of Linux for the Snapdragon X2 on the internet last week, paired with Debian 13 “Trixie” as the reference image. The hardware part is not the story. The story is that the drivers are landing in mainline (the upstream Linux kernel tree every distribution builds from) instead of in a Qualcomm-only patch branch that goes stale the moment the silicon team ships the next chip. That sounds like a small thing. It is not, and I want to explain why.
I will also be specific about what the preview does not deliver. There is a real chance someone reads the announcement, buys an X2 laptop, and discovers that sleep states do not work, microphone support is hit-or-miss, and the only thing that boots cleanly is the reference image. I want to head that off before it happens.
What “mainline” means in this context
Most ARM laptops that ship with a Linux option do it through a private kernel patch set the silicon vendor maintains in parallel with upstream. Sometimes that patch set gets merged, often it does not, and the result is a kernel fork that the vendor commits to backporting (manually porting newer fixes onto older code) for the lifetime of the chip. Backporting is expensive, and it is the reason so many ARM laptops ship with broken Wi-Fi six months after launch: nobody is keeping up.
The mainline bet is the opposite. The vendor pushes drivers into the upstream tree, distributions pull from upstream on their normal schedule, and the silicon team can stop maintaining a fork. Qualcomm is saying, in writing, that this is what they intend for the X2.
The practical test of that bet is whether the drivers actually land in mainline, and whether the Hexagon NPU driver (FastRPC) goes the same route. That is the part that unlocks on-chip AI acceleration (running models on the laptop’s own neural processor rather than over the network), and it is the part I am watching.
What the preview actually delivers today
The preview boots. That sentence sounds dismissive, and it is not meant to be. The boring plumbing is what kills most ARM-on-Linux projects, and the plumbing here works.
- USB, PCIe, and the Qualcomm peripheral engine (UART, I2C, SPI) are functional.
- Display output works through Mesa’s Freedreno driver stack (the open-source GPU driver for Qualcomm chips).
- Vulkan 1.3 acceleration is available through Mesa’s Turnip driver, which is enough for browser GPU and some Steam titles.
- OpenCL compute is available through Rusticl, which means GPU compute works without proprietary blobs.
Audio is the rough part. Speakers work through the standard ALSA (Advanced Linux Sound Architecture, the kernel-level sound system) path, but microphone support is unreliable across chassis. Some laptop SKUs will record fine. Others will not. Treat this as a debug surface, not a finished feature.
Sleep states are also unfinished. Closing the lid will not reliably suspend the laptop, and resume after a forced sleep has been reported as inconsistent. If battery life matters to your test, factor that in. You will be measuring idle drain on a laptop that thinks it is on.
What to actually run if you want to test
I am going to assume you are a developer or a distro maintainer, because that is the audience this preview is for. If you are an end user, skip to the bottom line.
If you have the time, run these tests in order, and file what breaks.
- Build the Debian OS layer from the unregistered path. This is the fastest signal you can produce. If prebuilt firmware builds cleanly on your machine and the resulting image boots to a desktop, you have a working baseline.
- Boot the flashable image. This skips the build entirely. It tells you whether the reference image works on real hardware, which is a different signal from “your build works.”
- Run a graphics workload. A browser playing video, a small OpenGL demo, anything that exercises Freedreno. If the GPU path dies under load, that is worth a kernel bisect (a methodical search through recent kernel changes to find the one that introduced a bug).
- Suspend and resume. Even if it does not work, document what happens. Sleep bugs are usually one-line fixes once you can reproduce them.
- Plug in a USB device you actually use. Headset, external SSD, drawing tablet, whatever your real workflow needs. Default USB enumeration (the process of detecting and configuring devices as they are plugged in) often hides bugs that only show up with specific device classes.
The point of that list is to triage what is worth a kernel bug report versus what is just preview roughness. Most things in the second category should not block X2 from being a useful laptop. Things in the first category might.
Two paths and a real host-architecture gotcha
The docs offer two ways in.
- Unregistered. Use prebuilt firmware binaries. No Qualcomm developer account required. Fastest path to a working build.
- Registered. Sign up, get full firmware source, build everything from scratch. Slower, but you can patch the firmware if something is wrong.
There are also prebuilt flashable images for anyone who wants to skip the build entirely.
The host gotcha caught me on first read. The Debian OS layer build wants an ARM64 host on Ubuntu 24.04 LTS or later, or Debian Trixie. The firmware build wants an x86_64 host on Ubuntu 22.04 LTS or later. Those are different machines. If you only own an Apple Silicon Mac, you cannot do the firmware build natively. You can run it under an x86_64 VM (virtual machine), but that is slow. Plan accordingly.
What I would tell someone deciding whether to test
Three pieces of advice, addressed to the version of you that is about to spend a Saturday on this.
- Test on hardware you can afford to brick. A bad kernel bump can leave you with a laptop that does not boot. Recovery is a flash step, not a one-button reset. Keep a second machine or a serial console handy.
- File one bug at a time, with a reproducer. “Wi-Fi sometimes drops” is not actionable. “Wi-Fi disconnects within 30 seconds of association when running kernel 6.11 with brcmfmac driver on X2 reference hardware” is actionable. The kernel maintainers cannot fix what they cannot reproduce.
- Watch the mainline kernel mailing list, not the Qualcomm blog. The mainline landing is what matters. The Qualcomm blog will keep announcing features that have not landed yet, and you will get impatient. Patience is the work here.
Trade-offs
The preview is honest about what it is. That does not mean it is free.
Your time is the first cost. A real test pass on this preview is a weekend, minimum, and you will hit at least one kernel bug that costs you an afternoon. If your weekend time is more valuable than the marginal contribution, send your test report to a maintainer who is already running the preview instead of duplicating their setup.
Risk is the second cost. Mainline landings are a long-term bet. If Qualcomm slips on the Hexagon NPU upstreaming, or if the kernel team rejects the FastRPC driver for design reasons, the preview becomes a fork nobody wants to maintain. That has happened to every other vendor who promised mainline and then disappeared. The public roadmap and the build scripts are evidence that Qualcomm means it, but I have been disappointed before.
Preview-software roughness is the third cost. Sleep, microphone, and certain peripheral classes are rough. If you buy an X2 today expecting a daily-driver Linux laptop, you are going to be unhappy. Wait for the distro images to catch up.
Bottom line
If you are an end user, wait one or two kernel cycles. The right time to buy is when your distro of choice ships an installer image that recognizes the hardware without tweaks. That has not happened yet.
If you are a kernel developer, distro maintainer, or hardware enablement engineer, this preview is the green light. Run the test list above, file the bugs that matter, and watch the mainline mailing list instead of the marketing blog. Qualcomm did the boring, important work by betting on mainline. The rest of us just have to keep the build moving and report what breaks.