One of the things which makes it difficult to get started in a project like Mir - where the core contributors are all Canonicallers and we meet in person a couple of times a year - is that there’s a wealth of oral traditions about large projects we know we want to do, but that aren’t currently a priority and won’t make it onto a roadmap. These are things we know we want to do, probably aren’t going to do in the immediate future, but are large and intricate projects, so probably unsuitable for first-time contributors.
In the interests of making Mir development more accessible to outsiders, as we think of things we’ll be putting such projects into a…
Mir Terrain (definitely not road!) Map
Platform refactoring
Render/Display separation
Mir’s abstraction for “graphics platform” is currently half-way through a separation between rendering and output. Rendering platforms need to provide clients a way to submit buffers to Mir, and provide the rest of Mir with rendering handles (eg: GL textures, CPU buffer content). The Output platforms need to provide a way to display rendering on the physical hardware.
This separation will make a number of things easier. Some devices - like DisplayLink USB docks, which provide output but no rendering, or some ARM boards where output hardware and rendering hardware appear as separate DRM devices - don’t quite match properly our current combined platform interface.
It also makes it cleaner to support…
Loading multiple graphics platforms simultaneously
Mir’s hybrid support is currently limited to systems where all graphics devices are supported by Mesa; relaxing this, and supporting, say, NVIDIA-proprietary/Intel-Mesa hybrid will require (among other things) the ability to load multiple graphics platforms simultaneously.
Loading multiple output platforms would also be helpful for remote desktop support.
Rendering
Replacable Renderer and Scenegraph
When building shells it’s hugely useful if you can use a toolkit! In Unity8, the qtmir component replaces Mir’s default renderer and scenegraph with QtSceneGraph, allowing the Unity8 UI - the bar and indicators, but also the animations, window switcher, and so forth - to be written in Qt (specifically, QML).
We never quite managed to clean this up, so this uses not-guaranteed-stable Mir-internal interfaces. We’d like to reform this, work out what a good interface looks like, and expose a stable, supported method for plugging in an external renderer/scenegraph. And maybe then update qtmir to use the new API and build a GSK (GTK SceneGraph Kit) backend.
This will be useful for more complex, integrated shells - things like GNOME Shell or Unity8, where there’s a significant amount of rendering the shell needs to make and which want to provide a good integrated experience.
General
Hot reloading/crash resiliance
One of the features that Windows does really well and which the Linux desktop lacks is hot relaoding and retart. When you install or upgrade a graphics driver in Windows the display subsystem will quit and reload running the new drivers, without having to restart any of your applications. As an added side-benefit, this means that Windows display subsystem can crash and reload, without taking down any running applications.
It’d be nice to bring this to the linux desktop!
Of all the interesting wishlist items, this is easily the biggest; it requires a bulletproof daemon for keeping state around over restarts/crashes, enhancing libwayland to make it possible to store the necessary IPC state in there, and a bunch of changes throughout Mir to store/validate/restore state in the stash.