Why I Stayed on X11 for AMD Laptop Dev in 2026
I’m writing this on a 16” Acer Aspire AL15-42P with an AMD Ryzen 7 7730U (Barcelo APU, Vega 7 graphics). Kernel 7.1.3-2-cachyos. KDE Plasma 6.7.2. The display server is X11.
Not because I don’t know Wayland exists. Not because I’m “afraid of change.” Because the constraint matrix for my hardware + my workflow resolves to X11.
The Hardware Reality
AMD Barcelo (Ryzen 5000 series, Vega 7 iGPU) sits in an awkward spot:
- Old enough that the mainline kernel’s DMCUB firmware interface
regressed (kernel 7.0.12 blank screen, fixed with
amdgpu.dc=0) - New enough that
xf86-video-amdgpuon X11 works flawlessly - Wayland support exists but the AMDGPU + Mesa + KWin Wayland stack has a persistent GPU process crash on this generation (error code 1002, “GPU process isn’t usable”)
I documented the DMCUB regression here. The
same hardware that needs amdgpu.dc=0 on kernel 7.x for X11
to boot also crashes the Wayland compositor’s GPU process. Two
different code paths, same root cause: AMD’s display firmware
interface changed, and the open-source stack hasn’t fully caught up for
this generation.
The Workflow Reality
I develop. That’s it.
No gaming. No touchscreen. No HDR. No multi-monitor hotplug dance. Just a laptop display at 100% scaling (or 125% if my eyes are tired).
What I Lose on X11
| Feature | X11 | Wayland | My Impact |
|---|---|---|---|
| Fractional scaling (125%, 150%) | Blurry (bilinear upscale) | Native per-monitor | Low — I’m fine at 100% or 200% |
| Touchpad gestures | libinput only (basic) | KWin native (smooth 3-4 finger) | Low — I use keyboard shortcuts |
| Per-monitor DPI | Global only | Per-output | Zero — single monitor |
| Tear-free compositing | Compositor-dependent | Mandatory, frame-perfect | Low — KWin X11 compositor is solid |
| App isolation | None (any app sees all input) | Native (wayland-protocols) | Low — trusted apps only |
| HDR | No | Yes (KWin 6+) | Zero — SDR content only |
| VRR / adaptive sync | Limited | Full support | Zero — 60Hz panel |
What I Gain on X11
| Feature | Reality |
|---|---|
| AppImage/Electron apps work | Freebuff Desktop, Slack, Discord, VS Code — no
--ozone-platform hacks |
| No GPU process crashes | The compositor doesn’t own GPU; apps do |
| Remote X forwarding | ssh -X still works for headless boxes |
| Mature tooling | xrandr, xinput, xdotool,
wmctrl — 30 years of scripts |
| Stable ABI | NVIDIA/AMD proprietary drivers target X11 first |
| No “which protocol?” confusion | One display server, one protocol |
The Politics Layer
This isn’t just tech. The X11 vs Wayland divide maps to real human incentives:
Red Hat employs the Wayland core authors. They control GNOME, Fedora, RHEL. Wayland isn’t “community consensus” — it’s Red Hat’s platform strategy. Canonical followed after Mir failed. Valve adopted Wayland for Steam Deck because Gamescope (their compositor) needs direct GPU access without X11 overhead.
AMD’s Mesa developers prioritize where the volume is: Steam Deck = Wayland. NVIDIA protects their proprietary driver moat — they implemented EGLStreams first, dragged feet on GBM, now support Wayland reluctantly.
Distros default to Wayland because supporting two display servers doubles the bug surface. “Legacy” is a business decision, not a technical verdict.
My Decision Matrix
When I’ll Switch
I’ll move to Wayland when one of these flips:
- AMDGPU + Mesa + KWin Wayland stops crashing on Barcelo (error 1002 fixed upstream)
- AppImage/Electron apps create windows natively on
Wayland without
--ozone-platform=waylandhacks - I get a HiDPI external monitor (150% scaling needed)
- Touchpad gestures become essential to my workflow
Until then, X11 on KDE Plasma is the boring, stable choice. The display server should be invisible. On my hardware, Wayland makes itself visible — crashes, missing windows, broken AppImages. X11 stays invisible.
Hardware: AMD Ryzen 7 7730U (Barcelo, 1002:15e7), 16GB DDR5, 1TB NVMe. CachyOS April 2026. linux-cachyos 7.1.3-2. KDE Plasma 6.7.2. Mesa 24.1.4. X11 session (KWin_X11).