[personal profile] mjg59
Mir is Canonical's new display server. It fulfils a broadly similar role to Wayland and Android's Surfaceflinger, in that it takes final responsibility for getting pixels onto the screen. XMir is an X server that runs on top of Mir. It permits applications that know how to speak the X protocol but don't know how to speak to Mir (ie, approximately all of them at present) to run in a Mir-based environment.

For Ubuntu 13.10, Canonical are proposing to use Mir by default. This doesn't mean that most applications will be using Mir, though - instead, the default session will run XMir as a full-screen client and a normal X environment will be run on that. This lets Canonical deploy Mir without forcing anyone to update their applications, allowing them to take a gradual approach. By 14.10, Canonical expect the default Unity session to be a Mir client rather than an X client. In theory it will then be possible to run an Ubuntu system without any X applications at all, leaving XMir to do nothing other than run legacy applications.

Of course, this requires a certain amount of replumbing. X would normally be responsible for doing things like setting up the screen and pushing the pixels out to the hardware, but this is now handled by Mir instead. Where a native X server would allocate a framebuffer in video memory and render into it, XMir asks Mir for a window corresponding to the size of the screen and renders into that and then simply asks Mir to display it. This step is actually more interesting than it sounds.

Unless you're willing to throw lots of CPU at them, unaccelerated graphics are slow. Even if you are, you're going to end up consuming more power for the same performance, so XMir would be impractical if it didn't provide access to accelerated hardware graphics functions. It makes use of the existing Xorg accelerated X drivers to do this, which is as simple as telling the drivers to render into the window that XMir requested from Mir rather than into the video framebuffer directly. In other words, when displaying through XMir, you're using exactly the same display driver stack as you would be if you were using Xorg. In theory you'd expect identical performance - in practice there's a 10-20% performance hit right now, but that's being actively worked on. Fullscreen 3D apps will also currently take a hit due to there being no support for skipping compositing, which is being fixed. XMir should certainly be capable of performing around as well as native X, but there's no reason for it to be any faster.

The output drivers aren't the only part of the stack. XMir still needs some way to get input events. You might naively expect that Mir would forward input events to XMir, but the current state of affairs is that XMir loads the existing X input drivers which in turn open the input devices themselves. This explains why XMir currently shows two cursors[1] - the first cursor is the Mir cursor that's being driven by the input events Mir is receiving, while the second is the cursor being drawn by XMir in response to the input events that it's receiving[2].

The final main piece of duplicated functionality is output management. In the case where X is its own display server, it can simply ask the kernel to program the outputs. XMir can't do that, so would have to ask Mir to do it instead. Sadly, that functionality's not implemented yet. Running xrandr on Xmir gives:
Screen 0: minimum 320 x 320, current 1366 x 768, maximum 8192 x 8192
XMIR-1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   XMIR mode of death[3]   60.0*+
which translates as "I have a screen that can be any size from 320x320 to 8192x8192, and have one output of unknown physical size that can only display 1366x768 at 60Hz". Other than the 1366x768, the result will be identical no matter how many outputs you have - XMir currently has no support for configuring multiple displays, and will always report 60Hz. It also has no support for placing monitors into any kind of DPMS state.

Obviously, this is still software under active development. There's three months from now until until Ubuntu is due to release with this functionality enabled by default, and the only significant missing features are xrandr and DPMS support. As long as Mir exposes interfaces for controlling those, they shouldn't be a problem to implement. To most users, the transition from native Xorg to XMir should be completely invisible.

Which is kind of the problem. What benefits does the user gain from using XMir on Mir rather than native Xorg?

Features? XMir is a total of around 1000 lines of code on top of Xorg. It implements no functionality that isn't present in Xorg.

Performance? XMir effectively is Xorg - it's the same code running the same drivers. It's not going to be any faster. At the moment it's actually slower, but that's probably fixable.

Security? Again, XMir is effectively Xorg. It still runs as root. It has the same privileges. There's no security benefit to using XMir instead of Xorg.

