The Mir server and client code is written in C++ and is hosted within a Bzr Launchpad repository. As of this evening there's been 461 commits to the Mir repository since it was internally created in June of last year. As far as who's developing this display server not derived from X.Org or Wayland, see The Developers Behind The Mir Display Server.
Within the Mir's repository is a HACKING file that goes over the process of building and running Mir. It's a fairly straight-forward process. Mir does make use of the C++ Boost libraries.
In terms of how large Mir is at this point, the src/ directory that is home to the client, protobuf, server, graphics, input, and other code for Mir, is just 14,661 lines of code (that also includes a bit of the cmake files and other files). Or at least what's publicly exposed by Canonical for now...
Running Mir requires a modified Mesa stack. For the Gallium3D/Mesa drivers to work with Mir, a new EGL DRI2 component to Mesa is needed, which Canonical has in their own packaged version of Mesa within a Launchpad PPA but they haven't yet attempted to upstream their Mir changes for Mesa. The Mesa package can be found in this PPA. They also have a Mir package, which is actually packaged for the Quantal (Ubuntu 12.10) repository while the Mesa package is only packaged for Raring (Ubuntu 13.04). However, the Mir packages in there right now aren't too useful and don't include Canonical's demo clients for Mir.
Right now Mir is said to only work with the Intel and Radeon open-source graphics drivers, but evidently is not yet working for Nouveau. In terms of binary drivers supporting Mir, Canonical claims to be pressuring AMD and NVIDIA to support it, but that will likely be quite some time until those blobs make the changes to fully support EGL and other requirements. Canonical's Mir design plan is also for Android graphics drivers to be compatible with Mir. Mir's requirements are on EGL (not GLX) and OpenGL / OpenGL ES.
As covered within their hacking file, right now running Mir does require running an X.Org Server. Mir isn't running atop an X.Org Server, but rather the server needs to be running for setting up the graphics adapter and the necessary access rights. Mir is simply run from a separate virtual terminal while the X.Org Server is running, but if it's not, the document says you will get "strange errors." Switching between the xorg-server and Mir sessions will also result in X dieing.
Found within the Mir repository is a mir_demo_client_accelerated binary that they suggest as the Mir demo application at this point. I built Mir from the latest source (Revision 461) and installed the modified Mesa 9.1 drivers. This was happening from an Intel Ivy Bridge setup with the HD 4000 graphics and running an Ubuntu 13.04 snapshot.
When following the instructions for building and running the Mir demo, I was less than impressed... Embedded below is the minute-long video that shows switching from X.Org into the VT and running this accelerated Mir client demo.
There isn't much at all yet to this Mir client demo. Mir might be capable of more, but not what's being shown from this demo. The Mir un-accelerated demo version also doesn't do much.
Thinking I was perhaps overlooking something or that it was broken, I dug deeper. I then came across this Launchpad Blueprint for Mir. This page shows the official items on Mir that they still have to do:
- Modality state into surface model
- Window decoration
- Window resizing
- Semi-maximised states
- Proximity regions
- Overlay scrollbar
- Side stage
- Input transformation
- Workspaces in surface model
- Non-homogeneous DPI displays
- Window deformation
- Inter-session effects
- Ready notification
- Boot / shutdown
- Mir on Mir
- Greeter on Mir
- Client transition animations
- Form-factor information status update
- Remote access
- Shell input control - pointer barriers, acceleration etc
- GTK+ support
- XUL support
- Libreoffice support
- Update control center
- Input methods, accessibility
So while there's some early Mir code out there, initial Mir bindings for Qt5 within the QMir code-base, and some early work on LightDM support for Mir, they have a hell of a lot ahead of them.
Seeing as Canonical doesn't have any serious low-level Linux graphics developers as part of the small team working on Mir and the company has further alienated upstream X.Org/Wayland/Mesa developers with Mir, it will be a miracle if Mir is ready for all form factors in a production environment by Ubuntu 14.04 LTS next year.
Ubuntu LTS releases used to be about stability and well-tested code so it's a surprise they plan to introduce the new display server into Ubuntu 14.04. For at least Ubuntu 14.04 on the desktop I think it will be more likely they will end up pushing Mir as just an experimental feature while an X.Org Server will continue doing the bulk of the work. Then again, it was just last year that Canonical thought they would have a Wayland-based System Compositor for Ubuntu 12.10.