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.
What I’m talking about is something different. My post is not about building an implementation myself, but about advocating for a direction. The idea is not to keep Xorg’s implementation or its internal abstraction layer, but to preserve the design philosophy of X itself — the distributed, protocol‑based, client/server model that enables remote graphics, composability, and implementation diversity.
A key advantage of following the X philosophy is that we don’t need to change GPU drivers, because modern Linux already has Mesa/KMS/DRM as the real driver layer. A new protocol and a lightweight, strictly‑scoped abstraction layer could sit above that, combining X’s distributed design with modern techniques from Mesa, without inheriting X11’s legacy complexity. This layer would not implement any concrete rendering or window system logic — only provide the minimal interface needed for distributed graphics and multiple implementations to coexist.
This avoids the “Android-style” direction where the graphics stack becomes local-only and loses distributed capabilities. Instead, it keeps the door open for a healthier, multi‑implementation ecosystem.
(English is not my native language, so this reply is translated with AI.)
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.
It turns out it's actually much better to just write in your own words and in your own voice, even if it's full of mistakes. We want to hear you, not a generated or filtered version of you.
Other explanations here in case helpful: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...