GoKawiilSeparating the Wayland Compositor and Window Manager
Traditional Wayland compositors have a monolithic architecture that combines the compositor and window manager into a single program. This has the downside of requiring Wayland window managers to do the significant work of implementing an entire Wayland compositor as well.
The new 0.4.0 release of river, a non-monolithic Wayland compositor, breaks from this traditional architecture and splits the window manager into a separate program. There are already many window managers compatible with river.
The stable river-window-management-v1 protocol gives window managers full control over window position, keybindings, and all other window management policy while river itself provides frame-perfect rendering, good performance, and all the low-level plumbing required.
This blog post gives a high level overview of the design decisions behind this protocol. This is roughly the same information I presented in my FOSDEM 2026 Talk.
Display Server, Compositor, Window Manager
The traditional Wayland architecture combines three separate roles in the compositor process:
Display Server: Route input events from the kernel to windows and give the kernel buffers to display. Compositor: Combine all buffers from visible windows into a single buffer to be displayed by the kernel. Window Manager: Arrange windows, define keybindings, other user-facing behavior.
To understand why Wayland compositors thus far have chosen to combine these roles, it is first necessary to understand some of the fundamental problems with X11’s architecture that Wayland was designed to solve.
With the X11 protocol, the display server is a separate process from the compositor and window manager:
... continue reading