Reposted in such a way that it can be shared, because G+ hates me.

Standing on the shoulders of giants

We've recently gone public (yay!) with the Mir project that we've been working on for some months now.

It's been a bit rockier than I'd hoped (boo!). Particularly, we offended people with incorrect information the wiki page we wanted to direct the inevitable questions to - https://wiki.ubuntu.com/MirSpec#Why_Not_Wayland_.2BAC8_Weston.3F

I had proof-read this, and didn't notice it - I'm familiar with Wayland, so even with “X's input has poor security” and “Wayland's input protocol may duplicate some of the problems of X” juxtaposed I didn't make the connection. After all, one of the nice things of Wayland is that it solves the X security problems! It was totally reasonable to read what was written as “Wayland's input protocol will be insecure, like X's” which is totally wrong; sorry to all concerned for not picking that up, most especially to +Kristian Høgsberg and +Daniel Stone.

Now that the mea-culpa's out of the way…

Although we've got a section on the wiki page “why not Wayland/Weston” there's a bunch of speculation around about why we really created Mir, ranging from the sensible (we want to write our own display serve so that we can control it) - to the not-so-sensible (we're actually a front company of Microsoft to infiltrate and destroy Linux). I don't think the rationale on the page is inaccurate, but perhaps it's not clear.

Note: I was not involved in the original decision to create Mir rather than bend Wayland to our will. While I've had discussions with those who were, this is filtered through my own understanding, so treat this as my interpretation of the thought-processes involved. Opinions expressed do not necessarily reflect the opinions of my employer, etc.

1) We wanted to integrate the shell with a display server - there are all sorts of frustrations involved in writing a desktop shell in X. See any number of Wayland videos for details :). We therefore want Wayland, or something like it.

2) We didn't want to use Weston. Weston, the reference Wayland compositor, is a test-bed. It's for the development of the Wayland protocol, not for being an actual desktop shell. We could have forked Weston and bent it to our will, but we're on a bit of an automated-testing run at the moment, and it's generally hard to retro-fit tests onto an existing codebase. Weston has some tests, but we want super-awesome-tested code. We don't want Weston, but maybe we want Wayland?

3) At the time Mir was started, Wayland's input handling was basically non-existent. +Daniel Stone's done a lot of work on it since then, but at the time it would have looked like we needed to write an input stack. Maybe we want Wayland, but we'll need to write the input stack.

4) We need server-side buffer allocation for ARM hardware; for various reasons we want server-side buffer allocation everywhere. Weston uses client-side allocation, and the Wayland EGL platform in Mesa does likewise. Although it's possible to do server-side allocation in a Wayland protocol, it's swimming against the tide. Maybe we want Wayland, but we'll need to write an input stack and patch the Mesa EGL platform.

5) We want the minimum possible complexity; we ideally want something tailored exactly to our requirements, with no surplus code. We want different WM semantics to the existing wl_shell and wl_shell_surface, so we ideally want to throw them away and replace them with something new. Maybe we want Wayland, but we'll need to write an input stack, patch the Mesa EGL platform, and redo the WM handling in all the toolkits.

At this point, it looks like we want something like Wayland, but different in almost all the details. It's not clear that starting with Wayland will save us all that much effort, so the upsides of doing our own thing - we can do exactly and only what we want, we can build an easily-testable codebase, we can use our own infrastructure, we don't have an additional layer of upstream review - look like they'll outweigh the costs of having to duplicate effort. Therefore, Mir.

This is only possible because all the ancillary work done by Wayland developers, particularly Kristian. Mir is a Wayland-alike; we're piggybacking on a lot of good work done for Wayland. Hopefully we'll contribute back not just an awesome display server in the form of Mir and an awesome desktop environment in the form of Unity, but also low-level improvements that can be used by Wayland compositors. I'm particularly excited about our engagements with NVIDIA and AMD; although it's early days, I'm hopeful we can get a solution for “but what about proprietary drivers?” not just for Mir, but for everyone.
Shared publiclyView activity