Separating the Wayland compositor and window manager

Original Article ↗ Hacker News Discussion ↗

Wayland architecture and kernel role

  • Several comments clarify that modern Wayland compositors rely heavily on kernel DRM/GPU facilities; apps draw into kernel-backed buffers which the compositor composites.
  • Compared to historical X11, commenters argue the kernel now does much of what X drivers used to, simplifying display servers.
  • Some note that hardware planes can bypass the compositor for lower latency.
  • There is debate over how “different” modern X (using DRM) really is from this model.

Separating compositor and window manager (River focus)

  • Many see River’s window-management protocol as an important step: lowering the barrier to writing WMs without re‑implementing a compositor.
  • Enthusiasts like the idea of composing desktops from multiple cooperating processes and extension APIs (e.g., Lua, Emacs modules).
  • Skeptics argue extension boundaries are hard to get right and can become leaky, especially with Wayland’s evolving, underspecified ecosystem.
  • Some warn that different compositors may expose incompatible WM APIs, so separation doesn’t automatically mean interchangeability.

X11 vs Wayland: flexibility, security, and features

  • X11 is praised for: pluggable WMs, easy remote window forwarding (ssh -X), global input events, knowing window position, niche workflows (synth control via pointer position, EXWM, tray icons, shading).
  • Wayland is praised for: better HiDPI and per-monitor scaling, no tearing, easier VRR/HDR, stricter security (no unrestricted keylogging/screen capture, permissioned screenshots via portals).
  • Critics argue Wayland’s security model makes some workflows and debugging harder; proponents counter that unfocused-input and global shortcuts must be mediated by the compositor.

Usability and maturity concerns

  • Some report years of smooth Wayland use (especially KDE, GNOME, Niri, Sway), while others hit persistent issues: clipboard flakiness, inconsistent screenshot APIs, remote access immaturity, missing window shading, and broken legacy tools.
  • There’s frustration that, after ~17–18 years, Wayland is only now approaching “works out of the box” and feature parity with X11 for many workflows.

Ecosystem, politics, and future directions

  • Several comments criticize perceived “my way or the highway” attitudes around client-side decorations, trays, and standards, especially in major DEs.
  • Others point out that anyone can build alternatives (wlroots, Smithay, River, Niri), and that market reality is moving most desktops to Wayland.
  • Some foresee “reinventing X11 one feature at a time”; others argue the real constraints are social/political, not technical.