10 ms·

Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way

105 points by redman25 13y ago

gaius 13y ago
Watch Linux video go the way of Linux audio... Intel are 100% in the right to make a stand.
- drivebyacct2 13y ago
  A completely overblown exaggeration and really not an issue for 98% of users ever, let alone regularly?
- tinco 13y ago
  It won't be like Linux audio, because all Linux audio drivers are open source. If Intel can't get AMD and NVidia to support Wayland, and Canonical spoke the truth when they said that AMD and NVidia will support Mir, then what reason will people have to use Wayland? It will only work with Intel cards. 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.
  - toyg 13y ago
    Well, what is stopping NVidia and AMD from cooperating on Wayland right now? When you look at it from this perspective, a shadowy doubt is cast over Canonical's motivations.
    - ginko 13y ago
      This is the part that irritates me most about Mir: 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.
      - ikt 13y ago
        If Red Hat had supported .deb packages maybe packaging wouldn't be such a pain in the ass and we wouldn't have a .tar, .deb and a .rpm for every program. 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.
        ginko 13y ago
        The difference is that the choice of package system is completely in the domain of open source software. Proprietary drivers require support by hardware vendors. If we had solid, feature-complete open source graphics drivers this wouldn't be an issue.
      - synchronise 13y ago
        If this were the case, then why is a large swathe of proprietary drivers supporting only Surfaceflinger? 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.
- jmillikin 13y ago
  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.
  - mhurron 13y ago
    The only time I have hunt down video drivers for Linux is when I decide to use the closed nVidia driver. Other than that it's all kernel/X supplied drivers.
  - makomk 13y ago
    Except that it doesn't just work. Ignoring the hardware aspect altogether for a moment, PulseAudio itself is inherently buggy. If you run it for long enough with its volume control app open, the daemon sometimes crashes and everything stops playing sound. (It looks like that might be due to a bug in the peak volume reporting code resulting from an incredibly misleading variable name, but I'm not sure - none of it's commented, so it's impossible to figure out how it's meant to work). Resampling glitches out randomly and requires a restart of the daemon. There was a patch to the resampling code in the latest release which was outright incomplete and broken but got included anyway, and since the PulseAudio devs don't release stable versions, the only release with the fix in will be a major one with a whole bunch of new regressions. I've encountered major bugs with fixes in the Fedora package that weren't submitted upstream at all, and the patches were written and added by Lennart Poettering himself. 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...
  - jlgreco 13y ago
lelandbatey 13y ago
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?
- achat 13y ago
  While developing some application, did you ever feel that your SDK is lacking some feature which would make your app development much easier? So think the video driver as library and the windowing system as an application using video driver library.
  - lelandbatey 13y ago
    Yep. However, if you're trying to replicate something that's already built on top of an existing piece of software using the existing API's, I'd assume you wouldn't have to patch the platform just to build on top of it. 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).
- tinco 13y ago
  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.
  - lelandbatey 13y ago
deleted 13y ago
[deleted]
WestCoastJustin 13y ago
> 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/commit/?id=58a7611 http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/com... [2] https://plus.google.com/109919666334513536939/posts/QzAyr5fo6r9 https://plus.google.com/109919666334513536939/posts/QzAyr5fo...
- marshray 13y ago
  Why should Intel accept a patch that's only ever going to be useful for one distro? Wouldn't it be better for everyone if the distro would just manage those patches itself?
- ealexhudson 13y ago
  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 13y ago
    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/
jessaustin 13y ago
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.
ChuckMcM 13y ago
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 13y ago
  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.
  - AsymetricCom 13y ago
    I thought it was more about making it impossible to use GPUs to guide cruise missiles, but that might be a bit presumptuous.
  - joe_the_user 13y ago
    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).
- deleted 13y ago
  [deleted]
- wmf 13y ago
  The answer to un-screwing Linux graphics is Wayland, and every major player in the ecosystem agreed to it. Then Ubuntu decided to go their own way so the other players are freezing Ubuntu out.
geoffhill 13y ago
Here's the actual commit that was reverted, for anyone curious like me: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=42d94356f65972eb7fb8991234a4e9388c4c2031 http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/com... Doesn't exactly seem like a lot of work to support this.
joeblau 13y ago
Fragmentation: It's the Linux way. I always love looking at this picture: http://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg http://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Dis...
raldi 13y ago
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!
- SEJeff 13y ago
  X.org is an ancient beast that works, but is creaky. Intel has really been leading the charge to develop a new display server named Wayland. After much publicity from none other than Mark Shuttleworth about how Ubuntu was going to adopt Wayland, they decided to write their own display server from scratch named XMir. 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_situation&num=1 http://www.phoronix.com/scan.php?page=article&item=x_wayland... http://mjg59.dreamwidth.org/26254.html 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.
  - raldi 13y ago
    I really appreciate your well-written reply. May it receive a multitude of points.
    - SEJeff 13y ago
      Thanks! I've added two technical articles with reasonings why Wayland and some technical reasoning to back that up.

