Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

21–30 of 102 posts

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

#21

Post by ihsw »

tinco wrote: post #16
ihsw wrote: post #8

Earlier quoted context omitted.

Beyond that, it may be because Mir is GPLv3 licensed and Wayland is MIT licensed. Just a hunch.

Oh I didn't even know that. That's a great reason to prefer Wayland over Mir or Mir over Wayland. I'm a bit torn now..

Indeed, also X.Org is X11 Licensed (MIT license variant).

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.

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

#22

Post by ealexhudson »

WestCoastJustin wrote: post #18
ealexhudson wrote: post #17

Earlier quoted context omitted.

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.

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 se…

I'd say it's understandable in this instance - I sympathise because it was initially accepted, and it's not a large patchset. I suspect if there hadn't been the various tech articles about how Intel were accepting XMir, the patchset could have stayed in (supposition, of course).

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

#23

Post by ajross »

WestCoastJustin wrote: post #18
ealexhudson wrote: post #17

Earlier quoted context omitted.

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.

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 se…

I don't think "Ubuntu" is particularly bent out of shape. Obviously as the authors of these patches they're already maintaining them in their tree already. All distros have long lists of local feature patches they maintain. And X.org/Intel aren't particularly concerned either, all they did is say "no". Patches get rejected every day.

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.

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

#24

Post by ginko »

toyg wrote: post #20
tinco wrote: post #13

Earlier quoted context omitted.

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…

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.

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.

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

#25

Post by mhurron »

jmillikin wrote: post #14
gaius wrote: post #2

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

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…

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.

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

#26

Post by voyou »

lelandbatey wrote: post #3

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?

Yes, I don't understand this, either. Note that a) the Intel X driver does not, AFAICT, have any special code to support Wayland and b) the code Ubuntu want to add appears to be for XMir, which is an X server that runs on top of Mir, not for the Mir display server itself. An X server running on top of a different display server should not need specific support in the drivers of the X display server; that XMir apparently does makes me worried Mir is going to be an architectural clusterfuck.

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

#27

Post by efuquen »

WestCoastJustin wrote: post #18
ealexhudson wrote: post #17

Earlier quoted context omitted.

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.

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 se…

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.

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

#28

Post by makomk »

jmillikin wrote: post #14
gaius wrote: post #2

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

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…

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...

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

#29

Post by 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.

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

#30

Post by spacelizard »

tinco wrote: post #16
ihsw wrote: post #8

Earlier quoted context omitted.

Beyond that, it may be because Mir is GPLv3 licensed and Wayland is MIT licensed. Just a hunch.

Oh I didn't even know that. That's a great reason to prefer Wayland over Mir or Mir over Wayland. I'm a bit torn now..

Not really. GPLv3 will prevent hardware manufacturers from locking down their devices if they intend to ship Ubuntu Mobile. This is a good thing for users of those devices. I can't defend Canonical's support of proprietary drivers, especially on these devices that are known to be used for such pervasive spying, but at least a non-hardware-locked device allows for workarounds (i.e. deployment of your own free drivers).
Post reply on HN