Like I said, the transition should be completely invisible - no drawbacks, but no benefits. What it does do is get Mir deployed on a larger number of systems, which means Canonical can both get wider testing of the basic Mir functionality and argue that the number of deployed Mir systems means hardware vendors should support it. Users won't see any of the benefits until Unity transitions to being a native Mir client, which is slated for 14.10 next year.

As a PR move, it's pretty great. The public perception is that Mir has gone from not existing to being sufficient to run a full desktop environment in very little time, and it's natural to compare it to Wayland which has been in development for longer and still isn't running a fully featured desktop session. The problem with that perception is that Mir is doing very little at the moment. It's setting an output mode (by asking the kernel to), allocating a window for XMir to draw into and then pushing that window onto the screen whenever XMir tells it that it's changed. This isn't advanced display server functionality, it's the bare minimum that a display server could possibly do[4]. Which is a shame, because Mir is significantly more functional than that, it's just not being used to do anything we couldn't already do.

In summary: XMir on Mir in Ubuntu provides no user benefits and isn't a compelling technology demo. Mir itself will permit a range of additional features, but isn't slated to be running a user session itself until 14.10. The only obvious benefit to Canonical in shipping XMir on Mir is to gain additional testing, which makes using it in 14.04, a supposedly stable and long term release, a somewhat surprising choice.

[1] Although this is in the process of being fixed
[2] This also explains why, on systems with a trackpoint and a touchpad, only the trackpoint moves the Mir cursor while both move the XMir cursor. The X touchpad driver has put the touchpad in absolute mode, which means it's now reporting events that Mir currently ignores.
[3] "XMIR mode of death" is hardcoded into XMir. I'm really hoping it's a Regular Show reference.
[4] So why hasn't anyone done this with Wayland? Mostly because, as described above, there's no technical benefit in doing so. Wayland does have an X server for compatibility purposes, and if you wanted you could run it as a full screen client and run an entire session underneath it. But you'd gain nothing by doing so. The Wayland X server is intended for running individual clients rather than an entire X session. Run an X client under Wayland and it'll pop up in its own individual window and managed by your Wayland session's window manager, just like it would under X. XMir currently has no support for this "rootless" mode - right now if you want to run X apps under Mir, you'll need to launch an entire X session with its own window manager.


Date: 2013-07-15 05:47 pm (UTC)
From: (Anonymous)
I read this as being slightly depressing news. I had assume XMir was substantially cleverer than that, but in fact it seems that many of the really hard problems haven't yet been touched.

I also assumed that this was a big hurry to make an LTS release, which is 14.04(?). But there doesn't seem to be a way that they will be Mir-native by then, and does it really make sense to support some version of this Frankenstack for five years?! Blimey.

Re: ouch....

Date: 2013-07-15 07:08 pm (UTC)
From: (Anonymous)
do you think you can be x11-free on desktop _soon_ (while mantaining productivity)? I don't

so, well, x11 for 3 or 5 more years, whichever fits LTS best, looks good to me

Re: ouch....

Date: 2013-07-15 07:54 pm (UTC)
From: (Anonymous)
Well, Mark Shuttleworth announced that Wayland was the future for Ubuntu in Nov '10. 2.5 years of development would certainly have got them further than where they are right now.

I had just assumed the one thing that Mir would buy them would be the ability to move faster than everyone else. Right now I'd bet native Wayland distros appear well before native Mir. I just don't get the point of why they've done it.

Re: ouch....

Date: 2013-07-15 09:41 pm (UTC)
From: (Anonymous)
The Licensing model for Mir is different than wayland. The way Canonical has set up the licensing puts them in a pretty good position when working with mobile device manufacturers when it comes to creating locked down images. Canonical can spin up a special non-copyleft license for Mir which locks that device manufacturer into contracting with Canonical for further enhancements. Strategic benefit to Canonical, but not a technical benefit to anyone. But that's the sort of tradeoff you make in the business world. Best tech doesn't always sustain a business. Adequate tech, with an adequate business model behind it that fits the market does.

