A recent post on omar.yt argues that Wayland set the Linux desktop back by ten years, and the Hacker News thread it spawned has nearly 400 comments of people vigorously agreeing or disagreeing. Both camps have a point. The architecture of Wayland is sound. The transition has been genuinely painful for real users with real workflows. Those two things are not in contradiction.
What X11 Actually Gave You
The X Window System was designed at MIT in 1984 and the X11 protocol specification dates to 1987. That heritage matters because X11 was built around a specific mental model: the display server is a networked service, and any authorized client can connect to it and interact with the shared display space.
This model was the source of X11’s flexibility and its problems simultaneously. On the flexibility side: ssh -X application forwarded a GUI app from a remote machine over the network, rendering it on your local display, and this worked out of the box on any X11 system for decades. Tools like xdotool could send synthetic input events to any window. Screen recording software could capture any application’s output without that application doing anything special. The EWMH specification (Extended Window Manager Hints) gave all window managers a common vocabulary for taskbars, workspace switching, and window management, so a panel written for Openbox worked with GNOME’s window manager and KDE’s equally well.
On the problems side: any X11 client connected to your display could read keystrokes from every other application, capture screenshots of every window, and inject input events without your knowledge. This was not theoretical. Keylogger tools exploited this routinely. Running a browser and a terminal emulator on the same X display was a genuine security boundary violation waiting to happen.
The Wayland Proposition
Kristian Høgsberg started Wayland in 2008 while working at Red Hat. The core idea was to eliminate the X server as a separate process and make the compositor the display server. Each application gets its own GPU buffer. The compositor decides what to display and composites everything. No application can see another application’s pixels without the compositor explicitly mediating that access.
Wayland 1.0 shipped in October 2012. The architectural decisions were defensible: direct rendering through DMA-BUF buffer sharing eliminated the copy overhead of X11’s rendering path. Compositor sovereignty over input and display gave a proper security boundary. Better multi-monitor handling with per-output refresh rates became possible. HiDPI support was designed in rather than retrofitted.
The problem is that Wayland 1.0 was a protocol core, not a complete desktop platform. Almost everything that users relied on in X11, beyond basic window drawing, had to be reimplemented as Wayland protocol extensions. And those extensions took years to arrive, standardize, and get adopted.
The Feature Regression Catalog
Screen capture is the most visible example. In X11, any application could capture any window or the entire screen. In Wayland, this requires the compositor to explicitly implement a capture protocol. The wlroots-based compositor ecosystem shipped wlr-screencopy, a wlroots-specific unstable protocol. KDE had its own D-Bus interface. GNOME had a different interface. OBS Studio, the dominant screen recording tool, had no working Wayland support until version 28.0 in September 2022, ten years after Wayland 1.0. The unified answer, PipeWire combined with xdg-desktop-portal, works well now, but PipeWire 0.3 only reached production stability around 2020-2021.
Global keyboard shortcuts presented a similar gap. Applications that need to respond to a hotkey regardless of focus, like a push-to-talk key in a voice chat client or a clipboard manager trigger, had no standard mechanism in Wayland. The GlobalShortcuts interface in xdg-desktop-portal version 1.6 addressed this, but that landed in 2023. Between 2012 and 2023, the answer was effectively “use your compositor’s specific mechanism, if it has one.”
Color management and HDR took even longer. KDE shipped frog-color-management-v1 as a compositor-specific protocol in Plasma 5. The xx-color-management-v4 protocol, which attempts to standardize this at the Wayland protocol layer, only merged into wayland-protocols in 2024. HDR support on Linux via Wayland became usable in KDE Plasma 6.0 (February 2024).
Fractional scaling had its own multi-year saga. wp-fractional-scale-v1 was added to wayland-protocols in 2022. Before that, HiDPI displays either got integer scaling (sharp but oversized) or applications ran through XWayland where they appeared blurry because XWayland applies fractional scaling by rendering at integer scale and letting the compositor scale the result down.
X11 forwarding via SSH never got a Wayland equivalent. XWayland provides X11 compatibility but it is a shim: you run a full X11 server as a Wayland client on your local machine. Forwarding a Wayland-native app over SSH to a remote display is architecturally difficult and has no standard solution. Users who relied on ssh -X for remote administration or development workflows either stayed on X11 or adapted to alternatives like VNC or RDP tunneling.
The Fragmentation Problem Nobody Talks About Enough
The single deepest structural failure of the Wayland transition is protocol fragmentation. X11 had one server implementation (Xorg) and one protocol. The EWMH hints that governed window management metadata were universally implemented because all window managers spoke the same underlying protocol.
Wayland has a minimal core protocol and an ecosystem of extensions. The extensions that matter most to application developers, covering things like taskbar integration, desktop notifications, window thumbnails, and application identity, have been implemented differently by every major compositor. KDE’s kde-plasma-window-management protocol is not the same as GNOME’s D-Bus window management interface, which is not the same as the wlr-foreign-toplevel-management-unstable-v1 protocol used by wlroots compositors like Sway and Hyprland.
This puts application developers and tooling authors in an awkward position. A taskbar widget, a window switcher, or an accessibility tool that wants to enumerate and manage windows needs separate code paths for GNOME, KDE, and wlroots. The problem is not a lack of smart people working on it; the wlr-foreign-toplevel-management protocol was a wlroots community effort to fill this gap. The problem is structural: when the compositor owns everything, compositor vendors have strong incentives to ship their own protocols quickly rather than wait for slow standardization processes.
Where Things Stand in 2026
The picture is materially better than it was in 2020. PipeWire + xdg-desktop-portal provides a working screen capture story across desktop environments. KDE Plasma 6 ships Wayland by default and HDR support has arrived. GNOME has been Wayland-first for several years. The ext-portal family of protocols is steadily addressing gaps.
XWayland remains the main friction surface. Applications that have not been ported to native Wayland, including a substantial portion of Electron-based apps, older Qt applications, and various developer tools, run under XWayland where clipboard edge cases, scaling artifacts, and input handling differences still surface. The blurry XWayland app on an HiDPI display is less common in 2026 than it was in 2021, but it has not entirely gone away.
The Honest Assessment
The omar.yt article’s framing is polemical, but it points at something real. The Linux desktop did not regress uniformly for ten years. It went forward on some axes, security, graphics performance, HiDPI handling, and sideways or backward on others, remote access, automation, accessibility, screen recording, for much of the transition period.
The architectural decisions in Wayland were correct. X11’s security model was genuinely broken and could not have been fixed incrementally without effectively replacing the protocol. The compositor-owns-rendering model enables better graphics primitives than X11’s aging rendering infrastructure ever could.
The mistake was sequencing. The GNOME developers who pushed Wayland to default in Fedora 25 in 2016 did so before PipeWire existed, before global shortcut portals existed, before color management was standardized, and before fractional scaling was settled. The argument was that defaulting to Wayland would accelerate the ecosystem. That is probably true. It is also true that users with specific needs, streaming, remote work, accessibility, automation, paid the bill for that acceleration with years of broken workflows.
The lesson from Wayland is not that clean-slate redesigns are wrong. It is that when you deprecate infrastructure that millions of people depend on, the replacement needs to meet the old system’s feature baseline at the moment of the switch, not promise to catch up afterward. Wayland did not do that, and the friction has been real and measurable. That the destination is worth reaching does not change the cost of how the journey was managed.