Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
arstechnica.com
arstechnica.com
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...
[2] https://plus.google.com/109919666334513536939/posts/QzAyr5fo...
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.
This is just the community yammering away over a particularly flameworthy fork. It's a proxy war over the "Why did Ubuntu write Mir?" question. The actual path to upstream for the patches is mostly irrelevant.
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.
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...
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.
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.
Wouldn't it be better for everyone if the distro would just manage those patches itself?
So think the video driver as library and the windowing system as an application using video driver library.
However, as tinco explained[0], it seems that there is no "standard graphics api" for linux, and the "link" between window servers and graphics drivers is hard coded. So you do in fact have to patch the video driver to provide support for a new window server (on Linux at least).
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.
> On Linux it is actually the window server that provides
> the interface between applications and the video driver.
> This means that every driver needs to interface with
> each of the window managers.
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.
Wayland and Mir driver support is pretty much a mystery, and Canonical has been trying to engage hardware designers (Nvidia, Intel, AMD) for support. This recent spate between Canonical and Intel may be indicative that the process isn't going well.
Ubuntu's next LTS release is 14.04 so it's 8 months away, and if there's any surefire way to piss Canonical off then Intel us definitely getting that job done. I'm not trying to defend Canonical but it's hard to ignore the reality of the situation.
I wouldn't be surprised if BSD licensing is on the table front-and-center during negotiations, considering the legal barriers surrounding GPLv3.
Also, it makes me wonder where this leaves Valve. I get the distinct impression that they've been getting cozy with Canonical and they might be getting nervous about the situation.
I think Valve is the reason that Canonical can work together with NVidia and AMD, and that they're probably not nervous about this at all.
This means that if one part of the stack is GPL, everything higher must also be GPL.
Actually the opposite; Canonical will sell phone vendors a non-GPL version of Mir so that they can lock down their phones.
But for now, it's only speculation. Time will tell.
This code is an optimization, not a strict requirement, as you're right that in theory XWayland or XMir could be supported in a hardware-agnostic manner. For XWayland this is the (formerly "wlshm") xf86-video-wayland X driver: <http://cgit.freedesktop.org/xorg/driver/xf86-video-wayland/>, but it is much slower than the hardware-specific options (which also exist for the radeon and nouveau X drivers). I don't know if there's an equivalent hardware-agnostic X driver for Mir, but in no case would a production-quality windowing server have that as its only method of compatibility for an important hardware segment--both Wayland and Mir developers expect X-dependent applications to stick around for quite some time, so they must perform as well as possible.
For what it's worth, my hat is firmly in the Wayland camp; its design is simpler, its development more open, and its motivations more clear than those of Mir. Canonical does a bad job of software stewardship and I'd hate to see them in control of the dominant graphics solution for Linux.
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.
For individuals: http://www.canonical.com/sites/default/files/active/images/C...
2.3 Outbound License
Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date.
Same goes for the entity license: http://www.canonical.com/sites/default/files/active/images/C...
You might also want to read the following:
For the history, abandon all hope ye who enter here:
http://www.phoronix.com/scan.php?page=news_item&px=MTMxNzI https://wiki.ubuntu.com/Mir/Spec?action=diff&rev1=3&rev2=4 http://www.phoronix.com/scan.php?page=news_item&px=MTMxODY
So either:
1) Ubuntu didn't understand Wayland at all, amd decided to write their own from scratch without talking to or consulting the Wayland devs.
Or
2) Ubuntu has an ulterior motive (e.g. Not-Invented-Here-syndrome).
Intel is actively making a stand against Open Source. I know that's unlike them, but their stance just makes no sense from a free software perspective.
When you look at it from the perspective of Canonical enabling AMD and NVidia to cooperate with introducing a new graphics driver interface, a shadowy doubt is cast over Intel's motivations.
When you look at it from this perspective, a shadowy doubt is cast over Canonical's motivations.
By rolling their own display server, Canonical has set back efforts to get all display vendors on board for supporting Wayland.
If Ubuntu would have switched used Wayland (along with the other distributions), there would have been a very strong incentive for all vendors to support this in their drivers.
There are a lot of things in linux land that don't make sense, I think picking on Canonical for choosing to do what they want as opposed to all the others who are choosing to do what they want, is very un linux like.
If we had solid, feature-complete open source graphics drivers this wouldn't be an issue.
If it's the most popular display framework in terms of use, then why not simply make it the default? Not Wayland nor X11 could garner the numbers required to overtake SF.
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.
Then there's the hardware-specific fun: headphone outputs that don't mute the speakers when they should due to driver or hardware quirks, outputs and inputs that plain don't work, weird volume glitches where exiting one app causes all the others to shift in volume due to PulseAudio's info about the hardware volume control being wrong...
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?
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.
sudo amdconfig --set-pcs-val=MCIL,DigitalHDTVDefaultUnderscan,0Even then, if you stick to ALSA applications, you'll have a few issues:
1) You're going to be limiting yourself to a lot less possibilities (Skype uses Pulse, IIRC, for example)
2) You can't have simple settings such as per-application volume control.
Sure it "just works", but it does if you use a set of programs which only the people who say "it just works" (a lot of people, I know) restrict themselves to. While it may work for you, different people have different needs.
I'm still waiting for the day Linux audio (and video, but less hopeful because of proprietary drivers) simply works in the same way it does under Windows/Mac.
Footnote: I completely forgot to mention latency issues, which is awful for audio processing.
Can't say I've ever noticed Pulse latency, even while playing Quake, except when using Pulse's networking features. Maybe I have crude ears.
It may not represent the typical Linux users, but while audio processing also doesn't represent the typical PC user, it works under mainstream operating systems. Until such a simple thing also "just works", I won't be happy with sound on Linux.
Basically, I'm from the group of people who want things to work on Linux for the same use cases they work on mainstream OSs before I state that it "just works". I believe saying things "just work" only because it works for most of my needs is detrimental, as it gives a wrong image and may frustrate people trying to do something different , as it has happened to me in the past, I've caught myself trying to do non-standard things a lot (read: most) of the time.
There's a ton of Windows applications that take over audio and do a lot of driver weirdness. There's still ASIO incompatibilies, latency issues, etc. In fact it happens in the same space where PulseAudio and JACK intersect on Windows.
Wasted a whole day at work with that one. The nVidia drivers don't support framebuffer consoles, only VGA, but UEFI doesn't provide VGA console I/O. And an encrypted disk needs human interaction to type the password in at bootup, meaning some kind of graphical support. Meanwhile, the non-proprietary drivers crash the X server if you so much as jiggle a window about.
Your best bet with desktop Linux is still to buy old, cheap, common-denominator hardware. Anything recent is a gamble unless you're very technically adept or have access to professionals.
Not with proprietary drivers. AMD/NVidia's failure to produce usable drivers of their own isn't particularly relevant as far as I am concerned. In fact, it serves to highlight just how good the the FOSS drivers are at "just working".
"Meanwhile, the non-proprietary drivers crash the X server if you so much as jiggle a window about."
That makes absolutely no sense whatsoever. Frankly, I do not believe it.
All you had to do to crash X was move a window quickly from side to side. The proprietary drivers are infinitely better in so far as they don't crash.
In contrast, audio tends to randomly completely break after every other update. Most recent major breakage I had: for one whole Fedora release, the headset mic input would not work in the one app where I need it to work (Skype). Worked fine on the previous and next releases, with the same Skype binary.
Minor problems that can be worked around just randomly come and go. Right now one one machine all audio playback will stop working every few days, until pulseaudio is killed. Another computer randomly goes to a mode where all audio playback from Chrome is accelerated by IIRC 7%. Just enough to make you uneasy due to things being off somehow, but not enough to make obvious that there's a problem. This persists until pulseaudio is killed and restarted, of course, which magically fixes things.
Doesn't exactly seem like a lot of work to support this.
Free karma if you do!
They want to use the same code for Ubuntu on phones, desktops, tablets. Intel doesn't much care to support anything other than Wayland because after 10+ years of X.org, they know better than anyone (most of all Canonical) what is best when it comes to display servers. They are putting all of their weight behind Wayland and don't see XMir as a viable future. As a result, they made a decision to not support it upstream.
Their driver their call. Seems relatively cut and dry to me. As usual, another case where Canonical can't play with the rest of the open source community.
Edit to add all below:
I would also highly suggest anyone curious to read:
http://www.phoronix.com/scan.php?page=article&item=x_wayland...
http://mjg59.dreamwidth.org/26254.html
Those two articles are both critical of Mir, but are also from some very senior developers in the low level Linux/X related plumbing of Linux. I'd argue they are more qualified to speak about the failings of X than the Mir developers primarily because they've been the people fixing it's bugs the past many years.
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).