Home / ubuntu / Questions / 314495
Accepted
Naveen
Asked: 2013-06-30 16:56:26 +0800 CST

Why did Canonical choose Mir over Wayland as the display server?

  • 772

I like to know, what are the advantages of Mir.

mir

2 Answers

  1. Best Answer

    Why Not Wayland / Weston?

    An obvious clarification first: Wayland is a protocol definition that defines how a client application should talk to a compositor component. It touches areas like surface creation/destruction, graphics buffer allocation/management, input event handling and a rough prototype for the integration of shell components. However, our evaluation of the protocol definition revealed that the Wayland protocol does not meet our requirements. First, we are aiming for a more extensible input event handling that takes future developments like 3D input devices (e.g. Leap Motion) into account. Please note though that Wayland's input event handling does not suffer from the security issues introduced by X's input event handling semantics (thanks to Daniel Stone and Kristian Høgsberg for pointing this out). With respect to mobile use-cases, we think that the handling of input methods should be reflected in the display server protocol, too. As another example, we consider the shell integration parts of the protocol as privileged and we'd rather avoid having any sort of shell behavior defined in the client facing protocol.

    However, we still think that Wayland's attempt at standardizing the communication between clients and the display server component is very sensible and useful, but due to our different requirements we decided to go for the following architecture w.r.t. to protocol-integration:

    A protocol-agnostic inner core that is extremely well-defined, well-tested and portable. An outer-shell together with a frontend-firewall that allow us to port our display server to arbitrary graphics stacks and bind it to multiple protocols.

    In summary, we have not chosen Wayland/Weston as our basis for delivering a next-generation user experience as it does not fulfill our requirements completely. More to this, with our protocol- and platform-agnostic approach, we can make sure that we reach our goal of a consistent and beautiful user experience across platforms and device form factors. However, Wayland support could be added either by providing a Wayland-specific frontend implementation for our display server or by providing a client-side implementation of libwayland that ultimately talks to Mir.

    There is a more detailed discussion here : https://wiki.ubuntu.com/Mir/Spec?action=show&redirect=MirSpec

    And from the Mir technical architect:

    http://samohtv.wordpress.com/2013/03/04/mir-an-outpost-envisioned-as-a-new-home/

    More information:

    • 15

  2. Jono Bacon on his Q and A has answered this a few times. His latest answer is here:

    http://www.youtube.com/watch?v=6Oa2psAewtg&feature=share&t=56m36s

    From what I have gathered from the likes of Jono's Q&A's, and Popey's comments on Linux Unplugged, the points can be summarized as follows:

    1. Wayland does too much. Having perpetually unused features in your software stack is poor software design.
    2. Wayland's team would not be flexible enough to offer a gutted version of Wayland to accommodate adequately, respectfully.
    3. Mir is to Wayland, what LightDM is to GDM/KDM.
    4. Ubuntu has very dire deadlines that they need to meet with phone manufacturers and the like. Having control over a project makes it easier to infuse extra resources to guarantee that these deadlines are met.
    5. Although I do not think this reason ever officially came from canonical, and thus is just speculation upon my part, at the time which the decision was made, Wayland did not seem like it was moving quick enough to market, and the existing Android technology seemed like a more appropriate base to launch their product from.
    • 11