105 points by redman25 13y ago

gaius 13y ago

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

drivebyacct2 13y ago
A completely overblown exaggeration and really not an issue for 98% of users ever, let alone regularly?
tinco 13y ago
It won't be like Linux audio, because all Linux audio drivers are open source. If Intel can't get AMD and NVidia to support Wayland, and Canonical spoke the truth when they said that AMD and NVidia will support Mir, then what reason will people have to use Wayland? It will only work with Intel cards. 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.
- toyg 13y ago
  Well, what is stopping NVidia and AMD from cooperating on Wayland right now? When you look at it from this perspective, a shadowy doubt is cast over Canonical's motivations.
  - ginko 13y ago
    This is the part that irritates me most about Mir: 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.
    - ikt 13y ago
      If Red Hat had supported .deb packages maybe packaging wouldn't be such a pain in the ass and we wouldn't have a .tar, .deb and a .rpm for every program. 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.
      - ginko 13y ago
        The difference is that the choice of package system is completely in the domain of open source software. Proprietary drivers require support by hardware vendors. If we had solid, feature-complete open source graphics drivers this wouldn't be an issue.
    - synchronise 13y ago
      If this were the case, then why is a large swathe of proprietary drivers supporting only Surfaceflinger? 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.
jmillikin 13y ago
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.
- mhurron 13y ago
  The only time I have hunt down video drivers for Linux is when I decide to use the closed nVidia driver. Other than that it's all kernel/X supplied drivers.
- makomk 13y ago
  Except that it doesn't just work. Ignoring the hardware aspect altogether for a moment, PulseAudio itself is inherently buggy. If you run it for long enough with its volume control app open, the daemon sometimes crashes and everything stops playing sound. (It looks like that might be due to a bug in the peak volume reporting code resulting from an incredibly misleading variable name, but I'm not sure - none of it's commented, so it's impossible to figure out how it's meant to work). Resampling glitches out randomly and requires a restart of the daemon. There was a patch to the resampling code in the latest release which was outright incomplete and broken but got included anyway, and since the PulseAudio devs don't release stable versions, the only release with the fix in will be a major one with a whole bunch of new regressions. I've encountered major bugs with fixes in the Fedora package that weren't submitted upstream at all, and the patches were written and added by Lennart Poettering himself. 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...
- jlgreco 13y ago

lelandbatey 13y ago

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?

achat 13y ago
While developing some application, did you ever feel that your SDK is lacking some feature which would make your app development much easier? So think the video driver as library and the windowing system as an application using video driver library.
- lelandbatey 13y ago
  Yep. However, if you're trying to replicate something that's already built on top of an existing piece of software using the existing API's, I'd assume you wouldn't have to patch the platform just to build on top of it. 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).
tinco 13y ago
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.
- lelandbatey 13y ago

deleted 13y ago

[deleted]

WestCoastJustin 13y ago

> 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/commit/?id=58a7611 http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/com... [2] https://plus.google.com/109919666334513536939/posts/QzAyr5fo6r9 https://plus.google.com/109919666334513536939/posts/QzAyr5fo...

marshray 13y ago
Why should Intel accept a patch that's only ever going to be useful for one distro? Wouldn't it be better for everyone if the distro would just manage those patches itself?
ealexhudson 13y ago
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 13y ago
  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/

jessaustin 13y ago

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.

ChuckMcM 13y ago

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 13y ago
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.
- AsymetricCom 13y ago
  I thought it was more about making it impossible to use GPUs to guide cruise missiles, but that might be a bit presumptuous.
- joe_the_user 13y ago
  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).
deleted 13y ago
[deleted]
wmf 13y ago
The answer to un-screwing Linux graphics is Wayland, and every major player in the ecosystem agreed to it. Then Ubuntu decided to go their own way so the other players are freezing Ubuntu out.

geoffhill 13y ago

Here's the actual commit that was reverted, for anyone curious like me: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=42d94356f65972eb7fb8991234a4e9388c4c2031 http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/com... Doesn't exactly seem like a lot of work to support this.

joeblau 13y ago

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

raldi 13y ago

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!

SEJeff 13y ago
X.org is an ancient beast that works, but is creaky. Intel has really been leading the charge to develop a new display server named Wayland. After much publicity from none other than Mark Shuttleworth about how Ubuntu was going to adopt Wayland, they decided to write their own display server from scratch named XMir. 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_situation&num=1 http://www.phoronix.com/scan.php?page=article&item=x_wayland... http://mjg59.dreamwidth.org/26254.html 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.
- raldi 13y ago
  I really appreciate your well-written reply. May it receive a multitude of points.
  - SEJeff 13y ago
    Thanks! I've added two technical articles with reasonings why Wayland and some technical reasoning to back that up.