A smithy for rusty Wayland compositors

Goals

Smithay aims to provide building blocks to create Wayland compositors in Rust. While not being a full-blown compositor, it'll provide objects and interfaces implementing common functionalities that pretty much any compositor will need, in a generic fashion.

It supports the core Wayland protocols, the official protocol extensions, and some external extensions, such as those made by and for wlroots and KDE.

Also:

• Documented: Smithay strives to maintain clear and detailed documentation of its API and functionalities. Compiled documentation is available on docs.rs for released versions, and here for the master branch.
• Safety: Smithay aims to be memory-safe and reliable, thanks to Rust.
• Modularity: Smithay is not a framework and does not impose constraints. You are never required to use components you don’t need.
• High-level: You should not have to worry about gory low-level stuff (but Smithay won't stop you if you really want to dive into it).

Getting started

If you want to learn how to build a compositor with Smithay, the best place to start is the getting started guide.

Anvil

Smithay as a compositor library has its own sample compositor: anvil.

To get information about it and how you can run it, check out the anvil README

Other compositors that use Smithay

• Cosmic: Next-generation Cosmic desktop environment
• Catacomb: A Wayland Mobile Compositor
• emskin: A nested Wayland compositor for embedding any app inside Emacs
• MagmaWM: A versatile and customizable Wayland Compositor
• Niri: A scrollable-tiling Wayland compositor
• Strata: A cutting-edge, robust and sleek Wayland compositor
• Pinnacle: A WIP Wayland compositor, inspired by AwesomeWM
• Sudbury: Compositor designed for ChromeOS
• wprs: Like xpra, but for Wayland, and written in Rust.
• Local Desktop: An Android app for running GUI Linux via PRoot and Wayland.
• Otto: A gesture-driven stacking compositor.
• DriftWM: A trackpad-first infinite canvas Wayland compositor.

System Dependencies

(This list can depend on the features you enable)

• libwayland
• libxkbcommon
• libudev
• libinput
• libgbm
• libseat
• xwayland

Contact us

If you have questions or want to discuss the project with us, our main chatroom is on Matrix: #smithay:matrix.org.

Contributing

General notes on contributing to Smithay can be found here.

Please note that to submit code to Smithay, you must agree to our Developer Certificate of Origin.

If you are used to using generative AI, please ensure you read our Policy before starting.

Why this fork exists

This fork carries five functional patches on top of upstream 812bd33259ff58810dadef6086d8385eeac1ca55 (renderer: cgmath -> glam, 2026-07-14), plus the fork's own explanation, CI contract and toolchain compatibility fixes.

• wlr-layer-shell: do not validate a role the client already destroyed. A teardown race: the client destroys the role, the compositor validates it anyway, the session dies.
• session-lock: tolerate a bufferless commit before the first ack. Qt commits once before the first configure ack, which the protocol forbids. This fork tolerates only that bufferless compatibility commit; attaching a buffer before the ack still fails.
• gles: optional linear-space gamut transform on sampled textures. Opt-in. Needed to map sRGB content into a panel's own primaries.
• drm/compositor: wait when there is no native fence. Without it a device with no native fence tears.
• gles: optional chromatic split on sampled textures. Opt-in.

The layer-shell teardown and fence wait are upstream candidates. The session-lock change is an explicit Qt compatibility exception. The two gles changes are ViewTop-facing features, gated and off by default. None has been submitted upstream yet.

Consumed by souveraine-viewtop, which pins this fork by revision.