River Is Doing What Everyone Said Was Impossible On Wayland

High-level summary

• River 0.4.0 introduces a non‑monolithic Wayland architecture by splitting the Wayland compositor (the low‑level display/input/render plumbing) from the window manager (WM) into separate programs using the River Window Management V1 protocol.
• The split lets WM authors focus on policy (tiling/floating layouts, keybindings, focus rules, server‑side decorations) while River handles frame‑perfect rendering, input routing, buffer synchronization, and other latency‑sensitive work.

Why this matters (technical context)

• X11 (Xorg) historically exposed high‑level services that made writing small WMs easy, but its design (remote display assumptions and many round trips) is outdated.
• Wayland removed X11’s middleman and combined display server + compositor to avoid X11’s input/latency issues — however, most Wayland compositors also included WM logic. That forced WM authors to implement low‑level compositor features (often using libraries like wlroots, Smithay, or Mir).
• River’s split preserves Wayland’s latency and “frame perfection” goals: there is no extra round trip or added input latency compared to a traditional monolithic Wayland compositor, and the compositor waits for window buffers so tiled/staged layout changes don’t show gaps or tearing.

Key protocol and architecture details

• State separation

  • Window‑management state: affects compositor↔client communications (sizes, fullscreen, keyboard focus, keybindings).
  • Rendering state: only affects compositor output (positions, stacking order, cropping, decorations).

• State machine model

  • The compositor initiates manage/render sequences.
  • The WM is only woken when window‑management state changes (for example: a new window or a WM keybinding).
  • If nothing changes, no round trip to the WM is required — maintaining low latency for typed input and games.

• Frame perfection

  • The compositor waits for all affected clients to submit buffers at requested sizes before presenting, preventing visual gaps in tiled layouts (subject to client responsiveness).

• Extensibility

  • The protocol is intentionally focused on 2D desktop WMs but is designed to be extensible via protocol additions if needed.

Practical benefits for developers and users

• Low barrier to entry: the project claims a few hundred lines of code can implement a usable WM (not just experimental).
• Language choice: WMs can be written in higher‑level or garbage‑collected languages without impacting compositor frame deadlines, since the compositor handles latency‑sensitive work.
• Robustness and development experience: a crashed WM does not kill the whole Wayland session; WMs can be restarted or swapped, improving debugging and iteration.
• Diversity: the approach encourages a variety of WMs on Wayland similar to the ecosystem under X11 (i3, dwm, awesome, bspwm, etc.).

Limitations and scope

• Not intended for non‑traditional 3D/VR use cases or complex visual gimmicks (for example, VR compositor integrations or advanced effects like “wobbly windows”).
• Simple animations are supported, but advanced custom shaders or richer rendering control are not a priority right now and would require further protocol work.
• Some niche policies can be added by extending the protocol; River does not block feasible policy changes.

Related projects and context

• Lower‑level compositor libraries: wlroots, Smithay, Mir.
• Wayland compositors and WMs mentioned for context: Sway, Hyperland, Niri, River (classic), Hyprland.
• River is the project implementing this split; River Classic had similar internal ideas refined over roughly six or more years.

Practical pointers (from the video)

• There is a River compatibility page listing existing WMs that work with River.
• The presenter claims writing a basic, usable WM over a weekend is realistic.
• Encouragement to try River, contribute, or build new WMs for behaviors not yet available.

Claim from the presentation: writing a basic, usable WM over a weekend is now realistic.

Main speakers / sources referenced

• River Project — River Window Management V1 protocol and the v0.4.0 release.
• Architectural background: Wayland and X11 (Xorg).
• Libraries: wlroots, Smithay, Mir.
• Example compositors/window managers referenced: Hyperland, Sway, Niri, River Classic.
• Video narrator / presenter discussing River and Wayland.