The Price of Wayland's Clean Slate: A Decade of Linux Desktop Regressions

The Wayland display protocol has been under active development since 2008. Its first real compositor, Weston, shipped in 2012. By 2016, Fedora was shipping GNOME on Wayland by default. Nearly two decades into the project, the Linux desktop is still mid-transition, and the frustrations that accumulated along the way have not gone away. A recent piece on omar.yt frames the damage directly: Wayland set the Linux desktop back by ten years.

That framing is worth interrogating, because the regressions it points to were real, the timeline was genuinely painful, and the causes are technical and organizational rather than accidental.

What X11 Made Trivially Possible

X11 was designed in 1984 around a cooperative client model. Every application connected to the same display server and, by default, could interact freely with every other application’s windows. That design produced capabilities the ecosystem built heavily upon.

Screen recording worked because ffmpeg -f x11grab could read the framebuffer directly. Screenshot tools could capture any window without special privileges. xdotool could synthesize input events into any running application because the X11 XTEST extension allowed it. Input method editors could intercept keystrokes globally. Accessibility frameworks could traverse the full window tree. Remote display worked because X11 had network transparency baked into the protocol from the start: running an application on a remote machine while displaying it locally was a first-class use case, handled by setting DISPLAY and letting the protocol do the rest.

All of this came at a cost. The X11 permission model imposes essentially no access control between clients. Any application in your X session can log every keystroke you type into every other window, including browser password fields. Any application can capture your screen silently. As sandboxed application packaging through Flatpak and Snap became relevant, the X11 model became increasingly incompatible with modern security requirements.

The Design Decision Wayland Made

Wayland’s protocol design addresses the X11 security problem directly. In Wayland, the compositor is the authority, and clients only interact with their own surfaces. One application cannot observe another’s windows, cannot inject input into another application, and cannot capture the screen without an explicit, user-mediated grant from the compositor.

This is the correct design for a display server that will run sandboxed applications, handle sensitive input, and coexist with modern security requirements. The choice to break X11’s cooperative model was not careless; it was the consequence of fixing a genuine architectural problem.

The problem was that fixing the security problem also removed the underlying mechanism for a large set of legitimate capabilities, and the replacements were not built in time.

The Infrastructure That Arrived Late

Wayland’s answer to “how does screen sharing work” is xdg-desktop-portal combined with PipeWire for the actual media transport. The portal model is genuinely good: the user receives a system dialog, selects what they want to share, and grants explicit permission. That is meaningfully better than X11’s silent universal access.

But xdg-desktop-portal was designed for the Flatpak sandboxing use case and was not ready for general desktop use until well after distributions had started defaulting to Wayland sessions. PipeWire’s screen capture support became stable around 2020 and 2021, roughly four to five years after GNOME had started shipping Wayland as the default. In the gap between those two dates, screen recording simply did not work reliably for many users, and the workaround was to log back into an X11 session.

Color management had a similar timeline. X11’s ICC profile support through Xrandr was imperfect but functional, and professionals doing color-critical work had stable workflows on Linux. The Wayland color management protocol specification was in development for years; functional color management for Wayland sessions arrived in GNOME and KDE only in the 2023 to 2024 timeframe, leaving a multi-year gap where accurate color reproduction ranged from broken to unreliable.

Input method editor support, critical for CJK language input, was another protracted issue. The text-input Wayland protocol exists, but compositor implementations varied in completeness and compatibility with the IBus and Fcitx input frameworks. Users who relied on IME were dealing with regressions and workarounds throughout much of the transition period, with fixes arriving piecemeal across different compositors on different schedules.

Remote desktop remains genuinely inferior to X11 to this day. X11’s network transparency required no special infrastructure. Wayland has no equivalent, and VNC or RDP solutions require compositor-side protocol support that is still not universally available or consistent.

Compositor Fragmentation

X11 had one display server. Wayland has compositors: GNOME’s Mutter, KDE’s KWin, wlroots-based compositors like Sway and Hyprland, and others. The core Wayland protocol is deliberately minimal, with extensions negotiated per-compositor.

This means that a feature present in KWin may be absent in Mutter, and vice versa. Global keyboard shortcuts support arrived in the xdg-desktop-portal specification and was then implemented by compositors at different times and with different degrees of completeness. The wlroots library did meaningful work to standardize behavior across the compositors built on it, but the overall landscape remains more fragmented than X11 ever was.

For application developers, this multiplied the testing surface. An application that uses portal APIs correctly can still behave differently across compositors because implementations diverge in subtle ways. That fragmentation has a real cost in developer time and in the kind of inconsistent behavior that erodes user confidence in a platform.

The wl-protocols and wlr-protocols collections grew as ad-hoc extensions accumulated, but the slow path from “someone implements this in one compositor” to “this is standardized and supported everywhere” means that features available in practice on X11 for a decade can exist only partially in the Wayland ecosystem.

XWayland as Permanent Infrastructure

XWayland was positioned as a compatibility bridge to ease the transition, a way to run X11 applications in a Wayland session while the ecosystem migrated. In practice, it became permanent infrastructure. Many commercial applications, games, and specialized tools remain X11-only with no Wayland port on any visible roadmap.

XWayland has real limitations. HiDPI scaling behaves inconsistently for XWayland windows compared to native Wayland clients. Screen capture of XWayland windows through portal APIs requires compositor-specific handling. With X.Org itself in maintenance mode, receiving only security patches and no new development, XWayland compatibility will not improve over time; it will drift as the surrounding Wayland infrastructure evolves away from it.

The uncomfortable implication is that a large portion of Linux desktop software will be running forever on an emulation layer of a frozen protocol inside a newer system that was designed to replace it. That is not what a clean migration looks like.

The Migration Management Problem

The Wayland protocol design, taken on its own terms, is sound. The failure was in how distributions and desktop environments handled the rollout. Users were defaulted onto Wayland sessions before the replacement infrastructure was ready, and the timeline for “this will be fixed” was too often vague.

When a user discovered that their screen recording workflow broke after upgrading, the typical response was that they should file a bug, switch back to X11, or wait for the portal infrastructure to mature. That response was technically accurate and practically useless for someone with a deadline.

The friction compounds because Wayland’s security model shifts responsibility onto compositors and portal implementations. When something does not work, it may be a compositor bug, a portal implementation gap, an application using the wrong protocol version, or a missing piece of the D-Bus session. Diagnosing the failure requires understanding a stack that is more distributed than X11’s single server, and the error messages rarely help.

The original argument is not that Wayland’s design goals were wrong. It is that the Linux desktop was measurably less capable for real users during the transition period, and that period lasted nearly a decade. Measured in working features rather than protocol cleanliness, that assessment is difficult to dispute.

Where Things Stand

By 2025 and into 2026, the situation has genuinely improved. PipeWire screen sharing works reliably on major compositors. Color management is functional for most professional workflows. The global shortcuts portal has shipped. KDE Plasma and GNOME both have mature Wayland sessions that cover the majority of daily-use workflows. The transition, while slow and painful, did eventually deliver most of what was promised.

But the transition consumed roughly a decade of developer effort and user patience. The lesson is not that clean redesigns are wrong or that backward compatibility should be treated as sacred. It is that users should not be defaulted onto incomplete infrastructure, that “this will be fixed” is not a substitute for fixing it before the switch, and that regression timelines matter as much as design correctness.

Wayland had the right technical destination. The cost of getting there was higher than it needed to be, and the people who paid that cost were the users who just wanted their Linux desktop to work.