Mir 2.30.0 Lands: Canonical Makes Rust Mandatory and Publishes Its First Roadmap
Canonical has released Mir 2.30.0, the latest version of the Wayland compositor that underpins Ubuntu's desktop and a grab bag of embedded, kiosk, and robotic hardware. It ships with a decisive shift to Rust, multi-monitor bug fixes, and, for the very first time, a public roadmap for the project.
Mir is one of those pieces of the Linux graphics stack that most desktop users have never heard of but rely on whether they know it or not. It is the compositor: the software that takes what each app wants to draw, stacks those surfaces, and pushes the final image to your screen. It speaks the Wayland protocol, the modern replacement for the decades-old X11 system, and Canonical has been developing it since 2011.
It started as an independent stack meant to break Linux's dependence on X11. A 2013 pivot steered it toward Wayland compatibility, and it has quietly become the engine behind the Miriway desktop, the Ubuntu Frame used in kiosks, and Ubuntu's own sessions. Keep in mind that it is a building block more than a finished product, which is why OEMs and shell authors tend to be the real audience here.
The two changes worth paying attention to are the Rust requirement and the roadmap. Everything else is incremental, and probably should be.
Rust is now baked in
Perhaps the most strategically important detail in 2.30.0 is that building Mir now requires Rust. The old optional MIR_ENABLE_RUST CMake flag is gone. The Rust components, chiefly wayland_rs and the experimental evdev-rs input platform, are always compiled now.
This isn't a fashion statement. Mir is targeting Ubuntu 26.04 strictly, and the underlying wayland-rs work needed a compatible version of the cxx bridging crate, so leaving Rust optional stopped making sense. There was real packaging work involved too, including wiring Cargo to resolve crates against Debian and Ubuntu's offline system registry instead of crates.io, plus sorting out cross-compilation issues on ARM.
The experimental Rust evdev driver ships alongside the traditional C++ version. It sits at an "experimental" priority, meaning your default input behavior is unchanged. You opt in deliberately if you want to try it. That is a fairly smart, backward-compatible way to migrate without breaking existing deployments.
It is a reasonable call, though the jury is still out on whether dragging an entire compositor over to Rust is worth the maintenance burden as the codebase grows. For now it at least future-proofs memory-safety work that would otherwise lag behind.
The ABI story and what actually changed
Mir documents each release with an ABI summary, a per-library breakdown of whether the contract between compiled libraries has shifted. For 2.30.0, nearly everything stayed put. miral, mircommon, mircore, and the rest are all unchanged. Only mirserver was bumped, to version 69.
That bump is exactly what you would expect for a release adding protocol support and backend changes. It just means shells and apps linked against the older mirserver need recompiling. Everyone else keeps a stable ABI, which is a welcome sign for packagers who'd rather not churn their builds every cycle.
The official tag itself reads 2.30.0~dev, the Debian "tilde-dev" convention marking the opening development snapshot. It signals that the release is now flowing into pipelines, with a final untagged 2.30.0 to follow once the cycle matures.
Among the concrete additions: wl_fixes support, the experimental Wayland core global that clients use to cleanly destroy a registry. It sounds like a niche detail, but it closes a real compatibility gap, and the underlying work forced Mir's code generator to handle a new kind of core-interface argument for the first time. There is also a typed C++ wrapper for the raw wl_array structure, plus dev tooling that lets you nest into a shell environment more easily.
Bug fixes cover a practical batch of user-facing headaches. Horizontal scroll-speed configuration is now honored. Attached surfaces like on-screen keyboards stop being mistaken for kiosk windows. A regression that broke extended desktop setups on GBM/KMS hardware is finally fixed, restoring the one-to-one mapping between physical outputs and display sinks that multi-monitor users have been missing.
A roadmap, finally
For years, Mir's direction was only implicit, defined through pull requests and issue threads. 2.30.0 publishes the first formal roadmap, available under /roadmap in the docs, and it sketches planned work across upcoming Ubuntu cycles beginning with 26.10.
The plan is ambitious in places. It calls for using a hardware video plane for playback to offload the GPU, building a Mir-based compositor entirely in Rust with a documented tiling window manager example, and stabilizing the mir-shell Wayland extension with feedback from clients like Flutter. It also floats embedding other clients' surfaces into shell components, plus a long-term rendering pipeline specification.
Publishing a roadmap is a quiet but honest sign of maturity. It gives downstream developers, OEMs, and enterprise buyers visibility into a multi-year direction. It is arguably the single most important deliverable in the release, even if it produces no commits on its own. Whether it can actually be kept on track is the question that only time will answer.
Getting it
Mir lives openly on GitHub under the GNU General Public License, versions 2 or 3, with additional LGPL components. It is packaged for Ubuntu, Debian, Fedora, and Arch, and ships as snaps for Ubuntu Core and beyond.
Head here for the full release tag, and over there for the individual pull requests covering wl_fixes, the wl_array wrapper, the Rust requirement, and the multi-display fix. The roadmap itself is the piece to bookmark if you are planning anything on top of Mir.
This report draws from Mir 2.30.0 release notes on GitHub, the linked pull requests, Canonical's Mir product pages, and the newly published roadmap. All information is current as of the September 24, 2026 release.