Re: ouch....

Date: 2013-07-16 07:58 am (UTC)
From: (Anonymous)
Sure, but right now they're playing uber-catchup. Android, iOS have been shipping for *ages*. Windows and Blackberry are shipping, although no-one much cares about it. FirefoxOS is shipping on actual hardware. Even Jolla have a ship date. Ubuntu is vaporware in the mobile market: nothing is shipping, nothing is ready, and the best date we have is "2014 sometime". They have a Carrier Advisory Group (aka talking shop) and an OS which is "dogfoodable" (aka alpha quality) on a couple of devices.

Canonical may have a wonderful super-special licensing position, but the obvious question to ask is, "Who cares?". Why is someone going to pick Android-based Ubuntu when they can just write their own Android skin? Is Ubuntu One really going to sell it?

I think 2014/15 are going to be sad years for Canonical. All this "convergence" tech will have to be released at some point, and then we'll see what the market makes of it.

Re: ouch....

Date: 2013-07-16 04:59 pm (UTC)
From: (Anonymous)
Yes they are playing catch up. I think they realize that... now. It's unfortunately they didn't realize this the first year they want to Computex to show off nascent Ubuntu for ARM, and had their thunder entirely stolen by functional Android demos.

I believe the way Android rolled in and gobbled up ODM mindshare was an outright shock to the company, but they didn't recognize what it meant soon enough, and when they did they took away the wrong lesson. The focused on making absolutely fantastic non-functional demo to capture buzz to steal the thunder from the likes of FirefoxOS. Not that it matters, firefoxOS has shipping hardware and is going for an underserved commodity phone market where Android and iOS are not focused. FirefoxOS is growing the smartphone market to some extent for people who don't need top of the line phones. So Canonical's big splash doesn't really hurt FireFoxOS at all in the long run. Canonical is aiming to displace Android, on high end devices and that's far riskier.

So this time around, the led the push into mobile with their non-usable touch demo interface running on top of Android core to turn heads at the MWC, and now have to scramble to backfill in the actual working technology they can build a business around. The learned the wrong lesson. Mir isn't even the biggest risk, strategically. Their reuse/abuse of deb packaging to build their next-gent "click" packages for their mobile "app" system is going to be a much bigger problem for them. Mir is just a sideshow that is draining engineering resources for them.

Canonical is absolutely a minimum of a full year away from beta testing a mobile solution that can be competitive in the marketplace. And until I see an unlocked developer handset or tablet show up with U* anything pre-installed, then its impossible to consider them a serious contender in the consumer device space.... no matter how much talk and engineering effort is expended to polish the software. If they can't make the leap to pre-installed devphone hardware they are not a not even on the battlefield.

Re: ouch....

Date: 2013-07-15 10:16 pm (UTC)
From: (Anonymous)
So how much development did Canonical put into Wayland?

Re: ouch....

Date: 2013-07-15 10:33 pm (UTC)
From: (Anonymous)
Virtually nothing. They posted couple small patches over a year ago.

Re: ouch....

Date: 2013-07-16 02:34 pm (UTC)
From: (Anonymous)
Quote: "Well, Mark Shuttleworth announced that Wayland was the future for Ubuntu in Nov '10. 2.5 years of development would certainly have got them further than where they are right now."

I'd say it's a fair question. But I wouldn't say your response was. I would even say that it lacks the least bit of decency.

Re: ouch....

Date: 2013-07-16 02:36 pm (UTC)
From: (Anonymous)
Note: That was meant as response to this:

Re: ouch....

Date: 2013-07-16 11:21 am (UTC)
From: (Anonymous)
Why does that matter. The question isn't even on topic with this blog. Do you need rehab? Get the help you need man.

Re: ouch....

Date: 2013-07-16 08:52 am (UTC)
From: (Anonymous)
> I had assume XMir was substantially cleverer than that, but in fact it seems
> that many of the really hard problems haven't yet been touched

I think that is known as 'doing an Ubuntu', no?

wayland on jolla

Date: 2013-07-15 07:31 pm (UTC)
From: (Anonymous)
So I assume this is the same approach jolla is taking for their new phone?


Re: wayland on jolla

Date: 2013-07-15 10:32 pm (UTC)
From: (Anonymous)
They use lipstick as Wayland compositor without even having XWayland support. Everything is native.


Date: 2013-07-15 08:12 pm (UTC)
From: (Anonymous)
Let's not forget that Mir acts as a system compositor in Ubuntu. This does one important thing: it allows them to get rid of VT switching, which is ugly and problematic. Here's a very good article on system compositors and VTs: http://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-system-compositors/

From the end user standpoint, if you've gained a system compositor, LightDM can now be used as lock screen, user/session switching is much smoother and you can now run several concurrent sessions in multi-head setups.

P.S. this blog doesn't work with Launchpad OpenID for some reason. I'm https://launchpad.net/~shnatsel


Date: 2013-07-15 09:04 pm (UTC)
From: (Anonymous)
everyone posts as anon on mjg's blog. It's the tradition!

Date: 2013-07-15 09:03 pm (UTC)
From: (Anonymous)
Mir itself will permit a range of additional features, but isn't slated to be running a user session itself until 14.10.

This is scheduled for 14.04 with Unity 8. In fact 13.10 is planned to have an optional Unity 8 preview session included.

Date: 2013-07-16 02:07 pm (UTC)
From: (Anonymous)
That email says that the default option will be Unity 7 on XMir, but doesn't say anything about the presence or absence of a Unity 8 on Mir preview.
From: (Anonymous)
To my mind, the point of releasing Mir in 13.10 is very clear: not *just* the PR of being first-to-market versus Wayland (which like Hurd may now be seen as having the Endless Design syndrome), but more importantly, testing. One of the valid complaints that ubuntu made about wayland was that they preferred a test-driven-development model. Most folks, including me, would take that to mean the same thing as agile programming, i.e. you write the performance-testing-scripts first (which report zero fps at the beginning), and then as you get working code up and running, you already have instant feedback on how well the code works, ability to catch regressions, etc.

However, now I'm starting to think that's not what the ubuntu folks meant by "test-driven" development... they weren't talking about auto-QA regression tests, they were talking about in-the-wild *beta* tests. Ubuntu 14.04 LTS is going to have a full copy of Mir, and a full copy of Unity8, and a full copy of all the rest of the future-Ubuntu-graphics-stack.

They have to support that for five years... but recently, they've started doing *rolling* kernel release on the LTS stuff. Which means, 12.04 LTS came out with kernel 3.2, but later 12.10 came out with kernel 3.5, which was then 'backported' to be the new kernel for 12.04 LTS part deux. Basically, the LTS series will be getting kernel upgrades every six months, shortly after the non-LTS flavor has beta-tested that kernel in the wild.

