
Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way - redman25
http://arstechnica.com/information-technology/2013/09/intel-rejection-of-ubuntus-mir-patch-forces-canonical-to-go-own-way/
======
WestCoastJustin
_> Intel customers who use Ubuntu will not see any regressions as we will
simply continue to support XMir in the Intel driver as part of Ubuntu._

This is an issue _only_ if you wish to use XMir outside of Ubuntu. Ubuntu
controls their own ecosystem so they can just patch/compile/repackage their
distribution as needed, like they do for many other packages (i.e. Mesa,
xf86-video-ati, and xf86-video-nouveau). The core issue is that they wanted to
push XMir support upstream so that other distros could use XMir.

Cryptic messages are making people draw their own conclusions as to what the
issue is.

 _> We do not condone or support Canonical in the course of action they have
chosen, and will not carry XMir patches upstream. - The Management_ [1]

 _> I've said it before, I'll say it again. You will not make your open source
project better by pulling another open source project down. - Michael Hall_
[2]

I think we are not seeing the full discussion happen in public light and there
is a lot of guess work happening.

[1] [http://cgit.freedesktop.org/xorg/driver/xf86-video-
intel/com...](http://cgit.freedesktop.org/xorg/driver/xf86-video-
intel/commit/?id=58a7611)

[2]
[https://plus.google.com/109919666334513536939/posts/QzAyr5fo...](https://plus.google.com/109919666334513536939/posts/QzAyr5fo6r9)

~~~
ealexhudson
In all likelihood, few other distros will be interested in shipping XMir.
Pushing upstream is usually a better thing to do because it helps reduce the
maintenance burden - you're not maintaining a patchset.

Intel's decision is basically saying they don't want any of the burden of
helping maintain (X)Mir. Canonical/Ubuntu make a rod for their own back every
time they settle on these Ubuntu-only solutions imho.

~~~
WestCoastJustin
I don't really see why Ubuntu is getting bent out of shape about this. Maybe
this is just a media/blogger generated grudge. Many very popular open source
packages are maintained out of stream before getting pushed upstream. DRBD [1]
was a very popular package which, after years of patches, finally got accepted
into the kernel. I think there is a burden of proof required before asking
someone to maintain your patch set upstream.

[1] [http://www.drbd.org/](http://www.drbd.org/)

~~~
efuquen
I think you're mistaking what is probably largely a political issue for a
technical one. The sense I get here is that there is nothing technically wrong
with the patch, it's not like Intel went back to Ubuntu and said you have to
fix X Y & Z to get this merged. They initially accepted the patch and only
after having accepted it on technical grounds they've come back and rejected
it because Mir isn't the horse they're backing.

If anything I would guess _Intel_ is the one getting bent out of shape here,
though I couldn't possibly know for sure due to lack of details.

~~~
bitwize
Intel is acting in the best interests of the community, which almost
unilaterally backs Wayland.

Linux is not about choice[0]. It's 2013, and the hard lesson that choice is
death to a reliable platform should have been well-learned by now, if by
nothing else than by the sheer fact that Apple steamrolled the Unix
workstation market into oblivion. Mac OS -- which provides comparatively
little choice -- grows YoY, whereas non-Mac desktop Unix, including Linux, has
faded into statistical noise.

If non-Android Linux is going to claw its way back into relevance, then the
community needs to decide on one framework for graphics, one for sound, etc.
and back them wholeheartedly. It _is_ a technical issue because focusing all
developer effort on one good thing produces better technical results than
splintering it among a dozen mediocre things. Apostasy needs to be punished,
and that's what Intel has done.

[0] [http://www.redhat.com/archives/rhl-devel-
list/2008-January/m...](http://www.redhat.com/archives/rhl-devel-
list/2008-January/msg00861.html)

~~~
synchronise
Apostasy needs to be punished, that's 21st century thinking right there.

~~~
gph
If Linux is ever to become mainsteam the way OSX and Windows are then
'apostasy' needs not be accommodated.

Now you can debate whether the philosophy of the Linux and open-source
community is for creating a standardized product that can be easily adopted
and used by the mainstream user-base. But for companies like Intel, I
understand why they want to push it in that direction.

~~~
synchronise
Linux already is mainstream, just look at the success that Android has had.

And there are still competing frameworks out there that are objectively better
than the decided on counterparts.

ALSA replaced OSS, then OSS4 came out. The latter is more stable and can do
more things than the former can do alone, such as per application volume
controls, yet it's only used in the BSD sphere.

Likewise, OpenRC is a great replacement for SysVinit without changing the
overall structure of the init system, unlike systemd which attempts to
consolidate all of those parts into 'optional' modules that other projects are
making compulsory e.g. Gnome Shell has a hard dependency on systemd as logind
cannot be used alone any more, not to mention the large changes to the init
design.

------
lelandbatey
I'm confused. I've seen this a bunch of times, and I don't understand why
Canonical submitted a patch to a _video driver_ to "support" their Xmir window
server. Why does a video driver need to have code in it to support a window
server? Isn't it supposed to be the other way around? Isn't the window server
supposed to work on top of the video driver (and all the other hardware
drivers)? What's going on?

~~~
tinco
On Linux it is actually the window server that provides the interface between
applications and the video driver.

Linux does not have a standard graphics driver interface like Windows does, at
the moment is sort of defined by X, and since Wayland and Mir aim to replace
X, the interface will be replaced too.

This means that every driver needs to interface with each of the window
managers.

I would agree that is a silly idea, but such is the world when applications
need very low level access to hardware to attain real time performance. You
just get a tangly mess.

~~~
jmillikin

      > On Linux it is actually the window server that provides
      > the interface between applications and the video driver.
    

This hasn't been true for a long, long time. Modern Linux applications
directly call into the graphics driver, either through OpenGL or an
intermediate library such as Clutter.

    
    
      > This means that every driver needs to interface with
      > each of the window managers.
    

This is also not true. Window managers are driver-independent, and you can
easily write your own window manager without any knowledge of the underlying
hardware. You might mean "display server" instead of "window manager", but
there's only one display server used in Linux, and that is X11.

X11 was designed in an era before standardized graphics or input APIs, so it
doesn't use OpenGL. As a result, it needs its own set of drivers for nearly
everything (keyboards, mice, graphics, overlays). That's why Linux graphics
drivers need to have special X11 support.

Wayland and Mir are an attempt to replace X11 with a much thinner layer,
handling only the bare necessities of getting the driver and user application
together so they can talk OpenGL together.

~~~
tinco
You are right, I meant 'display server' instead of both 'window server' and
'window managers'.

------
ChuckMcM
I find the dissonance of this conversation and the optimism of Gabe Newell in
the "Gaming on Linux" article fascinating.

Graphics has been screwed up on Linux ever since the 3dfx Voodoo 1 and nVidia
TNT wars. It spilled over into the ARM SoC space.

I don't know what the answer is, but I recognize that chip companies not
supporting someone's efforts to make their software useful on that company's
chip for more people is mind boggling.

~~~
tux1968
It's about maintaining a clean codebase. If a maintainer believes that a
proposal is genuinely the wrong way to achieve a goal, it is counterproductive
to accept it. This happens all the time in the Linux kernel for instance,
where one or more further iterations are required to get something accepted.
It's just juvenile to stamp ones feet because some upstream disagrees with a
particular approach. You argue the technical merits, and then you live with
their decision by going your own way or revamping your submission. It's hard
to imagine open source working any other way.

~~~
joe_the_user
So you're saying Wilson thought Mir would allow a clean code base a few days
ago when he accepted a Mir patch and now he doesn't, despite not giving any
technical reasons for the change in opinion? (Me - complete outside but the
turn of events sure sounds fishy).

------
gaius
Watch Linux video go the way of Linux audio... Intel are 100% in the right to
make a stand.

~~~
jmillikin
I wish Linux video would go the way of Linux audio.

Linux audio just works. There's a single userspace API (PulseAudio), a single
kernel driver API (ALSA), and all the old nastiness of the '90s (ESD, aRts,
OSS) is dead and gone.

In contrast, getting video to work properly involves figuring out what
hardware you're running (nVidia? ATI/AMD? Intel? misc other?), then hunting
down the drivers, installing them, rebooting, hoping the hardware gets
detected correctly, and so on until the user gives up and settles for a half-
broken system. I consider myself fairly skilled with Linux stuff, and I still
can't figure out how to get my desktop to have both kernel modesetting and
accelerated OpenGL at the same time.

~~~
jlgreco
Frankly both audio and video "just work" in Linux, and have for years. It has
been several years since I bothered to look up what chips a computer had and
what Linux support was like before making a purchase.

I just buy the hardware I want, assume it will work, and find that it does.
Maybe I've been getting lucky, but I don't think so.

The only real remaining pain in the ass is printer support, but who the hell
uses printers these days?

~~~
ikt
My HTPC has the desktop off the top of the TV and frequently the HDMI audio
doesn't work.

With my ATI graphics card on my desktop I have a script that runs on startup
to force the display drive to to detect my 1920x1080 monitor otherwise it
displays the screen with big black bars all around the edges.

Audio and video are still a pita for me.

~~~
oakwhiz
Have you tried this?

    
    
      sudo amdconfig --set-pcs-val=MCIL,DigitalHDTVDefaultUnderscan,0

------
geoffhill
Here's the actual commit that was reverted, for anyone curious like me:
[http://cgit.freedesktop.org/xorg/driver/xf86-video-
intel/com...](http://cgit.freedesktop.org/xorg/driver/xf86-video-
intel/commit/?id=42d94356f65972eb7fb8991234a4e9388c4c2031)

Doesn't exactly seem like a lot of work to support this.

------
joeblau
Fragmentation: It's the Linux way. I always love looking at this picture:
[http://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Dis...](http://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg)

------
raldi
Can someone summarize the story in a way that doesn't presuppose prior
knowledge of what Mir or XMir is, and who isn't familiar with the Ubuntu-Intel
history?

Free karma if you do!

~~~
Cogito
== Backstory ==

The X Window System (known as X11 - 11th version) is currently the predominant
way for Linux users to use a graphical interface, specifically a windowed
interface.

It is old and was designed for a purpose that doesn't match current usage nor
technology. For this reason, a number of projects have risen to replace X11.

'Wayland' is the best supported of these projects, whilst 'Mir' is similar but
has much less support. Mir was started specifically for Ubuntu, and has caused
significant controversy in the community.

Until these new projects are completed, and in order to support legacy
software written for X, bridges that allow X11 compatible software to run on
Wayland or Mir have been created. These are called XWayland and XMir
respectively.

== Current Story ==

The open source Intel drivers support X11, and increasingly will support
Wayland (not sure on current state of this).

Canonical wrote a patchset that adds support for Mir to the Intel drivers, and
requested that this be included in the main Intel project.

Intel has, for seemingly political reasons, denied that request. Canonical
will thus have to maintain the patches themselves (it is common for many
distributions to maintain patchsets in this way). If anyone else wanted to use
Mir, and use Canonical's XMir bridge, they would need to source it from
Canonical directly rather than from the main Intel repository.

It seems that Intel doesn't want to support multiple new windowing projects,
and has backed Wayland over Mir (as have many others in the community).

~~~
nitrogen
Does anyone know if Intel could just expose an API that is entirely agnostic
of the display server, so Wayland, Mir, XMir, or some random other project
could all use the same interface and get full functionality?

~~~
wmf
I thought that API was KMS/DRM, but maybe it's not enough.

------
jessaustin
Maybe some people have it out for Canonical no matter what, but the fact that
Wilson accepted the patches only to reject them days later while blaming some
anonymous "management" seems to pin this entire "controversy" on IBM. If the
only accepted course for Canonical is to shit-can Mir and take whatever
Wayland eventually becomes (I mean, who's to say the same wouldn't happen to
any Wayland patches Canonical produces?), it shouldn't surprise anyone that
Canonical prefer working on projects they have some opportunity to influence.

