In 2008, a Red Hat engineer named Kristian Høgsberg began writing code that would eventually ignite one of the longest and most bitter technical debates in open-source history. The project was called Wayland, and its mission sounded reasonable enough: replace the aging X Window System — the display server protocol that had powered Unix and Linux graphical interfaces since 1984 — with something modern, secure, and architecturally sound.
Sixteen years later, the transition remains incomplete, contentious, and, according to a growing chorus of developers and power users, actively harmful to the Linux desktop.
The Case Against X11 — And Why Wayland Was Supposed to Fix Everything
The X Window System, commonly referred to as X11 or simply X, is old by any standard. It predates the World Wide Web. It was designed for an era of networked terminals, where a thin client might display an application running on a remote mainframe. That network-transparent architecture — the ability to run a program on one machine and display it on another — was a defining feature, not a bug.
But X11 accumulated decades of technical debt. Its security model was essentially nonexistent: any application could snoop on keyboard input from any other application. Screen capture and input injection required no special permissions. The compositing model was bolted on after the fact through extensions like XComposite, and the result was a patchwork of protocols, hacks, and workarounds that compositor developers had to wrestle with constantly.
Wayland’s pitch was clean. Strip away the cruft. Build a protocol where the compositor is the display server. Give each application its own buffer, eliminate the ability for apps to spy on each other, and let the compositor handle all the rendering directly. No more decades-old extension baggage. No more security holes wide enough to drive a truck through.
On paper, it was compelling. In practice, it broke nearly everything.
Omar Rizwan, an independent developer and researcher, published a detailed technical critique on his blog titled “Wayland set the Linux desktop back by 10 years” that catalyzed renewed debate across the Linux community. His argument is not that Wayland’s goals were wrong, but that the project’s ideological rigidity — its refusal to provide certain capabilities that X11 offered — has resulted in a net loss for Linux desktop users and developers. As Rizwan wrote: the Wayland project “Democrats-falling-in-line’d the Linux desktop into mass-adopting a platform with huge gaps.”
The gaps he identifies are not obscure edge cases. They are fundamental capabilities that professional users and developers rely on daily.
Global hotkeys. Gone, or at best inconsistently implemented through compositor-specific portals. Under X11, any application could register a keyboard shortcut that worked regardless of which window had focus. Wayland’s security model forbids this by design because it would require one application to intercept input destined for another. The result: tools like push-to-talk in Discord, clipboard managers, and automation utilities either don’t work or require fragile workarounds specific to each compositor.
Window positioning. Gone. Under X11, an application could request to be placed at specific screen coordinates. Wayland considers this a compositor concern, not an application concern. So test automation frameworks that need to position windows predictably — broken. Tiling window manager workflows that relied on applications self-positioning — broken. The Wayland developers’ response, per Rizwan’s account, has consistently been that applications shouldn’t need to do this. But they do.
Screen capture and recording. Severely restricted. The same security model that prevents keystroke snooping also prevents legitimate screen recording and sharing without going through an XDG Desktop Portal, which requires user interaction and compositor support. This broke OBS Studio workflows, remote desktop tools, and accessibility software that needed to read screen contents programmatically.
Color management, HDR support, and advanced display features were either missing or arrived years late. Network transparency — X11’s original killer feature — was simply abandoned. The Wayland developers’ position was that VNC or RDP-style solutions could fill the gap. For many sysadmins and remote users, they don’t.
Rizwan’s critique extends beyond missing features to the culture of the project itself. He describes a pattern where users and developers reporting broken workflows were told their use cases were invalid, or that they should file requests with the XDG Desktop Portal project, or that their compositor of choice should implement a proprietary extension. The effect was to shift blame away from the protocol and onto everyone else.
“The Wayland community will mass-close issues on their issue tracker and mass-close merge requests,” Rizwan observed. He compared the dynamic to a political movement that demands loyalty while delivering incomplete results.
The Fragmentation Problem
Perhaps the most damaging consequence of Wayland’s architecture is fragmentation. Under X11, there was one display server protocol. Applications written to the X protocol worked with any window manager or desktop environment. That’s no longer true.
Wayland is a protocol, but it’s a minimal one. Many capabilities that applications need — screen capture, global shortcuts, clipboard management, window positioning — are not part of the core protocol. They’re handled by extensions, and different compositors implement different extensions. GNOME’s Mutter compositor supports certain features. KDE’s KWin supports others. Sway, Hyprland, and the dozens of other Wayland compositors each make their own choices.
For application developers, this means targeting “Wayland” isn’t sufficient. You need to know which compositor your user is running. And you may need to implement multiple code paths. Or just give up and tell users to use X11 through XWayland, the compatibility layer that runs X11 applications inside a Wayland session.
XWayland itself is a telling admission. Years into the Wayland transition, a huge number of applications — including many professional tools, games, and legacy software — still run through XWayland rather than natively. The compatibility layer works, mostly, but it reintroduces many of the performance and security characteristics that Wayland was supposed to eliminate.
The XDG Desktop Portal system was created to address some of these gaps by providing a standardized way for sandboxed applications to request capabilities like screen recording or file access through a user-mediated dialog. But portals are unevenly implemented across compositors, they add latency and complexity, and they fundamentally change the programming model. An automation tool that could previously capture a screen region in a single function call now needs to invoke a D-Bus service, handle an asynchronous user permission dialog, and deal with compositor-specific behavior differences.
Rizwan’s blog post resonated because it articulated frustrations that had been simmering for years in developer communities. Discussions on Hacker News, Reddit’s r/linux, and X (formerly Twitter) have consistently featured complaints about Wayland regressions. But the major distributions kept pushing forward anyway.
Ubuntu switched its default session to Wayland in 2021 (after an earlier attempt in 2017 that was rolled back). Fedora made the switch even earlier. GNOME and KDE both declared Wayland their primary target. The X.Org server, meanwhile, has effectively entered maintenance mode — its last major release was in 2021, and active development has largely ceased.
This creates a ratchet effect. As X.Org development stalls, bugs go unfixed, drivers stop being optimized for it, and the argument for switching to Wayland becomes self-fulfilling. The old system is deteriorating — but it’s deteriorating in part because resources were redirected to its replacement before that replacement was ready.
Not everyone agrees with the critics. Wayland’s defenders — and there are many, including most of the core GNOME and KDE developers — argue that the transition pain is real but temporary, and that the security and architectural benefits are worth it. They point to genuine improvements: better handling of mixed-DPI displays, smoother frame pacing, elimination of screen tearing without hacks, and a security model that’s appropriate for a modern desktop where applications shouldn’t be able to keylog each other.
They also argue that many of the “missing features” are being addressed through ongoing protocol extensions. The ext-global-shortcuts protocol, for instance, is working its way through the standardization process. Color management and HDR protocols are in development. The situation is improving.
But “improving” after 16 years of development is itself part of the critique. X11 had these capabilities — imperfect, insecure, but functional — in the 1990s.
Recent discussions on social media and developer forums suggest the debate is far from settled. On X, developers have shared Rizwan’s post widely, with reactions splitting predictably along ideological lines. Those who prioritize security and architectural purity tend to support Wayland’s approach. Those who prioritize practical functionality and backward compatibility tend to side with the critics.
What Comes Next
The uncomfortable truth is that the Linux desktop is now committed to Wayland whether the transition is complete or not. X.Org is dying. The major desktop environments have moved on. Going back isn’t a realistic option.
But the path forward requires something the Wayland project has historically resisted: compromise. The protocol needs to accommodate use cases that its designers consider architecturally unclean. Global hotkeys, even if they create theoretical security concerns, are a practical necessity. Window positioning, even if it violates the compositor-owns-everything model, is required by real software. Screen capture without portal dialogs is needed by professionals who record, stream, and automate.
Some of this is happening. KDE’s approach has generally been more pragmatic than GNOME’s, implementing extensions and workarounds to maintain functionality that users expect. Hyprland and other independent compositors have taken similarly practical approaches. But the lack of a single standardized protocol for these capabilities means every compositor reinvents the wheel, and application developers pay the cost.
Rizwan’s post ends with a pointed observation. He doesn’t argue that X11 was good. He argues that Wayland’s developers confused “X11 is bad” with “everything X11 does is bad,” and in their zeal to build something architecturally pure, they threw away capabilities that took decades to develop without providing replacements.
The result is a Linux desktop that is, in measurable ways, less capable than it was five years ago. Not in every dimension — Wayland is genuinely better at some things. But in enough dimensions that matter to enough people that the frustration has reached a boiling point.
And so the Linux community finds itself in a familiar position: arguing about infrastructure instead of building on it. The display server wars have consumed enormous amounts of developer time, community goodwill, and user patience. Whether Wayland eventually delivers on its promise or becomes a cautionary tale about the costs of ideological purity in systems design, the price has already been steep.
The desktop Linux market share, stubbornly hovering around 4% globally, can’t afford many more decades-long transitions that leave users worse off in the interim. But that appears to be exactly what it’s getting.
from WebProNews https://ift.tt/wCR0LZS
No comments:
Post a Comment