The state of XMir

[mjg59]

XMir's been delayed from Ubuntu 13.10. The stated reason is that multi-monitor support isn't sufficiently reliable. That's true, but it's far from the only problem that XMir still has:

• It's still broken on some single-monitor systems

Some machines have display corruption. There are writes to freed memory. To be fair, some of the behaviour that's been seen has been down to underlying bugs in the Xorg drivers that were never triggered under normal use but are hit by XMir. Others are down to implicit assumptions made in the drivers that XMir happens to violate. The problem is that there doesn't appear to have been enough room in the schedule to deal with these interactions, presumably because nobody accounted for the inevitable "This thing we thought would be easy turns out to be difficult" part of the project.


• The input driver bug still isn't really fixed

I've mentioned this bug before. It's now marked "Fix released" which is kind of true but not really. Mir now tells XMir that the VT is changing before the VT is changed, but it doesn't wait for that to complete before switching the VTs. Until XMir is scheduled and runs, it's still receiving input events. In most circumstances that window is small, so there's no real risk of triggering it accidentally.

There's one corner case where it might still cause problems. Simply running isn't enough - XMir has to make progress through its event loop. That'll only happen if the X server is processing its wakeup events, and it's possible to effectively stall that by submitting a sufficiently awkward drawing request to the server. The X server will appear to freeze, and if the user then attempts to work out what's going on by switching to a VT and logging in, those input events will still be going to XMir. It's left as an exercise to the reader to construct ways to take advantage of this.

This can't happen in Xorg because the VT switch is blocked until the input devices have been released. Mir could have done the same, but doesn't because of a conscious design decision - in the Ubuntu Phone world, clients stop doing things when they're told to. Ubuntu Desktop is expected to behave the same way.

This is an unfortunate situation to be in. Ubuntu Desktop was told that they were switching to XMir, but Mir development seems to be driven primarily by the needs of Ubuntu Phone. XMir has to do things that no other Mir client will ever cope with, and unless Mir development takes that into account it's inevitably going to suffer breakage like this. Canonical management needs to resolve this if there's any hope of ever shipping XMir as the default desktop environment.


• It's still missing features

XMir doesn't support colour profiles. XRandR properties aren't exposed, so there's no way to control TV output encoding or overscan. There's still no hardware cursor support. Switching to XMir now would reduce functionality without providing any user-visible gain.

It's clear that XMir has turned into a larger project than Canonical had originally anticipated, but that's hardly surprising. There's only one developer with previous X experience working on it full-time, and the announced schedule provided no opportunity to deal with unexpected problems. As if that weren't enough, there's obvious conflict between Ubuntu Desktop and Ubuntu Phone when it comes to developer time and required functionality. The one hardware vendor who's willing to take a public stand has demonstrated that they have no interest in supporting XMir, despite Canonical assuring people that they were already engaging in productive negotiations with GPU manufacturers.

Multiple monitor support may be the single most obvious feature where XMir is lacking, but it's not the only one. Technically and politically, this code is a long way from being ready for prime time. Without significant community contribution, Canonical need to focus on prioritising it appropriately rather than expecting a tiny number of developers to perform miracles. Or, alternatively, they could just drop XMir entirely and focus on Unity 8.

Comments

No showstoppers

[(Anonymous)]

Nice list of bugs, but none of those look like showstoppers for a non-lts release of Ubuntu.

[(Anonymous)]

http://planet.debian.org/deriv/

Use Planet Debian Derivatives and stop polluting Planet Debian with butnut crap!

Manpower

[(Anonymous)]

Do you think Canonical has the manpower to maintain all of this on their own? I mean, I don't think even Red Hat would undertake this daunting task alone, and Canonical acts as if they'll pull it off with no problems.

Delays? At Canonical?

[(Anonymous)]

Sticking to a schedule was never one of Canonical's strengths. As they shed employees and move further away from Red Hat's software stack, the schedules will only slip more and more.

Security is relative, and short-term user-visible benefit was prolly never the point

[(Anonymous)]

While I guess I agree that there is still a race-condition, which could theoretically someday maybe lead to some sort of exploit, as you point out there is now only a vanishingly small chance that some everyday endusers will accidentally reveal their username and password to IRC or Skype. Although it was a reasonably-serious bug before, that deserved a big red warning on the package, I'm pretty confident that necessity is now well in the past. You point to Xorg as the epitome of secure input handling? And yet, Jamie Zawinski has all my passwords stored away in his underground bunker. http://www.jwz.org/xscreensaver/faq.html#setuid Furthermore, Xorg itself has problems with securing VT sessions -- http://www.jwz.org/xscreensaver/faq.html#no-ctl-alt-bs

Point being, it seems like Mir is at least *level* with the security provided by X, if not ahead. At the risk of sounding like the guy responsible for WinME, security *is* actually relative.

p.s. My other point is short and sweet: getting parts of Mir into 13.10 as the default was never about providing *immediate* user-visible benefits. And although I would agree it was at least partly a publicity stunt, to generate buzz, and get out the gate faster than Wayland, I definitely think that was a secondary or tertiary goal. The number one primary goal was UbuntuPhone deals, which may have been accomplished (we'll know based on whether you can buy one before December 25th). But the big desktop goal was to put the Mir codebase through the gauntlet, of getting real-world beta testing by millions of users on all kinds of nutty hardware. That would make pushing Mir into 14.04 LTS *much* more palatable, even if it was non-default in the LTS flavor. So the big loss for endusers is not that they are missing out on some hypothetical cool feature in 13.10 -- it is that Mir will not be as battle-tested when 14.04 comes around. Long-term benefit was always the key here.

[(Anonymous)]

Nice "fedora" tag :P

A radical sugestion: create a xlib driveless compatibility layer from scratch

[(Anonymous)]

I have a more radical sugestion for legacy X support, more due to the experience from the X11 server built from scratch for Android tablets, which was written in Dalvik Java and SurfaceFliger API, and it's driveless, that's mean it don't need any Xorg drivers to work.
The main backwards is the reduced compatibility with window toolkits, and some advanced X engines like Compiz would not be compatible at all.
In real word use, the X emulator for Android was used to the unofficial port of OpenOffice for Android.

Instead to load a full X server in top of other graphic server, with all legacy stuff loaded, why not use the new Mir API directly and write a X11 driveless pseudo-server from stratch to start the X programs ?
That's my fair opinion, and I think is the most stable option to legacy programs.
For more information, I share the project homepage:
http://code.google.com/p/android-xserver/