A library for writing Wayland compositors
- swlr provides backends that abstract the display and input hardware, DRM with atomic modesetting and a hardware cursor plane, a nested Wayland backend for developing without a spare VT, and a headless one for tests, picked automatically for whatever it is running on.
- swlr provides a long list of Wayland protocols already implemented,
xdg_shell,layer_shell,linux_dmabuf,session_lock,text_input,screencopy, and everything else on the list further down, so none of it is a wire protocol you write a handler for yourself. - swlr provides a scene graph with damage tracking, so only what changed gets redrawn, and the hit testing that turns a pointer position into a surface.
- swlr provides a renderer abstraction, GLES2 where the hardware allows it, pixman software rendering everywhere else, through one small render pass API.
- swlr provides server side window decoration, a client here never draws its own frame, you draw it, however it should look.
None of this decides where a window goes, what a keybinding does, or what a title bar looks like. That is policy, and it is entirely up to whatever gets built on top, a example.
The package, the pkg-config name, and every symbol in it are swlr, the name
in the title above is just what the project as a whole goes by.
See doc/writing-a-compositor.md for a guide through the whole API, server lifecycle, signals, outputs, windows, etc..
meson setup build
ninja -C build
ninja -C build install
Needs wayland-server and wayland-client >= 1.22, wayland-protocols >= 1.32, libdrm >= 2.4.109, pixman, xkbcommon, libinput >= 1.14 and libudev.
GBM, GLES2, libseat and freetype plus fontconfig are auto: found means built,
missing means the reduced path is what is left. Without GBM and GLES2 the
software renderer is all there is, without libseat there is no seat managed
session, so no real tty, without freetype title bars have no text. meson setup
prints which ones ended up in the build.
meson setup build -Dgbm=disabled -Dgles2=disabled # software only
Static works too. default_library=both means the install carries libswlr.a
alongside the shared object already, and the pkg-config file lists the private
dependencies a static link needs to resolve:
meson setup build -Ddefault_library=static
ninja -C build && sudo ninja -C build install
- wlroots, the C library most Wayland compositors on Linux build on.
- shrub, for neuswc and neuwld, a compositor library and drawing library pair.
- Smithay, the Rust library niri is built on.
- Weston, the source of
swl-gearsand its toytoolkit.
include/swl/swl.h the entire compositor API
include/swlr/ the rendering layer, one header per subject
src/backend/ drm, nested wayland, headless, libinput, session
src/core/ server, surfaces, outputs, buffers, subcompositor
src/scene/ the scene graph, damage tracking, traversal
src/shell/ xdg_shell and layer_shell
src/protocol/ everything else on the protocol list above
src/input/ seats, keyboards, pointers
src/decor/ server side decorations
src/allocator/ gbm, shm and dumb allocators
src/render/ renderer interface, gles2 and pixman implementations
src/drm/ device discovery
src/format.c pixel formats, modifiers, format set arithmetic
src/buffer.c the buffer type and its lifetime
protocol/ XML for protocols wayland-protocols does not ship
doc/ writing-a-compositor.md, a guide to the compositor API
example/ a working compositor, small enough to read in one sitting
test/ the smoke test, which needs no compositor, and the
protocol clients, which run against one that run-tests.sh
brings up. Plus things meant to be run by hand:
swl-gears, weston's gears off the toytoolkit, which
brings up EGL and desktop OpenGL itself, prints the frame
rate it got, and with -p reports which contexts this
compositor's clients can actually get.
swl-test-core-profile-client, which draws through a 3.2
core context the way a modern engine does. And the
swl-stress-* harnesses, which measure frame pacing and
what a configure storm costs.