The claim circulating on Hacker News that Wayland set the Linux desktop back by ten years lands differently depending on when you switched. If you tried to use Wayland as your daily driver in 2017, screen sharing was broken, NVIDIA was largely unusable, input methods for CJK languages were unreliable, and dozens of tools you’d taken for granted quietly stopped working. From that vantage point, the complaint makes complete sense.
But the argument needs more precision. Wayland the protocol is not what caused those regressions. The cause was a combination of deliberate security tradeoffs, a fragmented ecosystem of compositor extensions, and the sheer mass of software that had built itself on top of X11’s permissive-to-a-fault model.
What X11 Actually Was
X11 is old in a way that’s easy to underestimate. The X Window System dates to 1984 at MIT, with the X11 protocol spec arriving in 1987. The current release, X11R7.7, was published in 2012 and has had only maintenance work since. The code inside X.Org Server carries decisions made when workstations shared physical hardware between users and “security” mostly meant file permissions.
The critical problem with X11’s architecture is that it has no isolation between clients. Any X11 application running in your session can, without any special permissions, record every keystroke you type into any other application, take screenshots of any window on screen, and inject synthetic input events into other programs. This isn’t a theoretical attack surface. Keyloggers, screenshot tools, and accessibility frameworks all rely on exactly these capabilities. The difference between a legitimate accessibility tool and malware is entirely policy, enforced nowhere in the protocol itself.
The X.Org security model page acknowledges this directly: X11 was designed for a cooperative, trusted environment. The modern desktop, where you run code from npm packages, browser extensions, and Flatpak bundles of uncertain provenance, is not that environment.
What Wayland Was Trying to Fix
Kristian Høgsberg started Wayland in 2008 while working at Red Hat, with Wayland 1.0 releasing in 2012. The core design decision was to give the compositor full control over what clients can see and do. In Wayland, one application cannot read the input events of another. It cannot take a screenshot without the compositor’s involvement. It cannot inject keystrokes. The compositor is the sole arbiter of what gets rendered where and what input goes where.
This was the right call. It is genuinely better to run untrusted code in a Wayland session than in an X11 session, in measurable, concrete ways. But the cost of that correctness was that every piece of software that had relied on X11’s promiscuous model needed a replacement path, and many of those replacement paths took years to arrive.
Where the Years Actually Went
The most visible regression for most users was screen sharing. Zoom, Google Meet, Discord, OBS — anything that needed to capture your screen or a specific window — broke on Wayland because the old approach of just reading pixels from the X server no longer worked. The replacement was xdg-desktop-portal, a D-Bus interface that proxies requests through the compositor, combined with PipeWire for the actual video stream transport.
PipeWire’s initial commit was in 2015. Fedora 34, released in April 2021, was the first major distribution to ship PipeWire as the default audio system, finally putting the screen sharing infrastructure in place at the OS level. That is six years from “protocol exists” to “broadly functional in a stock distro install.” During those six years, every user who tried to use Wayland and hit a broken screen share was a real user with a real regression.
NVIDIA was its own saga. NVIDIA’s proprietary driver relied on interfaces that Wayland compositors didn’t expose, and NVIDIA resisted adopting the GBM (Generic Buffer Management) interface that the rest of the ecosystem had standardized on. Usable NVIDIA support on Wayland required explicit sync protocol extensions that didn’t land in mainline compositors until 2024. For years, NVIDIA users on Wayland dealt with flickering, crashes, or simply couldn’t use it at all.
Global keyboard shortcuts were another casualty. In X11, any application could register a global hotkey by grabbing a key at the X server level. Wayland’s security model makes this impossible without compositor cooperation. The ext-idle-notify and ext-session-lock protocols eventually got standardized, but per-application global shortcuts are still handled through compositor-specific mechanisms or the relatively new xdg-toplevel-shortcuts proposal.
The Fragmentation Problem
The sharpest criticism of the Wayland transition isn’t about the security model. It’s about the protocol extension ecosystem. Wayland’s core protocol is deliberately minimal. Anything beyond basic window rendering, including window management hints, system tray integration, screen locking, output configuration, and tablet input, lives in protocol extensions.
The problem is that extensions come in two categories: stable extensions in wayland-protocols, and unstable compositor-specific ones. GNOME has protocols that only work under Mutter. KDE has plasma-wayland-protocols that only work under KWin. The wlroots ecosystem, which powers Sway, Hyprland, and a long list of tiling compositors, has its own wlr-protocols set.
An application that needs to, say, present itself in a system tray cannot write one code path that works everywhere. It needs to know which compositor family it’s running under and speak that compositor’s dialect. For years the primary answer was “use XWayland,” the X11 compatibility layer that runs an X server inside a Wayland session. XWayland meant all the old tools kept working, but it also meant that the security properties Wayland was supposed to provide were quietly bypassed for a huge fraction of running applications.
The wlr-foreign-toplevel-management protocol, which lets taskbars and docks see what windows are open, existed only in wlroots compositors for years. GNOME had a different mechanism. KDE had its own. Taskbar developers had to write three implementations or pick one ecosystem and drop the others.
Where Things Stand
KDE Plasma 6, released in February 2024, defaulted to Wayland for the first time. This was meaningful because KDE’s Wayland session has historically been more complete than GNOME’s, given KDE’s willingness to implement compositor-specific protocols quickly. GNOME had defaulted to Wayland since Fedora 25 in 2016, but many features required falling back to XWayland or were simply missing.
As of 2025, the Wayland story is genuinely much better. PipeWire handles screen capture properly. Explicit sync resolved most NVIDIA rendering issues. Fractional scaling, which was unreliable for years, works correctly on both GNOME and KDE. HiDPI handling is more consistent than it ever was on X11. The tools that broke have mostly been rewritten or updated.
X.Org Server itself was declared feature-frozen by its maintainers, with the project in pure maintenance mode. There is no path forward on X11. The security problems cannot be fixed without breaking the protocol’s guarantees to existing software. Anyone who wants to see the Linux desktop move forward was always going to have to go through this transition.
The Honest Assessment
The ten years framing is defensible as a measure of user-facing regression duration. From roughly 2012, when Wayland 1.0 shipped and people started trying to use it, to roughly 2022, when Ubuntu 22.04 LTS could default to Wayland for most users without major daily-driver pain points, is close to a decade of “this is technically the future but it’s not ready.” That’s a long time to tell users to wait.
But the alternative was not “keep X11 and add features.” The alternative was watching the gap between X11’s security model and the modern threat environment grow wider every year, while the X.Org codebase became increasingly difficult to maintain. The X.Org Server CVE history is a reliable source of motivation for why this transition was necessary.
The real failure was not choosing Wayland. It was the decade-long inability to agree on stable, cross-compositor protocol extensions for basic desktop functionality. If the compositor ecosystem had standardized on common protocols for taskbars, system trays, screenshots, and global shortcuts five years earlier, most of the pain points would have been resolved before the major distributions defaulted to Wayland. The protocol got the hard security decisions right. The ecosystem failed to build the shared infrastructure around it fast enough.
Users who lost ten years of working tools deserved better coordination from the people building the ecosystem. That criticism stands. The conclusion that Wayland itself was the mistake does not.