Mir is a Wayland compositor library aimed at people writing shells

A library aimed at shell authors, not desktop users

Mir is a set of libraries for building Wayland based shells, published by Canonical. The framing matters, because it tells you what the project is not. Mir is not a desktop environment you install and use, and it is not a window manager you configure. It is the layer underneath, the piece a developer writes against when the product is a shell: a kiosk, an embedded appliance interface, a system compositor, or a purpose built user interface with its own look. The documentation describes it as simplifying the complexity that shell authors need to deal with, providing a platform with touch, mouse and tablet input, multi-display capability and secure client-server communications. The audience is a small set of teams shipping a device or a specialised interface, and the value proposition is that the unglamorous parts of a compositor, device bringup, configuration and hardware quirks, are handled once inside a maintained library rather than in every product.

Window management comes with the platform, not beside it

The design decision that shapes everything else is that window management is integrated into Mir rather than layered on top as a separate program. The project documentation says it comes with useful default behaviour and is extremely customisable by shell authors through a simple high-level API. That distinction matters for anyone who has tried to write a shell on raw Wayland, because the protocol layer gives you surfaces, buffers and input events, and leaves you to decide what a window is, where it goes and how it reacts to input. Mir also handles the bringup and configuration of a broad array of graphics and input hardware, which is where a lot of product time disappears: quirks in touchscreens, digitisers and pointing devices differ between vendors, and the library absorbs those differences so the shell code does not have to. It also integrates with system components such as greeters, so the shell can take over the display in the right order during boot.

A C++ core with Rust components bridged in

Mir is a C++ project, but the repository is not purely C++. The Cargo manifest declares a small workspace whose members are a platform crate for evdev and a Wayland frontend crate:

[workspace]
members = [
  "src/platforms/evdev-rs",
  "src/server/frontend_wayland/wayland_rs"
]
resolver = "2"

The dependency list tells you what those crates are for. The cxx and cxx-build crates are the bridge between the Rust code and the C++ core, input pulls in libinput for device handling, udev covers device discovery, calloop provides the event loop, and wayland-server with wayland-scanner and wayland-backend supply the protocol side. The Rust workspace carries its own version of 0.1.0 and a minimum rust-version of 1.82.0, which is a separate version line from the Mir releases you install. So the architecture is a C++ shell platform with two focused Rust components for input plumbing and the Wayland frontend, joined by a CXX bridge, rather than a rewrite.

Example servers that show what a shell looks like

The examples directory is the most useful part of the repository for anyone evaluating Mir, because it contains several complete servers rather than fragments. There is miral-shell, which is the general shell example, and miral-kiosk, which is the same framework aimed at a single purpose kiosk. There is miral-system-compositor, the variant meant for a system compositor role, and mir_demo_server, a small demonstration server. There is mir-x11-kiosk, a kiosk example that also touches X11, which matches the x11 topic the repository carries. Alongside them sit an example client and an example-server-lib, so you can see both sides of the protocol boundary. These examples are the documentation in executable form. The pattern they show is that a shell author supplies the surface content, the window behaviour and the input handling policy, and leaves the platform concerns to Mir.

Debian, RPM, snap and a spread test harness

Mir ships as a set of packages rather than a single binary, and the repository layout shows the distribution formats it targets: a debian directory, an rpm directory and a snap directory, plus cmake modules, a doc tree, an include tree, an sdk directory and a tools directory. The project also publishes a packaging status badge that points at repology, which is the fastest way to see whether your distribution already carries a build. Testing has its own infrastructure, with a spread.yaml file and a spread directory, spread being the test harness the project uses to run cases across environments. There is a HACKING.md for development setup, a SECURITY.md for reporting issues, a pre-commit configuration and a .clang-format file, which tells you the project treats formatting and hooks as part of the workflow rather than an afterthought. The documentation, the data sheets and the whitepapers live on the Mir website, with usage documentation on canonical.com/mir/docs and discussion happening on the Ubuntu Discourse category for Mir and on a matrix channel.

GPL version 2 or 3, with LGPL files alongside

The copyright sits with Canonical Ltd. and the licensing statement is wider than a single version: the program is free software that you can redistribute and modify under the terms of the GNU General Public License version 2 or 3. The repository carries the matching licence texts as COPYING.GPL2 and COPYING.GPL3, and it also ships COPYING.LGPL2 and COPYING.LGPL3, which usually means parts of the tree are offered under the less restrictive terms while the rest stays copyleft. If you are building a commercial shell on Mir, read those files rather than assuming a single licence applies to the whole tree. On versions, tagged releases include Mir 2.28.0 on 2026-06-05, Mir 2.29.0 on 2026-09-02 and Mir 2.30.0 on 2026-09-24, and the last push was on 2026-10-20. This is a line with recent work behind it, which matters when you are deciding whether to bind a product roadmap to it.

Editorial conclusion

Adopt Mir if you are writing a Wayland shell, a kiosk appliance or a system compositor and you would rather reuse a tested window manager and input stack than write one. Do not adopt it as an end user desktop, since it is a library rather than a shell, and do not expect a drop in C API, because the shipped surface is C++ with Rust components bridged in. Before you start, read the documentation at canonical.com/mir/docs, check the packaging status for your distribution, and confirm that the GPL version 2 or 3 terms and the LGPL files in the repository fit the way you intend to distribute your shell.

Frequently asked questions

Official sources

1. canonical/mir on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases