How to Check Whether a Laptop Is Compatible with Linux
Updated
You can judge a laptop's Linux compatibility before buying by checking four component families — Wi-Fi chipset, GPU, touchpad, and power management — against real-world reports in a hardware database such as Linux Hardware Database (linux-hardware.org), then confirming with a Live USB boot on the actual machine. The database tells you what other owners of the same model experienced; the Live USB tells you what this specific unit does. Use both, because a model can ship with different Wi-Fi cards or panel revisions across batches.
The four components that decide most compatibility outcomes
Most "works out of the box" versus "needs tinkering" differences come down to a small set of parts. Check these first; everything else (storage, USB controllers, audio) is usually handled by the kernel without extra work.
| Component | Why it matters | What "good" looks like | What causes trouble |
|---|---|---|---|
| Wi-Fi / Bluetooth | The most common blocker; a single unsupported chip can mean no wireless at all | Chipset with in-kernel driver (e.g., Intel, Atheros, MediaTek parts with mainline support) | Broadcom or very new chipsets needing out-of-tree drivers or missing firmware |
| GPU | Drives display, suspend/resume, external monitors, and video decode | Intel or AMD integrated graphics with mature Mesa support | Very recent discrete GPUs, hybrid setups with poor switching support |
| Touchpad | Affects daily usability more than benchmarks suggest | Recognized as a precision touchpad with gesture support | I2C touchpads that need a newer kernel or a quirk entry |
| Power management | Battery life, suspend, fan behavior, thermal throttling | Suspend-to-RAM works; sensors report temperatures | Missing ACPI quirks, suspend that won't resume, fans that never spin down |
A laptop can pass three of these and fail the fourth, so treat them as separate checks rather than one overall verdict.
Querying the Linux Hardware Database by model or component
Linux Hardware Database collects hardware probe reports uploaded by Linux users, so its value is that entries reflect machines that actually booted Linux — not vendor spec sheets.
By laptop model: Search the model name or vendor plus model number. Probe reports typically list the kernel version used, the distribution, and the detected components. Look for reports on a kernel close to the one you plan to run: a report from two years ago on an older kernel may not reflect current driver support, and conversely a very new model may have few or no probes.
By component: If you already know the Wi-Fi chipset or GPU model (from the vendor's spec page or a review), search that part directly. This is the more reliable route when a model has multiple configurations, because the database entry is tied to the actual chip, not the marketing name.
Reading a report: Focus on whether the component was detected at all, whether the report notes missing firmware or a non-functional device, and which kernel version was in use. A device that appears in the probe but is flagged as not working is a stronger warning than a device that simply isn't listed.
Out-of-the-box versus "works with extra steps"
Sort what you find into three buckets before deciding:
- Works out of the box: Component detected, driver loaded automatically, no notes about firmware or kernel parameters. This is what you want for Wi-Fi and touchpad especially.
- Works with firmware or a newer kernel: The driver exists but needs a firmware package installed or a kernel newer than the distribution's default. Common for recent Wi-Fi and GPU parts. Acceptable if you're comfortable installing firmware or running a newer kernel.
- Needs out-of-tree drivers or kernel parameters: Vendor driver packages, DKMS modules, or boot parameters to fix suspend, backlight, or touchpad behavior. Workable, but each kernel update can break it — weigh this against how much you value low maintenance.
If a laptop's Wi-Fi falls in the third bucket, that alone is often a reason to choose a different configuration, since it affects every boot.
Confirming on the actual machine with a Live USB
Database reports are evidence, not proof for your unit. Boot a Live USB of the distribution you intend to use and check the hardware directly. The commands below read hardware state; none of them change the system.
- Boot the Live USB and connect to Wi-Fi if possible. If Wi-Fi doesn't appear, that itself is the finding.
- List PCI devices (GPU, Wi-Fi, Ethernet):
Thelspci -nnk-nnkflags show numeric vendor/device IDs and which kernel driver is in use. A device with no "Kernel driver in use" line is a red flag. - List USB devices (Bluetooth, webcam, some touchpads):
lsusb - Check the kernel log for errors and missing firmware:
Messages about missing firmware files point to the "works with extra steps" bucket.dmesg | grep -i -E "firmware|error|fail" - Test the touchpad and suspend: move the cursor, try two-finger scrolling, then suspend and resume. Suspend/resume failures are easier to catch now than after purchase.
- Check sensors and power:
If temperatures or fan readings are absent, power management support may be incomplete.sensors
Run these on the exact configuration you plan to buy — in a store if possible, or confirm the return policy before ordering.
When something isn't recognized
Troubleshoot by component type rather than reinstalling or switching distributions:
- Wi-Fi missing: confirm the chipset with
lspci -nnk, then check whether a firmware package for that vendor is available in your distribution's repositories. If the driver isn't in the kernel, the database report will usually name the out-of-tree module others used. - GPU or display issues: check whether the correct driver module is loaded, and whether the problem appears only with external monitors or after suspend.
- Touchpad not responding: verify it's detected as an I2C device; newer kernels often add support, so a kernel upgrade may resolve it.
- Suspend, fans, or battery: these usually trace back to ACPI quirks. Look for reports from owners of the same model, since fixes tend to be model-specific kernel parameters.
If a component remains unsupported after these checks, the practical decision is whether that component is essential to you. A non-working fingerprint reader is an inconvenience; a non-working Wi-Fi card changes how you use the machine every day.