MIR_ENABLE_RUST build switch, and ships with Canonical's first public roadmap for the project. The build change mostly affects developers, packagers, and anyone maintaining a Mir-based shell. It has little bearing on the people who only use devices running one. For Mir, Rust has now gone from an experiment you could switch on to a permanent part of the toolchain, and the roadmap shows where that is heading: Canonical wants people to be able to write a whole Mir compositor in Rust, without C++.
Mir 2.30.0 Drops MIR_ENABLE_RUST and Makes the Rust Toolchain Mandatory
The key line in the release notes is short. The official GitHub release for the v2.30.0 tag lists "Require Rust when building Mir and package the Rust evdev input platform" as change #5185. Require Rust when building Mir and package the Rust evdev input platform #5185 Before this release, Rust support was optional and controlled by a CMake-style build flag, as Phoronix first reported. That flag is gone.
Canonical's own pull request explains why. The automated release PR on GitHub describes change #5185 as a move to drop MIR_ENABLE_RUST from the build, since Rust will be required in 26.04. Phoronix adds context: Mir now targets Ubuntu 26.04 LTS and newer, where Rust is a given, so Mir's build system can assume a Rust compiler is always installed. The practical upshot is that Mir's supported baseline and Ubuntu's toolchain policy now line up, and there is no longer a second, Rust-free build path to maintain and test.
The second half of the change is the input stack. Evdev is the Linux kernel interface that exposes keyboards, mice, touchscreens and other input devices to user space. A compositor has to read those events before it can send them to windows. Mir 2.30 packages the Rust implementation of that evdev input platform, so a component written in Rust now sits in the path every keystroke and pointer movement takes.
Keep the scope in mind. The release notes change the prerequisites for building Mir. They don't say that devices running Mir-based shells need Rust installed separately, and they don't name a minimum Rust compiler version. The new Rust requirement also doesn't mean Mir's C++ codebase has been replaced. It is still a C++ project, now with Rust components it can't be built without.
Mir's Rust Migration Has Been Building Since 2.25
Mir 2.30 is the latest step in a migration that has been visible for several releases. Mir 2.25's release notes already listed Implementation of an evdev platform in rust among its enhancements. That input code is what 2.30 now packages as standard.
Mir 2.26 went further. As 9to5Linux reported through Tux Machines, that version brought an initial implementation of the Wayland frontend in the Rust programming language. By June 2026, Phoronix was describing Mir 2.27 as carrying many Wayland Rust "wayland-rs" changes including support for generating implementations for Wayland events so they can be sent from C++ to Rust to Wayland clients.
So Rust is already in Mir's Wayland protocol layer and its input layer, and the C++ and Rust sides pass events to each other. With an optional build flag, Canonical had to keep a Rust-free configuration working and tested. Removing the flag drops that burden. The 2.30 release PR also includes a change titled all: drop toolchain workarounds, which suggests the team is clearing out compatibility code from the same period.
wl_fixes, Multi-Display Fixes and the Rest of the 2.30.0 Changelog
Apart from the toolchain change, 2.30 is an ordinary feature-and-fix release. Its new features, according to the official notes:
- Mir now supports the Wayland
wl_fixesprotocol, change #5193, which was @andogq's first contribution to the project. - A typed wrapper for
wl_arraymakes the handling of that Wayland data type safer in Mir's code. - The project's workshop tooling gains a
run nest <shell>command. - Mir can build with libxml++ 5.0 where available, with a libxml++ 2.6 fallback for older distributions.
The bug-fix list is mostly about input and window management, which is what shell authors work with day to day. According to 9to5Linux, Mir now safely handles unmanaged surfaces in window_at(), ensures pointer enter and leave events see the final surface geometry after window-management changes, reports wl_surface role conflicts using the correct Wayland protocol error. The official notes also say Mir will no longer treat attached surfaces, such as on-screen keyboards, as kiosk windows. Do not treat attached surfaces, such as on-screen keyboards, as kiosk windows #5157 That one matters on touch-first kiosks, where an on-screen keyboard is part of the interface.
The display fixes may be the most visible. Mir 2.30 improves the horizontal scroll-speed configuration, sets the cursor role on hidden cursor surfaces, fixes GBM/KMS multi-display configurations that do not use clone mode, reuses the screen-shooter renderer, and handles output resizing correctly. GBM/KMS is the direct-to-hardware display path a compositor uses when it drives the screens itself instead of running nested inside another desktop. Anyone running Mir on a multi-monitor setup with extended rather than mirrored displays should test this release.
The documentation work is less visible but useful. The release clarifies input-trigger protocol descriptions, documents the release-burning process, updates the supported environments for release testing, and adds a project roadmap.
The mirserver ABI Bump to 69 Is the Packaging Change to Watch
Each Mir release reports the ABI (application binary interface) version of every library it ships. An ABI bump means binaries linked against the old version may not work with the new one without rebuilding. In 2.30, mirserver is bumped to 69, while miral remains at 8, mircommon at 13, mircore at 3, miroil at 10, mirplatform at 35, mirwayland at 7, mirplatformgraphics at 24, and mirinputplatform at 11.
Linux Compatible reads this to mean only shells and apps linked against mirserver need recompiling. That follows from how ABI versioning works, and it's reassuring for projects built on MirAL, Mir's higher-level abstraction layer, whose ABI hasn't changed. Still, whether a given shell links mirserver directly depends on how it was built. Packagers should check their own link dependencies rather than assume.
One oddity in the primary record: the GitHub release heading says "Mir 2.30.0", but the generated notes begin with New upstream release 2.30.0~dev. The tag itself is v2.30.0, and every outlet covering the release treats it as the final 2.30.0. The "~dev" suffix looks like a leftover in the release-note template, not a sign this is a development snapshot.
Mir Roadmap for Ubuntu 26.10 Puts a Pure-Rust Compositor on the Table
The roadmap shows what the Rust requirement is for. Canonical's new roadmap page files all of its current items under Ubuntu 26.10, and it comes with a clear warning: Canonical also published a formal roadmap outlining plans from Ubuntu 26.10 onward. Canonical calls the roadmap exploratory and says it may change as priorities, designs and implementation details develop. Treat these items as intentions, not delivery dates.
The headline item is a Rust compositor API. Canonical plans an idiomatic Rust API, modelled on MirAL, for building a Mir-based compositor without writing C++. The plan says it will cover the relevant MirAL functionality, come with a documented example compositor, and be built and tested in CI. Canonical says this should make it practical to write a small tiling window manager in Rust. Making Rust mandatory at build time is the groundwork: a Rust-first public API wouldn't work if Rust were only an optional extra.
The rest of the roadmap splits into performance, protocol and platform work:
- A hardware plane for video playback would put eligible video subsurfaces on dedicated display planes when the hardware supports it. Only the video plane would need updating and no format conversion would be needed, which could cut GPU load. Candidates would be picked based on subsurfaces, colour formats, refresh rates and hardware capabilities.
- The mir-shell Wayland extension would reach a documented v2, shaped by feedback from a real client such as Flutter. The goal is to meet that client's window-management needs without workarounds.
- A privileged protocol would let shell components such as app switchers embed other clients' toplevel surfaces, with simple scaling and translation. The design would follow
wp_viewporterand the subsurface protocols. - A long-term rendering-pipeline specification would weigh compositor flexibility against Mir's control of rendering. It would cover animations, window effects, input routing, and how these relate to GL, Vulkan, SoC-optimised or software renderers.
- A public MirAL
OutputConfigurationPolicycustomization point would let third-party developers write output-configuration logic using only MirAL abstractions, similar to the existingWindowManagementPolicy. - Stable interfaces would let a custom renderer module be loaded at runtime and supplied through a custom GPU support snap.
Two items are aimed at deployment. The shell security work promises documentation and tools for building baseline-secure shells. It would cover granting specific protocols to specific clients, the risks of privileged protocols, which protocols should never be exposed to sandboxed apps, client identification, and possible use of the Wayland security-context protocol. The systemd integration item promises documentation, example units and code where needed so shells can run full systemd user sessions. The compositor would signal readiness before graphical session components start and shut down correctly.
For teams building kiosks and embedded devices, the Mir market 9to5Linux describes as embedded and kiosk display stacks, those last two items could matter more than the Rust API. Shell security guidance and systemd lifecycle management are problems every appliance vendor currently solves alone.
What Mir 2.30 Means for Shell Authors and Packagers
If you build Mir from source or package it, act now. Everyone else can mostly treat this as a routine upgrade. Build environments that were set up without Rust will fail once they move to 2.30, because the switch that used to let you skip Rust no longer exists. Canonical has matched this to Ubuntu 26.04 LTS. On older distributions, whether a suitable Rust toolchain is available is now your problem, and the release notes don't name a minimum compiler version.
Shell authors should look at the ABI summary and the input and display fixes before anything else. The roadmap is useful for planning, but the 26.10 grouping is explicitly provisional, so don't commit product timelines to a Rust compositor API that doesn't exist yet.
- Install a Rust compiler in every Mir build environment and remove any
MIR_ENABLE_RUSTsetting from build scripts, because Mir 2.30.0 now requires Rust and has dropped that option. - Rebuild anything that links against mirserver, whose ABI moved to 69. The MirAL, mircommon, mircore, miroil, mirplatform, mirwayland, mirplatformgraphics and mirinputplatform ABIs are unchanged.
- Test multi-monitor GBM/KMS setups that don't use clone mode, and kiosk shells with on-screen keyboards, since 2.30 fixes both areas.
- Expect the libxml++ dependency to use version 5.0 where your distribution offers it, with libxml++ 2.6 still supported as a fallback.
- Read the roadmap as Canonical's stated direction for Ubuntu 26.10, including a MirAL-like Rust API, hardware video planes and systemd session support, not as a delivery commitment.
Mir 2.30 shows that Canonical is now fully committed to Rust in Mir, and its roadmap makes that direction official. The next milestone is the Ubuntu 26.10 cycle. If the Rust compositor API ships as described, with a documented example compositor tested in CI, developers will be able to build a Mir shell without writing any C++. The build-time requirement in this release is what makes that possible.