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

Link to where mir's vt-switching is being designed

[(Anonymous)]

Your position sounds reasonable to me, overall. I disagree, however, because I don't want a system that is exactly what an old-school person like ourselves expects from rm. Instead, I want the automagical versioned backup filesystem (amvbfs?) in which rm does not actually free any space, does not actually delete any data, but really just adds a new zero-byte version-of-a-file on top of the stack of existing versions-of-that-file. I also want certain system-level utilities (I'm particularly thinking of /sbin/undelete at the moment) that will survive rm rf of the entire drive. Now, as an old-school person, that behavior is *definitely* not like what I would expect, from my previous work with rm, but it *is* pretty close to what I would really want.

As for XMir and VT, our expectations are similar, and our analysis is similar... where we differ is that it sounds like you want XMir to be finished now, and I think XMir is still very much in beta and thus fluid. In other words, it is still under heavy development, and until 13.10 has been debugged, and the final kinks worked out for what ships with 14.04, I'm reserving judgement on whether Mir/Xmir are going to offer something relatively (to Xorg) secure speedy stable shiny useful intuitive et cetera. Here is the blog of one of the mir/xmir folks that is particularly interested in fixing up terminal-switching. https://dvdhrm.wordpress.com/ See particularly the Sane Session-Switching and the How VT-switching Works. Do you see serious problems with what he's talking about in those, security or otherwise? That's where mir&xmir are heading, from what I can grok, which is *not* necessarily the same thing as where the beta release-early-release-often codebase actually is right now.

The 'racy one' used now is just a prophylactic, to prevent 99.9% of security-pregnancies. If you are in one of those 0.1% situations that you describe, where firefox is hanging up X, and you think you might have left your cursor-focus in an IM chat window, the workaround is to unplug your LAN cable (or use Fn+F12 or somesuch to power off your wifi). But be fair here: 99.9% of the time, the racy band-aid keeps the typical enduser from shooting themselves in the foot. That's good enough for beta stuff, which is what Mir is, really. If they *keep* using the racy band-aid indefinitely, then I agree that's not a Good Thing, but that remains to be seen.