Reverting a patch, at least one that isn't causing a bug or regression, is
often controversial. Normally, the patch has been technically vetted
before it was merged, so there is—or can be—a non-technical reason behind its
removal. That is the case with the recent reversion
of a patch
to add XMir support to the Intel video driver. As might be guessed,
rejecting support for the X compatibility layer of the Mir display server
resulted in a loud hue and cry—with conspiracy theories aplenty.
The patch adding support for XMir was merged into the xf86-video-intel
driver tree on
September 4 by maintainer Chris Wilson. That driver
is the user-space X.org code for supporting Intel GPUs; it is code that
developed and maintains. The commit message noted
that the XMir API had likely been frozen so support for the API was being
the driver. The patch consists of less than 300 lines of code, most of it
confined to a new sna_xmir.c file. Based on the commit and
message, Wilson clearly didn't see any reason not to merge the patch.
All of that changed sometime before the revert on September 7, which
also prompted the release of the 2.99.902
snapshot. In the NEWS file for the snapshot was the
We do not condone or support Canonical in the course of action they have
chosen, and will not carry XMir patches upstream.
There are a number of possible interpretations for that statement, but,
however it was meant, it
was certain to raise the ire of Canonical and/or Mir fans—and it did.
When asked about the removal of XMir support, Wilson pointed to Intel
management for answers. I
contacted Dirk Hohndel, CTO
of the Intel Open Source Technology Center, who answered the main question
at hand: Intel's "engineering team and the senior technical people made the decision that we needed to continue to focus
our efforts on X and Wayland", he said. It was a question of focus, he
said, "adding more targets to our QA and
validations needs, having to check more environments for regressions [...]
would require us to cut somewhere else".
So removing support for XMir was requested by Intel management, but
seemingly did not sit very well with Wilson. One suspects the
NEWS file entry did not get approved, for example. But it's hard
to see that any reversion (or outright rejection) of the XMir support would
have led to a different outcome. Ubuntu has a legion of fans, who can
often be quite vocal when they believe their distribution is being treated
Michael Hall, a Canonical employee on the Community team, obliquely
referenced the XMir removal in a post to Google+: "You will
your open source project better by pulling another open source project
The argument that Hall and others make is that because Intel supports
Wayland, it is hamstringing Mir by
removing support for it,
and, in effect, helping to
keep Mir as a
single-distribution display server. "This
just strikes me as trying to win the race by tripping the competition, not
by running faster", Hall said in the comments.
But accepting any code into a codebase you maintain is a burden at some
level. Supporting a new component, like a display server, also requires a
certain amount of testing. All of those things need to be weighed before
taking on that maintenance. As Matthew Garrett put it (also in the
comments to Hall's post):
Intel commit to supporting the code that they ship, even if that would
require them to write or fix large amounts of code to keep it
working. Keeping the XMir code comes at a cost to Intel with (at present)
zero benefit to Intel. As long as XMir is a single-distribution solution,
it's unsurprising that they'd want to leave that up to the distribution.
Certainly Canonical can continue to carry the XMir patches for the Intel
video driver. It is, after all, carrying its own display server code in
addition to its Unity user interface and various other Ubuntu-specific
components. But Hall sees the "single-distribution solution" as a
Upstream won't take patches because other distros don't use it. Other
distros don't use it because other DE's don't use it. Other DE's don't use
it because it requires upstream patches that haven't been accepted.
Upstream won't accept the patches because other distros don't use it.
Since its initial attempt—with less than
stellar results—Canonical has not really tried to make any kind of
compelling technical arguments about Mir's superiority
or why any other
distribution (or desktop environment) would want to spend time working on
it (as opposed to, say, Wayland). The whole idea is to have a display
server that serves Unity's needs
and will run on multiple form factors in a time frame that Canonical
requires. That's not much of an argument for other projects to jump
As Garrett points out, Canonical has instead chosen the route of
"winning in the market", which is going to require that it
shoulder most or all of the burden until that win becomes apparent.
Casting the rejection of XMir as an attack of some kind is not sensible,
Refusing to adopt code that doesn't benefit your project in any way isn't a
hostile act, any more than Canonical's refusal to adopt code that permitted
moving the Unity launcher was a hostile act or upstream Linux's refusal to
adopt the Android wakelock code was a hostile act. In all cases the code in
question simply doesn't align with the interests of the people maintaining
Other comment threads (for example on Reddit here
followed a similar pattern. Intel focusing on Wayland and X is seen as Mir
(or Canonical) bashing, with some positing that it really was an attempt to
prop up Tizen vs. Ubuntu Touch (or some other Canonical mobile initiative).
Or that Intel believes Wayland is so badly broken it needs to stop the Mir
"momentum" any way it can. Most of that seems fairly far-fetched.
One can understand Intel's lack of interest in maintaining support for
XMir without resorting to convoluted reasons—though the size of the patch
and how self-contained it is do lead
some to wonder a bit. There is a risk
for Intel in doing so, however. As Luc Verhaegen, developer of the Lima driver for ARM Mali GPUs, pointed out
in a highly critical blog
post, Intel could actually end up harming its own interests:
By not carrying this patch, Intel forces Ubuntu users to only report bugs
to Ubuntu, which then means that only few bug reports will filter through
to the actual driver developers. At the same time, Ubuntu users cannot
simply test upstream code which contains extra debugging or potential
fixes. Even worse, if this madness continues, you can imagine Intel stating
to its customers that they refuse to fix bugs which only appear under Mir,
even though there is a very very high chance of these bugs being real
driver bugs which are just exposed by Mir.
At this point, though, Intel may well be waiting to see the "proof of the
pudding". If Canonical is successful at getting Mir onto the desktops of
lots of Intel customers in the next year or two, one suspects that any
needed changes for Mir or XMir will be cheerfully added to the Intel video
driver. For now, the company loses little, and gains some maintenance and
testing time, by waiting for it all to play out.
In the end, there is an element of a "tempest in a teapot" to the whole
affair. We are talking about 300 lines of code that, evidently, won't need
much in the way of changes in the future (since the API is frozen). Intel
is almost certainly embarrassed by how the whole thing played out, and
Ubuntu fans will undoubtedly see it as yet another diss of their
favorite distribution. But in the final analysis, the impact on Mir users
will be minimal to non-existent, at least in the short term and probably
the long as well.
to post comments)