Separating the Wayland compositor and window manager

Original Article ↗ Hacker News Discussion ↗

Separating window management from the Wayland compositor in projects like River is rekindling interest in flexible, customizable Linux desktops, closer in spirit to how X11 allowed pluggable window managers. Commenters weigh the architectural benefits — simpler compositors that lean on the kernel, better security, HiDPI and multi‑monitor support — against long‑standing pain points such as fragmented protocols, missing or awkward features (e.g. screenshots, remote apps, global hotkeys), and slower maturation compared with X11. Many see this new protocol layer and libraries like wlroots or Smithay as lowering the barrier to experiment with new WMs, while others remain skeptical and plan to stick with X11 or its forks unless Wayland achieves full feature parity and smoother user experience.

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.