Two weeks with Mir

Tuesday, July 9th, 2013

Mir has been running smoothly on my laptop for two weeks now. It’s an all-Intel Dell XPS, so the driver stack on Ubuntu is very clean, but I’m nonetheless surprised that the system feels *smoother* than it did pre-Mir. It might be coincidence, Saucy is changing pretty fast and new versions of X and Compiz have both landed while I’ve had Mir running. But watching top suggests that both Xorg and Compiz are using less memory and fewer CPU cycles under Mir than they were with X handling the hardware directly.

Talking with the Mir team, they say others have seen the same thing, and they attribute it to more efficient buffering of requests on the way to the hardware. YMMV but it’s definitely worth trying. I have one glitch which catches me out – Chromium triggers an issue in the graphics stack which freezes the display. Pressing Alt-F1 unfreezes it (it causes Compiz to invoke something which twiddles the right bits to bring the GPU back from it’s daze). I’m told that will get sorted trivially in a coming update to the PPA.

The overall impression I have is that Mir has delivered what we hoped. Perhaps it had the advantage of being able to study what went before – SurfaceFlinger, Wayland, X – and perhaps also the advantage of looking at things through the perspective of a mobile lens, where performance and efficiency are a primary concern, but regardless, it’s lean, efficient, high quality and brings benefits even when running a legacy X stack.

We take a lot of flack for every decision we make in Ubuntu, because so many people are affected. But I remind the team – failure to act when action is needed is as much a failure as taking the wrong kind of action might be. We have a responsibility to our users to explore difficult territory. Many difficult choices in the past are the bedrock of our usefulness to a very wide audience today.

Building a graphics stack is not a decision made lightly – it’s not an afternoon’s hacking. The decision was taken based on a careful consideration of technical factors. We need a graphics stack that works reliably across a very wide range of hardware, that performs predictably, that provides a consistent quality of user experience on many different desktop environments.

Of course, there is competition out there, which we think is healthy. I believe Mir will be able to evolve faster than the competition, in part because of the key differences and choices made now. For example, rather than a rigid protocol that can only be extended, Mir provides an API. The implementation of that API can evolve over time for better performance, while it’s difficult to do the same if you are speaking a fixed protocol. We saw with X how awkward life becomes when you have a fixed legacy protocol and negotiate over extensions which themselves might be versioned. Others have articulated the technical rationale for the Mir approach better than I can, read what they have to say if you’re interested in the ways in which Mir is different, the lessons learned from other stacks, and the benefits we see from the architecture of Mir.

Providing Mir as an option is easy. Mir is a very focused part of the stack, it has far fewer tentacles and knock-on consequences for app developers than, say, the init system, which means we should be able to work with a very tight group of communities to get great performance. It’s much easier for a distro to engage with Mir than to move to SystemD, for example; instead of an impact on every package, there is a need to coordinate in just a few packages for great results. We’ve had a very positive experience working with the Qt and WebKit communities, for example, so we know those apps will absolutely fly and talk Mir natively. Good upstreams want their code widely useful, so I’ve no doubt that the relevant toolkits will take patches that provide enhanced capabilities on Mir when available. And we also know that we can deliver a high-performance X stack on Mir, which means any application that talks X, or any desktop environment that talks X, will perform just as well with Mir, and have smoother transitions in and out thanks to the system compositor capabilities that Mir provides.

On Ubuntu, we’re committed that every desktop environment perform well with Mir, either under X or directly. We didn’t press the ‘GO’ button on Mir until we were satisfied that the whole Ubuntu community, and other distributions, could easily benefit from the advantages of a leaner, cleaner graphics stack. We’re busy optimising performance for X now so that every app and every desktop environment will work really well in 13.10 under Mir, without having to make any changes. And we’re taking patches from people who want Mir to support capabilities they need for native, super-fast Mir access. Distributions should be able to provide Mir as an option for their users to experiment with very easily – the patch to X is very small (less than 500 lines). For now, if you want to try it, the easiest way to do so is via the Ubuntu PPA. It will land in 13.10 just as soon as our QA and release teams are happy that its ready for very widespread testing.

59 Responses to “Two weeks with Mir”

  1. Open Source Pixels » Shuttleworth: Two weeks with Mir Says:

    […] Shuttleworth defends the development of the Mir display server on his blog. “Of course, there is competition out there, which we think is healthy. I believe […]

  2. Brian Says:


    I have been a long time supporter of Ubuntu. However, based on recent events it looks like Canonical really wants to close source ubuntu as much as possible to start delivering a product. I have faith still, but I still see no technical reason for Mir over Wayland other than complete control of the stack. I don’t mind using proprietary software however, I draw the line at the OS. I want my os to be free and open source. I can use proprietary drivers etc (I have XPS Developer Edition 13.04 running now). Is there a plan to go closed source at some point? Its clear that seems to be within the realm of possibility. Is all the Jono and your posts really FUD or are you serious about Mir having true advantages over Wayland being written by the origional X11 dev’s?

  3. celso Says:

    People, ler ubuntu work on mir as the way they want. everybody is able to create the software they want. In my 2 small cents, its healthy this competition (mir). since a few years back, ubuntu was the distro who wanted to inovate. why they should stop doing it now? i just would like it just still open source and more configurable.
    ( sorry for my bad english)
    i as ceptic but i am not anymore. you have my trust Mark! Good luck!

  4. LinuxLife Blog » News: Mark Shuttleworth: Zwei Wochen mit Mir Says:

    […] Shuttleworth schreibt, setzt er seit zwei Wochen auf seinem Dell-Laptop, der auf Intel-Chips beruht, die aktuelle […]

  5. mark Says:


    Mir is open source – GPL – just like pretty much everything we do.

    Mir will work with proprietary drivers, because that’s just practical reality.

    Finally, yes, I think Wayland is repeating the mistakes of X, and I would like to have a fast, lean, clean option that does not.


  6. mark Says:


    Here’s some feedback from one of the lead developers of Mir:

    Firstly, we’re not doing memory allocation in the sense that you mean. We’re allocating the buffers for the client’s window; the client is free to allocate the rest of its buffers – textures, etc – however it wishes.

    Now, there *is* a context switch involved in the SwapBuffers call, but that context switch is inherent in having the display server control the output hardware. You have to switch to the display server context to present the buffer on the screen. If you want to be synchronised to vblank that also means your client needs to wait on the display server. And you always want to be synchronised to vblank.

    It’s also only one context switch per frame.

    We have additionally *chosen* to make clients who don’t wait for vblank roundtrip to Mir, but that’s not difficult to change.

    The only way you could possibly get a no-context-switch SwapBuffers is if you could give revokable pageflip privileges to a client – an extreme form of composite-bypass. This is not currently possible. There’s work happening in the drm stack around splitting modesetting privileges and rendering privileges – the rendernodes work – which may make this possible. If it does, there’s no reason we can’t support it, as it doesn’t require client allocation anyway.

    Of course, even if you remove all graphics context switches, input still requires a context switch.

  7. mark Says:

    Will do 🙂

  8. mark Says:


    Yes, battery life is very important to Mir, because of its relevance in the mobile push (phone and tablet).

  9. mark Says:

    @Robert Smol, look closer, and perhaps with a slightly more open mind 😉