The Linux desktop debate has a recurring focal point: Wayland. Every few months, a post surfaces arguing that Wayland’s architects made a category error, treating a display protocol redesign as an opportunity to enforce security boundaries that the existing ecosystem was never built to accommodate. The latest iteration of this argument, which landed on Hacker News with nearly 300 points and 380 comments, is worth taking seriously because the specific architectural decisions that produced these regressions were intentional, not accidental.
What X11 Actually Enabled
X11’s design, which dates to 1987, was built around a fundamentally different set of assumptions. The system was network-transparent, meaning a client could connect to a display server running on another machine. It was permissive by default: any application could read the input events of any other application, take screenshots of arbitrary windows, and synthesize keystrokes into other applications’ windows.
That permissiveness was what made the X11 ecosystem so productive for power users and automation. Tools like xdotool could automate GUI applications by synthesizing mouse clicks and keystrokes. scrot and import from ImageMagick could capture any window on the screen without special permissions. xbindkeys provided global hotkeys that worked regardless of which application had focus. xclip and xsel made clipboard manipulation scriptable from the terminal. Remote desktop via VNC worked because VNC servers could hook directly into X11’s drawing model.
The entire ecosystem of screenshot tools, screen recorders, clipboard managers, color pickers, custom window managers, and automation scripts was built on the assumption that the display system was a shared, inspectable resource. Developers wrote tools against that assumption for three decades.
Wayland’s Isolation Model
Wayland, which began development in 2008 under Kristian Høgsberg at Red Hat, started from the premise that X11’s permissiveness was a genuine security problem. Under X11, a malicious application can log every keystroke typed anywhere on the system, including in password fields in other applications. It can take screenshots without user notification. It can inject input events into other applications. These are real and documented vulnerabilities; keyloggers on Linux exploited exactly these properties for years.
The Wayland security model addresses this by making clients completely isolated from each other. A Wayland client can only see its own windows. It cannot read input events from other clients. It cannot capture the screen without going through a privileged compositor-mediated interface. The architecture is clean: the compositor is the only trusted entity, and clients communicate with it rather than with each other or with a shared global server.
This design was deliberate and defensible from a security standpoint. It also made an enormous number of existing tools stop working, and that consequence was understood by the designers from the beginning.
The Specific Regressions
The list of broken features in early Wayland spans years of bug reports and user complaints across every major distribution.
Global hotkeys stopped working for applications that were not the active window. Tools like xbindkeys had no equivalent for years. KDE and GNOME eventually implemented separate portal interfaces for this, but they required applications to be explicitly ported and compositors to implement the specific protocol extension. For users who had configured media key bindings or push-to-talk shortcuts through independent tools, this was a flat regression with no workaround.
Screen capture was completely broken until PipeWire and the xdg-desktop-portal infrastructure were developed and integrated. This took several years to reach a state where video conferencing applications like Zoom could share a window at all. The initial implementations only worked in specific desktop environments. Firefox and Chrome did not support Wayland screen sharing properly until 2021 and 2022 respectively, meaning years passed between Wayland becoming a default session and basic screen sharing working in a browser.
Clipboard management between X11 applications running under XWayland and native Wayland applications was unreliable for an extended period. X11 has a selection model with PRIMARY (middle-click paste) and CLIPBOARD (ctrl+v paste) selections. Bridging this correctly across the XWayland boundary required the compositor to run a clipboard synchronizer, and bugs in this area persisted across multiple release cycles. Users who relied on middle-click paste from terminal selections found it silently broken depending on which applications were involved.
Input method editors for CJK languages were broken under Wayland for years. The text-input-v3 protocol is still not uniformly supported across compositors, which matters directly for users typing Japanese, Chinese, or Korean. This is not a power-user edge case; it affects hundreds of millions of potential Linux users and remained a serious gap well into the 2020s.
Remote desktop and VNC effectively required staying on an X11 session for anyone who depended on these workflows. GNOME Remote Desktop gained proper Wayland support around 2022; third-party tools like x11vnc simply do not have Wayland equivalents with comparable feature coverage. Organizations that used Linux VDI or remote access workflows had no migration path.
Color management and ICC profiles were missing from the core Wayland protocol for a long time. The wp-color-management protocol was only merged in 2024, meaning photographers and designers working with color-critical applications had to stay on X11 or accept compositor-specific workarounds that did not transfer between environments.
The Protocol Fragmentation Problem
One of the less-discussed costs of Wayland’s design is the protocol fragmentation it introduced. X11 was a monolithic protocol with a known feature set. Applications could depend on it unconditionally. Wayland is a minimal core protocol with compositors implementing extensions, and those extensions are not guaranteed to exist across compositors.
This means that an application targeting Wayland cannot know at runtime whether the compositor supports screen capture, global shortcuts, foreign toplevel management, or any number of other features. The wayland-protocols repository tracks the standardization effort, but protocol development and ratification has been slow, and compositors frequently ship their own unstable extensions that applications end up depending on in practice.
Compositors like sway via wlroots, GNOME’s Mutter, and KDE’s KWin each implemented different subsets of extensions at different points in time. A tool written targeting sway-specific protocols might not work under GNOME. A GNOME-specific extension would not be available under KDE or any tiling compositor. X11, for all its design problems, had a single reference implementation with a single feature set. The Wayland ecosystem has multiple compositors that are each partially compatible with each other, and users have to discover which features are available in their specific compositor through trial and error.
This also shifted implementation burden from a dedicated shared display server into every compositor independently. When a new protocol gets standardized, every compositor has to implement it separately. Features arrive at different times in different environments, and users experience different gaps depending on their desktop environment. The dream of a simpler protocol produced a more fragmented ecosystem.
Was the Migration Managed Well
Some of these regressions were structurally unavoidable given Wayland’s design goals, and some were not.
The isolation model is not separable from the core architecture. If you want a client to be unable to capture another client’s window, then tools that depend on capturing arbitrary windows will break. That follows from the design by necessity. You cannot have both X11-style permissive access and Wayland-style client isolation; they are mutually exclusive.
What was more avoidable was the pace of the transition. For years, the standard response to any broken feature under Wayland was to use XWayland, the compatibility layer that runs X11 applications by embedding a nested X11 server inside the Wayland compositor. XWayland mostly works for basic cases, but it does not support Wayland-native features like per-monitor fractional scaling and HDR, it adds complexity to the compositor stack, and it is a maintenance burden that the ecosystem has been trying to reduce. Telling users to fall back to a compatibility layer is not a migration strategy; it is deferral.
The PipeWire screen capture infrastructure, the xdg-desktop-portal portals, the xdg-foreign protocol for embedding foreign windows, and the foreign-toplevel management protocol all needed to exist before Wayland was a viable replacement for X11 in most non-trivial workflows. Several distributions, particularly Fedora starting with version 25 in 2016, moved to Wayland as the default session before this infrastructure was in place. That put ordinary users in the position of filing bug reports and discovering workarounds in their daily workflow, which is not how default sessions are supposed to work.
Where the Ecosystem Stands
The situation in 2025 and 2026 is substantially better than it was in 2016. PipeWire has become the standard audio and video pipeline on major distributions and handles screen capture well. KDE Plasma and GNOME both have functional Wayland sessions for the majority of workloads. Fractional scaling works across most hardware configurations. Screen sharing in video calls generally works. Gaming through Steam has improved significantly due to sustained work on Wayland input handling and the xdg-activation protocol.
What remains is a tail of missing features and niche workflows. Accessibility tools still have coverage gaps. The automation ecosystem built on xdotool and friends has no clean Wayland equivalent with the same cross-compositor portability. Some workflows that X11 enabled with simple command-line tools now require either compositor-specific solutions or staying on X11.
The honest assessment is this: Wayland set the Linux desktop back in the sense that features which worked for decades stopped working, and the replacement infrastructure took another decade to partially reconstitute them. The security model and the cleaner protocol design are genuine improvements. Whether the cost was worth it depends on what you value in a desktop system. For developers building sandboxed application distribution or systems where client isolation matters, Wayland’s foundation is clearly better. For the user with years of shell scripts built on xdotool and scrot, the last ten years have been a sustained regression that is only now approaching recovery.
Both of those things are true at the same time, and the debate rarely acknowledges both sides with equal seriousness.