📈 GH Trending Explorer 🎲 Surprise me

← all repos

riverwm / river

git clone https://github.com/riverwm/river.git v0.3.0 · 2y ago 🔥 on GitHub Trending today

[mirror] A non-monolithic Wayland compositor

+1
stars, 24h · #7,706
+~7
stars, 7 days · #8,358
+48
stars, 30 days · #11,703
4.3k
★ total · +0% this week
170
forks · 67 open issues

Star history (as recorded here)

2026-10-20 · 4,327 ★ 2026-10-22 · 4,327 ★
LanguageZig
License—
Created2020-03-20 (6y ago)
Last push8d ago
Watchers49
OwnerOrganization

Seen on GitHub Trending

  • 2026-10-21 — #16 monthly in zig · +46 ★
  • 2026-10-20 — #16 monthly in zig · +48 ★

GitHub topics

Links

README excerpt
## Overview
River is a non-monolithic Wayland compositor. Unlike other Wayland compositors,
river does not combine the compositor and window manager into one program.
Instead, users can choose any window manager implementing the
[river-window-management-v1] protocol.
Read my blog post, Separating the Wayland Compositor and Window Manager,
for an in-depth explanation.
There is a [list of compatible window managers] on our wiki.
> *If you are looking for the old dynamic tiling version of river, see
river-classic.*
## Links
- Protocol Docs
- tinyrwm example window manager
- Wiki
- IRC: #river on irc.libera.chat (logs)
- Zulip (new)
- Issue Tracker
- Code of Conduct
## Features
River defers all window management policy to a separate window manager
implementing the [river-window-management-v1] protocol. This includes window
position/size, pointer/keyboard bindings, focus management, window decorations,
desktop shell graphics, and more.
River itself provides frame perfect rendering, good performance, support for
many Wayland protocol extensions, robust Xwayland support, the ability to
hot-swap window managers, and more.
The [river-window-management-v1] protocol and other river protocol extensions
are stable. We do not break window managers.
## Motivation
Why split the window manager to a separate process?
- Significantly lower the barrier to entry for writing a Wayland window manager.
- Allow implementing Wayland window managers in high-level garbage collected
 languages without impacting compositor performance and latency.
- Allow hot-swapping between window managers without restarting the compositor
 and all Wayland programs.
- Promote diversity and experimentation in window manager design.
## Building
Note: If you are packaging river for distribution, see PACKAGING.md.
To compile river first ensure that you have the following dependencies
installed. The "development" versions are required if applicable to your
distribution.
- zig 0.16
- wayland
- wayland-protocols
- wlroots 0.20
- xkbcommon 1.12 or newer
- libevdev
- pixman
- pkg-config
- scdoc (optional, but required for man page generation)
Then run, for example:
 [code] 
To enable Xwayland support pass the `-Dxwayland` option as well.
Run `zig build -h` to see a list of all options.
## Usage
River can either be run nested in an X11/Wayland session or directly
from a tty using KMS/DRM. Simply run the `river` command.
On startup river will run an executable file at `$XDG_CONFIG_HOME/river/init`
if such an executable exists. If `$XDG_CONFIG_HOME` is not set,
`~/.config/river/init` will be used instead.
Usually this executable is a shell script which starts the user's window manager
and any other long-running programs.
See also:
- The `river(1)` man page
- The wiki FAQ
- The [list of compatible window managers]
- The [list of useful companion software]
## Strict No LLM / No AI Policy
Use of generative AI/LLMs is strictly forbidden for all contributions to river.
This includes bug reports and comments