Mir For Everyone

Earlier today Mark Shuttleworth blogged about the evolution of Mir, the powerful display server we are building as one component in the Ubuntu convergence story across desktops, phones, tablets, and more, but also as a general purpose display server that other distributions, desktops, and other upstreams can use too.

Mir will be landing by default in Ubuntu 13.10 with the XMir compatability layer to ensure we can continue to ship our existing Unity codebase and to ensure that any and all other distributions can ship their desktops too. This will be the first major distribution to ship a next-generation display server, not only on a desktop, but also on phones and tablets too.

I recommend you read Mark’s post in full, but I want to highlight this piece in particular:

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.

In a nutshell, we are passionate about encouraging not only Ubuntu flavors, but all distributions (either Ubuntu-derived or not) to be able to harness Mir as a powerful next-generation display server for either shipping their X desktop with XMir or harnessing Mir directly. From 13.10 onwards we will have a production-stable, fully supported Mir ready for everyone to use.

To put it clearly: while Mir will serve the needs of Unity well across a range of devices, it is not only intended for Unity, it is intended to serve other environments across a range of devices too.

Last week I reached out to most of our flavors to discuss this work (and discuss many related topics with the Mir engineers), and these discussions are continuing this week. I have also been in touch with some other distributions to discuss Mir support. Obviously we will be working closely with Debian to help get Mir in the Debian archives too.

Mir is Free Software (get the code or test from a PPA), discussed openly on mir-devel (see the archive), and we provide weekly updates from Kevin Gunn, Mir Engineering Manager every Tuesday at 5pm UTC on Ubuntu On Air. We are also refining our documentation to help folks write clients (see the API, the sample client, and other documentation). If you have any other questions about adding Mir support, feel free to get in touch with the Mir team on mir-devel.

