This is not nostalgia. These capabilities matter for remote work, automation, multi‑machine workflows, thin clients, cloud desktops, and future distributed systems. They are not “legacy features”; they are architectural strengths that may become important again.
The problem is not Wayland itself, but the fact that it was never designed to support these use cases. Its philosophy is intentionally local, single‑user, and compositor‑centric. That is perfectly valid for mobile devices, but it leaves a gap for desktop and distributed environments.
Xorg, on the other hand, suffers from an aging implementation, not an outdated philosophy. Its core ideas—protocol‑based rendering, remote execution, composability, and transport independence—remain relevant. What we lack is a modern, minimal, protocol‑only successor that preserves these strengths without carrying Xorg’s historical baggage.
Such a project would not need to replicate Xorg’s entire feature set. It would not need server‑side rendering, fonts, input methods, window management, or security policy. It would simply define a clean, modern protocol and a stable abstraction layer. Existing compositors could implement it. Existing drivers would not need to change. Mesa would not need major redesign. The engineering effort is far smaller than rewriting a full graphics stack.
This is not a call to replace Wayland. It is a call to acknowledge that the Linux desktop may need more than one graphics model. A protocol‑first, implementation‑agnostic layer could coexist with Wayland, complement it, and preserve capabilities that would otherwise disappear.
If no one starts this work, the industry will naturally converge on mobile‑style graphics architectures, and the distributed capabilities of the past may be forgotten for a long time. But if someone begins a modern protocol‑only successor to Xorg, the community may finally have a path that balances simplicity with the flexibility the desktop once had—and may need again.
bigyabai•1h ago
powerwordtree•1h ago
I’m not advocating copying Wayland or rejecting a greenfield implementation. My point was simply that a protocol‑first approach deserves to be part of the discussion, especially for use cases that Wayland intentionally doesn’t target.