Why Mir

Mir provides a framework for integration between three parts of the graphics stack.

These parts are:

  1. The drivers that control the hardware
  2. The desktop environment or shell
  3. Applications with a GUI

Mir currently works with mesa-kms graphics, mesa-x11 graphics or android HWC graphics (work has been done on vulkan graphics and is well beyond proof-of-concept but hasn’t been released).

Switching the driver support doesn’t impact the shell or applications. (Servers will run unchanged on mesa, on X11 and android.) Mir provides “abstractions” so that, for example, user input or display configuration changes look the same to servers and client applications regardless of the drivers being used.

Mir supports writing a display server by providing sensible defaults for (e.g.) positioning tooltips without imposing a desktop style. It has always carried example programs demonstrating how to do “fullscreen” (kiosk style), traditional “floating windows” and “tiling” window management to ensure we don’t “bake in” too many policies.

Because the work has been funded by Canonical features that were important to Ubuntu Phone and Unity8 desktop have progressed faster and are more complete than others.

When Mir was started we needed a mechanism for client-server communications (and Wayland wasn’t in the state it is today). We did something that worked well enough (libmirclient) and, because it’s just a small, intentionally isolated part of the whole, we could change later. We never imagined what a “big deal” that decision would become.


[added]

Seeing the initial reactions I can tell I made a farce of explaining this. I’ll try again:

For the author of a shell what Mir provides is subtly but significantly different from a set of libraries you can use to build on: It provides a default shell that can be customized.

21 thoughts on “Why Mir”

  1. For me it sounds like, you could implement all this stuff with wayland protocoll support from the very beginning.

    The problem with mir was that you hided it from the community for a year and on release Mark said basicly: “Haha, we said we will do wayland, but we doing mir behind closed doors for a year”.

    And then there was this Mir (Spec) wiki article, with wrong accusation what wayland can’t do. Every single of them was wrong and later on wayland was first with real support.

    When mir was in development wayland wasn’t frozem.
    Now the 1million doller question:
    Why weren’t you active in the development of wayland (code and mailinglists)?

    1. > Why weren’t you active in the development of wayland (code and mailinglists)?

      We all make a living, and what I was asked to do wasn’t immoral (which I would have refused).

      It isn’t nice working on a project that’s kept secret. It wasn’t nice to wake up and find the project had been announced along with a load of unnecessary bullshit. That was corrected as soon as anyone knowledgeable saw it.

      1. >We all make a living, and what I was asked to do wasn’t immoral (which I would have refused).
        Maybe it wasn’t nice of me to write “you” ‘couse it was a company thing. Sorry about that 🙂

        >It isn’t nice working on a project that’s kept secret. It wasn’t nice to wake up and find the project had been announced along with a load of unnecessary bullshit. That was corrected as soon as anyone knowledgeable saw it.
        I undestand if you belive in something and you put your heart into this, then it’s hard to go through all of this crap.

        I don’t know who. But maybe (i hope) this is a wake up for some people at canonical. I hope these people realize now, working with the community is essential. Without that canonical is just another company to the people.

        I hope you do fine 🙂

  2. Problem here is wayland development has skinned the same problem as Mir by using Libraries.

    https://aur.archlinux.org/packages/mesa-hybris-wayland-egl/
    –Servers will run unchanged on mesa, on X11 and android–
    Wayland compositors run unchanged on those three platforms by being abstracted by egl and libinput.

    Still you have provided nothing that explains why should we have the overhead of Mir.

    –(work has been done on vulkan graphics and is well beyond proof-of-concept but hasn’t been released).–
    This is Mir complete problem. NIH. The reality that you have developed so much in house without it being released for peer review means that you could have coded in core design faults.

    –Because the work has been funded by Canonical features that were important to Ubuntu Phone and Unity8 desktop have progressed faster and are more complete than others.–
    Reality this is not true. So far you have not presented anything that is more complete that want has existed for quite some time. Remember libhybris comes out of the Mer project being QT based phones. Mir name conflicts for a lot of people with Mer. So Mir project was poorly named from the start.

    Of course Unity8 ported to Wayland would allow Mer as a group to move forwards more unified.

    You really need to explain why Mir quite well to explain why its not worthless fragmentation with performance problems. If mir remains the fragmenting force it has been it will do no one any good.

    1. Of course software is delivered in libraries, and any compositor will address these problems. Some better than others.

      The only “worthless fragmentation” that Mir introduces that wouldn’t equally apply to, say, Mutter and KWin is the client-server communications.

      1. Kwin and Mutter are not fragment when it comes to client server communications with Wayland.
        https://wayland.freedesktop.org/docs/html/apc.html
        https://wiki.qt.io/QtWayland
        Yes sitting at the core of Mutter and Kwin Wayland support is libwayland-server and that is doing the communications.

        Kwin uses libwayland-server wrapped in QtWayland to be C++ and Mutter using libwayland-server directly. Then you go to enlightenment and all the other Wayland servers and you find libwayland-server over and over again.

        Alan Griffiths you have not looked under the hood of what dependencies Wayland compositors are using to notice repeating dependency libwayland-server. So instead of running a service like Mir with common functionality Wayland compositors have stacked it all into a library. Why would you have to use libwayland-server because there is not fragmentation in how the wayland server protocol is implemented by wayland compositors and it would not be sane to start something different to libwayland-server.

        Alan Griffiths so what fragmentation between Kwin and Mutter is there currently. I see no real fragmentation here these days. Before libwayland-server there was fragmentation in the wayland world of different groups creating their own wayland implementations..

        So Mir wants to support Wayland protocol at the same level as all the other Wayland compositors hello use libwayland-server. Then with the functionality in libwayland-server how much will be left of mir after you remove all the duplication.

        The issue here there was two solutions to a problem. 1 implement a service and take the overhead of a service. 2 implement a library of shared functionality.

        The question is can the path Mir took be justified. But it does require you to step back and wake up that Wayland compositors are not 100 percent independent to each other and there is quite minimal fragmentation on how things are done these days.

        Question is if Mir does have some functionally libwayland-server does not have is there anything blocking it being merged into libwayland-server. If there is some unique feature with enough benefit this would be a reason to keep Mir around.

        Issue is most of your sales points of mir are gone. Wayland developers addressed them.

        Chris Rosenau check the mailing list for wayland for who suggested creating libwayland-server to unify the protocol none other than me. Issue here I don’t do a lot that is right. I ask a lot of questions why X is not done. Now sometimes this leads to development paths being changed and problems going away for good.

        I am not saying I will not back Mir but the big I am asking is what exact advantage is Mir attempting to provide. If you look closely there is way less fragmentation in implementation under wayland than there was under X11. Include more functionality done by a shared library between all compositors.

        Mir was designed to address X11 fragmented mess and early Wayland not using a shared library between compositors. Since this is changed is Mir still valid idea or should it be given up on .

        It happens from time to time that someone invests years in a project only to wake up another project that took another path has done it better so their project was a waste of time.

        Mir is particular hard thinking to implement Wayland compatibility properly will be using libwayland-server then you have duplication on functionality and conflicts because that is not designed to get along with Mir.

        Just because you like something is not enough to keep a project alive. Project has to provide some benefit.

        The idea of Mir now supporting Wayland is way too little way to late. Mir need to start supporting Wayland when libwayland-server started so the shared library was made in ways compatible to Mir.

        1. “The issue here there was two solutions to a problem. 1 implement a service and take the overhead of a service. 2 implement a library of shared functionality.”

          Here you lose me. What is this “service” you talk about? I know it isn’t part of Mir (which is a set of libraries sharing functionality) and I don’t see it in Mutter either.

  3. It is amazing how people complain about Mir who have zero investment in what it is doing and are not impacted by it. Yet you have to deal with people like oiaohm who haven’t proved they can do anything but make up opinions and then demand that you explain yourself. But it is so much easier to Troll and hate and then actually contribute anything positive towards the world.

    Alan thanks for all the work you have done. I hope Mir makes it to production and we get to enjoy your hard work.

    1. Chris, thanks for the kind words.

      I’m tempted to add that Unity8, MirAL and Mir are all available in Ubuntu 17.04.

      $ sudo apt install unity8-desktop-session miral-examples libmiral-dev

  4. #Griffiths my friend
    You are a developer not a businessman.
    You do not need to explain to anyone why business took wrong decisions and you as part of a team making a living and being loyal to the project worked hard on materializing that ill vision.

    I do understand your Mir attachment, and I’d like everyone of the Linux community to be brave through their anger on company leadership rather than stone developers working on opensource projects for something out of their control.

    Mir retool itself to use wayland as a protocol. I suggest you look at the unity8.org and offer them some assistance.

    Still Mir and unity8.org will need cooperate interest to become relevant.

  5. Sorry, but I can’t see the answer for the title question in the blogpost body.

    So I will make the question a bit more specific to make answers easier: “what can now Mir do, that isn’t already solved by Wayland?”

    1. I think it cool that I can write a minimal shell (miral-kiosk) in under 500 lines of code and that the same framework is flexible enough to support a “full” desktop environment like Unity8 and a tiling window manager.

  6. If Wayland becomes the new SystemD we need Mir as an alternative and Canonical should not give up on it like they did wirh upstart and Unity.

  7. 1) People make a lot of fuss about what wayland can do and mir not or vice versa. But in fact both can’t do much that X can’t, while lot of stuff that X can can’t really be done now with mir/wayland. In the end no user cares about the protocol, only about what you can do and what you can’t do.
    2) I like Kubuntu better than Ubuntu, it will never work with mir and doesn’t really work in a useful way now with wayland. It does work great with compositing on new hardware and also great with old slow hardware with xrender.

    But…

    where are the phones?

    Who can say Mark made a bad decision when there are phones and a tablet running Ubuntu? I have one, and it really is good. I will be really sorry when it dies and I am forced to go back to Android.

    To me it seems a lot has been achieved and some has failed. But let’s not forget that a market succes requires a perfect product and that is a rare thing to achieve in one try.

    So, thanks Alan and thanks Mark, I wish you all succes the second time around.

    1. 1. X can’t provide separation of applications (unless you go QubesOS-style way, that is pretty hard). That’s a security dealbreaker for me.

  8. I really hope Mir would still be widely available – on Ubuntu and beyond. It seems to me that all the problems around Mir stack were always managerial and never technical. Which is actually a bad thing in a way – technical problems can be acknowledged and fixed, no big deal… but to make managers acknowledge their own stupidity and, for a change, do something useful – that would be challenging.

  9. Alan, thank you for your great work! Mir maid Wayland improve a lot. So, even if Wayland and Mir are now close in features, competition is vital for progress and will make things even better. Now, as Mir and Unity8 are no longer under Canonical management, I really hope a community will build around them to continue the development.

    IMO the ex-developers of Canonical should team up with other people like UBports & Yunit, define a direction for both projects and continue the development. People from UBports & Yunit are analyzing both projects now and need assistance from those who developed them to better understand the bigger picture and the motivations behind each concept.

    What I would really like to see is for the convergence dream finally to come true and for both projects to become independent of Ubuntu. It would be great to run them on other GNU/Linux distros and *BSD too.

    1. “the ex-developers of Canonical should team up with other people…”

      The ex developers of Canonical are people that have just lost their jobs. However much they would like to be able to contribute to these efforts they will have much higher priorities in their lives.

Comments are closed.