tl;dr: the Mir team are very open to discussing the needs of upstreams and distributions. Get in touch on mir-devel or feel free to send me an email and I will put you in touch with the right person.

  • Jef Spaleta

    The bug report https://bugs.launchpad.net/mir/+bug/1193261 has moved from medium to low to wishlist in the span of 2 weeks. This does not inspire confidence in any statement from anyone inside the Canonical fenceline concerning the desire to see Mir established as a generally useful bit of tech. The necessary custom mesa and xorg codebases are still not documented as part of the build from source instructions at unity.ubuntu.com/mir. These instructions still refer only to the PPA. And the bug tracking this issue has been de-prioritized down to wishlist. Not what I expected to see when I was encouraged to engage on this.

    Sorry Jono, I can’t take the stated desired to really see Mir as a vendor neutral tech seriously until the build from source instructions are documented correctly to include the branches for the custom xorg and mesa with the enablement patchset.

    This is sort of important. Building from source is the primary way external developers get comfortable with the code, doubly so for distribution packagers. The continued lack of documented instructions on which specific patched xserver and xorg to grab stands in contrast to the statements being made concerning the desire to see Mir getting picked up. If it really was an important desire, the instructions would be updated by now. Instead the bug report is downgraded, and the discussion in the mailing list lingers and lingers with no documentation correction. In the meantime the docs have been updated to point to a different ppa. Not cool.

    And those patches really need to be discussed with upstream xorg and mesa for serious consideration for mergability. I seriously doubt other distributions are going to choose to pick up those Mir enablement patches for xserver or mesa directly from Ubuntu packaging. I’m pretty sure Fedora is not going to touch them until they are upstreamed into mesa and xorg. And I very much doubt Debian will either. So what’s the timeline on those patchsets being merged? Is that a post 13.10 release activity?

    Why are we bothering even discussing “other distributions” when you and Mark both know that other distributions are looking for these patches to be upstreamed back into the mesa and xorg codebases? You are putting the cart significantly ahead of the horse with the discussion of “other distributions”. These patches are the equivalent of mutagenic biohazard until they are on a path towards inclusion in the upstream mesa and xorg mainline development tip.

    First make it possible for individuals to build and testing Mir from source. Then get the xorg and mesa patches upstream Then and only then is it really appropriate to even think about other distributions packaging Mir and Unity8 up.

  • Adrian Wechner

    Months ago there was a series of articles about reasons etc for the development of mir. That was very interesting. Will be soon a new series with more technical insights?

  • http://metin2wiki.ru CSRedRat

    Great message!

  • Michael Galyuk

    A lot of people many years are waiting nimble desktop on linux. You do a great job, guys! Only creative people, like you, move free software forward. Any types of destructors (critics, analysts, trolls, sceptics) cannot help community to create something useful. Don’t pay attention to scepticism. Just do what you planned!

  • http://metin2wiki.ru CSRedRat

    I hope, Canonical to respond to it with business. Real projects, developers and distribution kits which already supported who already joined development.

  • Anonymous

    Jef, I know we have some teething issues, this is par for the course with new projects, and I have raised these with the Mir team. They assure me they will respond to you to move this along soon. Thanks for the feedback.

  • Thomas Voß

    Hey Jef, thanks for pointing out that the discussion stalled. I bumped the priority of the bug to medium again and will work with the team to update the build instructions to include pointers to the Mesa and Xorg branches. However, to get started with building Mir, both the patched Mesa and Xorg are not required and Mir’s build-time test suite works without them. Did you have a chance to try to build Mir in this isolated scenario?

  • Jef Spaleta

    I have. Not bloody useful really though..right. And NOT the documented test instructions on the webpages. Either I get unity8 up with native mir support..which I still need the mesa patches for at a minimum….and the xmir patches for to run any useful application outside of unity8 itself. Or I get xmir up and running with twm as a starting point..which is a much lower bar.

  • Jef Spaleta

    And I want to be clear. If Mir was just going to be rolled out for use under Unity8 and Xmir under Unity7 in 13.10… then rolling out an on-ramp for externals wouldn’t be such a big deal.

    But the aggressive roadmap to have all the other DEs in the Ubuntu-the-project repository use Xmir has raised the profile of external developer needs a bit. (depending on the flavor media you originally installed. As in you install the default Ubuntu branded desktop media and then install KDE… you’ll be running KDE over xmir from a session defined in lightdm..as my current understanding of how this is going to work)

    And now the glowing statments from both you and Mark… people external to the Mir development, concerning Mir’s wide applicability as a piece of tech raises the external developer needs.

    Look, I don’t see any of the active Mir codebase contributors chearleading about Mir being anywhere near ready for externals to chew on. I’ve gotten nothing but caution flags from the actual developers and team management who have called my bluff and actually took the time to respond to my requests and concerns to work with the source code. You and Mark are out of position on this. Its way too soon to be talking about Mir as an externally consumable. It’s way to soon to commit to putting xMir underneath any DE that is not Unity branded.

    All you are doing is setting expectations higher than can be achieved and creating a situation that will be frustration to externals. Every single external who trusts you personally, and take a way from this that Mir as a project is ready for teething by the wider community outside the Canonical fenceline. is going to disappointed with the current state of thing.

    Back off on the aggressive messaging concerning Mir’s suitability outside of Unity… its completely out of touch with the reality of the situation at present. The aggressive chearleading is only going to lead to externals attempting to work with Mir before Mir is ready to work with externals and your going to create a frustrating first impression for people. Back away from this, and focus on getting Mir to work for Unity8 and XMir to work with Unity7.. and come back to the issue of external uptake after the mir enablement patches have been submitted and integrated into upstream xorg and mesa. Not before.

    -jef

  • Thomas Voß

    Sure, not useful but at least a checkpoint. +1 on XMir + twm, I will prepare the respective bits of documentation. Again, sorry for letting this linger.

  • Jef Spaleta

    and get those blasted patches on a trajectory to being upstreamed. Watching Mark talk about the glory of a 600+ line xorg mir enablement patch buried inside a ppa tarball on his blog required me to do 4 face palms. This is just arse-backwards. If the patch is ready to commit to in inflicting on your…dare I say… dozens if not hundreds of active Ubuntu users in the wild on 13.10 release day (I could be over estimating that number really hard to get accurate numbers on users)… then this patch needs to be on a trajectory into an xorg upstream release well before that point.

    Having Mark talk about downstream patches so publicly ahead of any upstream patch submission request only highlights the fact that there’s been no upstream submission yet. Either these patches are ready and the team is confident in them being made part of upstream, or they aren’t confident in them yet…and if so… Mark did you a huge disservice by talking out of turn and raising the profile on the patchset.

    Again this is only important in the context of the expectations have for externals to have to deal with Mir. If Ubuntu backs off on the aggressive roadmap and moves to a plan to dogfood Mir/Xmir for only Unity8/Unity7 and leaves all other DE sessions to xorg…the pressure to give externals dogfoodable Mir and to drive dogfoodable Mir into other distributions is exponentially reduced in the priority list of crap the Mir team has to deal with in the short term.

    I personally would much rather see the Mir team figure out a commitment to a tarball release cadence, and with mir enablement patches committed into at least an experiemental branch in the official upstream projects before anyone talks seriously about external distribution uptake or any non Unity branded DE is expected to run ontop of xmir by default (user opt-in would be appropriate).

  • Anonymous

    Jef, we are trying to help, please dial down the tone of your feedback. We don’t need 500 lines of angry rhetoric, we need to focus on solving the problems you highlight.

  • Jef Spaleta

    Then solve them. This post does not solve them. Mark’s post does not solve them. These blog post imply a state of affairs that do not yet exist. Mir is not ready for everyone…yet. I’m here reminding everyone that the on-ramp for externals does not exist…yet. Squeeky wheel and all that. It’s actually a little bit insulting to see these posts so blithely ignore the fact that the build from source instructions haven’t been fixed when I know you know this was on the map as part of the on-ramp building for externals. Mark may not know, but you know better.. you know the score.

    If the Mir team needs more time to solve the problems for external on-ramping, I’m okay wit that. I don’t blame them for this post or Mark’s posts intimating that Mir is ready for externals. You both have jumped the gun with the socialization of Mir as a viable upstream vendor neutral project. Shame on you both. I do not fault the Mir development team for over-stating the situation. This is a management failure. So caught up in evangelizing corporate decision making that you’ve forgot to ground truth the battlefield. It happens. You are welcome to the reality check.

    I’m not even sure I can fault the Mir team for greenlight the rush to default status of Mir/Xmir in the 13.10 roadmap. Its a very bad decision for external DE project developers who do their primarily development, testing and bug triage on non-Ubuntu Saucy ssystems and who are going to be blindsided by any potential regressions in how xmir operates. But that decision makes having an on-ramp for external developers an imperative now to reduce the impedance mismatch between Ubuntu distribution policy and upstream development. So while I cannot fault the Mir development team for the Ubuntu distribution decision to commit to unreleased graphics stack tech… the Mir team is the only group who can address the problem created by that decision.

  • Michael Hall

    All DE sessions except Unity 8 will be running on Xorg’s X server. The only difference will be whether they use a normal device driver or the XMir driver that will route the drawing through the Mir system compositor.

  • Jef Spaleta

    Oh is that not what I said? I’m pretty sure that’s exactly what I said. But to be as clear as I possibly can on this. Defaulting any DE session to run on top of “the xmir driver that will route through the Mir system compositor without” without buy-in from the upstream developers for that particular DE as a tenatively supported configuration is pre-mature and damaging to interproject relations and damages the enduser upstream project communication flow. The only DEs at this point which I’ve seen buy-in from are Unity8 and Unity7. Those are the only DEs which should be run on top of the mir/xmir stack by default in 13.10 no matter which DM is used to manage available DE logins. Everything other DE should be a user opt-in to run ontop of the xmir “driver”

    You can moderately mitigate that damage by making it possible for those external developers to get Mir/Xmir environments up and running in their normal development environments (ie not Ubuntu Saucy) by including accurate instructions for building a working Mir/Xmir configuration residing in /usr/local that is parallel installable with the xorg and mesa they normally run.

    You can further mitigate the damage by making it possible for distribution packagers to provide Mir/Xmir as part of distribution packaging for those environments that upstream DE devs normally use right now as part of their workflow (ie not Ubuntu Saucy), without requiring any vendor patching.

    The sooner these things are done, the sooner external developers can dogfood an Mir/Xmir setup underneath their DE and become comfortable enough with it to at least help triage end-user bugs that bubble up with Xmir related regressions. A flood of bugreports for regressions that can only be produced on Mir/Xmir in 13.10 with no way to reproduce in a Mir/Xmir setup in another environment is going to piss upstream dev teams off. This can be mitigated.

  • Michael Hall

    I’m not sure we ever had to get buy-in from a DE to use any other Xorg driver by default. We should do that with our flavor leads though.

  • https://www.happyassassin.net/ AdamW

    “This will be the first major distribution to ship a next-generation display server”

    Well no, it won’t, not even close. I think you meant to write “by default” (using a compatibility layer, as you noted).

  • Thomas Voß

    We updated the documentation to include references to the MESA, X and X driver patches in this revision http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/842, changes have propagated through to http://unity.ubuntu.com/mir/building_source_for_pc.html. Strictly speaking, the XMir/system compositor documentation should live in its own subsection as it continues to grow, tracking that issue here: https://bugs.launchpad.net/mir/+bug/1200114.

  • Jef Spaleta

    thank you. Mid-week next week as soon as I get back from my near off-the-grid work trip I’ll work my way through the instructions.

  • Jef Spaleta

    Michael, non-upstreamed patches to xorg itself. Mir enablement is not just sliding in another peer driver that looks and tastes like the intel driver or the radeon driver. A Mir enablement patch is required that break your simplistic mental model. If it was just another driver… I wouldn’t need to a custom xorg server… I’d just need another driver. Yeesh man…pay attention to the specifics just a little..sometimes.