I fully expect the same approach will apply to 14.04 -- it will get rolling kernel updates, and prolly rolling Mir updates, so that ubuntu need not maintain a "frankenstack". Now, whether rolling kernel upgrades to an LTS distro is a good idea or not remains to be seen -- RHEL/CentOS does not do that (it's their main selling point), although Oracle's downstream RHEL clone *does* seem to be doing the Ubuntu trick of rolling kernel upgrades.

As for graphics stacks, whether Mir's approach to release-early-release-often is able to beat Wayland also remains to be seen. But one thing is for sure: releasing Mir into 13.10 isn't just a PR move, it has real benefits for endusers. Just not the *13.10* endusers -- the downside of releasing Mir into 13.10 is that those endusers will prolly experience bugs and instabilities and whatnot. The upside, for the 14.04 and later endusers, is that Mir will have already gone through a six-month beta, so *their* experiences with Mir will be improved.

p.s. One last note: the crucial difference between Mir and Wayland, which remains to be determined, is how well and how fully they will get support from the proprietary GPU drivers. Not *just* the NVIDIA and AMD binary-blob stuff for the x86 desktops however.

More crucial methinks is the Mali/Tegra/PowerVR/Vivante/OMAP/BroadcomVideoCoreAkaRaspberryPi/etc for the tablet and phone markets, using ARM CPUs. Both the wayland and mir teams -- unfortunately to my mind -- are eagerly pursuing the binary-blob folks, with Wayland aiming more at the ARM stuff (Daniel Stone of the Wayland team has already been involved with a proprietary wayland port to Raspberry Pi), and with Mir seeming to be more interested in the desktop GPU vendors (their homepage explicitly states they are trying to get NVIDIA and AMD onboard with Mir... but also strongly hints they are pursuing ARM vendors, and says outright they want Mir to work with existing binary-blob drivers for Android).

Just when the Mesa9/gallium/radeon/r600/libdrm open-source drivers for the desktop were within striking distance of performance-parity (on 2011-era chipsets at least), too.... As the old fortune cookie curse says: may you live in interesting times.


Date: 2013-07-15 11:01 pm (UTC)
From: (Anonymous)
I kind of wonder how much testing benefit they actually get from this. Sure, in theory they're exercising Mir to help get the bugs out - but in practice, all they're really testing is the ability to handle pass-through to a full-screen X window, the kind of thing that's normally intended for getting the desktop and associated overheads out of the way for running games.

User-visible benefits

Date: 2013-07-16 05:37 am (UTC)
From: (Anonymous)
Actually, you do get some user-visible benefits from sticking a system compositor underneath an otherwise stock X session - you get the ability to do transitions on user-switch, and from bootsplash→greeter and session→logout without making you want to tear kittens apart with your bare hands.

Oh, and someone (ie: me) has done this with Wayland ☺ - https://github.com/RAOF/weston and https://github.com/RAOF/xserver/tree/xwayland-1.12.2

Kinda sucky that dreamwidth doesn't understand Launchpad OpenID urls ☹.

Re: User-visible benefits

Date: 2013-07-16 05:39 am (UTC)
From: (Anonymous)
Of course, it's not clear whether or not we'll have implemented any of that for 13.10, but we'll have the infrastructure!

Both xwayland and xmir feel smoother.

Date: 2013-07-16 12:27 pm (UTC)
From: (Anonymous)
xwayland matches performance with its straight up x.org or beats it.

wayland has client side allocation.
Mir has server side allocation.

There are already a livecd using weston running wayland weston and running x.org inside. So there is no reason to bench mir vs x.org alone. It should be benched against weston as well. So yes wayland is running a fully featured desktop session inside X11.

Both Mir and Wayland are at the same area of development.


Date: 2013-07-17 04:14 am (UTC)
From: (Anonymous)
XWayland (without my system-compositor-patches) only runs rootless; you can't run Unity (or GNOME Shell, or KWin, or…) inside XWayland - Weston is the X11 compositor and window manager in that case.

It's not possible to directly benchmark Weston+XWayland against unity-system-compositor+XMir.

Re: Both xwayland and xmir feel smoother.

Date: 2013-07-17 06:58 am (UTC)
From: (Anonymous)
wayland can have server side allocation as well when needed. Good with hardware overlays and the like; but on x86 clientside should be good or better - server side allocation forces a roundtrip.

Date: 2013-07-16 07:02 pm (UTC)
reddragdiva: (geek)
From: [personal profile] reddragdiva
Is there any news of how Kubuntu and Xubuntu plan to approach this?

Date: 2013-07-17 09:21 pm (UTC)
From: (Anonymous)
Well, hopefully Kubuntu will stick with shipping Xorg then, as there's no reason on earth to put their users through the pain an upset of a beta quality display driver...

Again... (remembering accelerated Intel drivers...)

Date: 2013-07-18 06:30 am (UTC)
From: (Anonymous)
Win ; http://blogs.kde.org/2013/06/26/kubuntu-wont-be-switching-mir-or-xmir


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags