Earlier quoted context omitted.
Ubuntu initially agreed to use Wayland, then they changed their minds and invented Mir.
Does anyone know why?
Copyright assignment.
Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
61–70 of 102 posts
Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
#62Watch 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…
You must be drunk or something.... I for example.owned a machine.where audio only worked after I installed OSS4 in the kernel. AND removed PA and Alsa so they stopped crashing some Wine stuff.
Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
#63I 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…
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 techn…
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).
Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
#64I'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 apparen…
It actually does have code to support XWayland, the analogue to XMir: " rel="nofollow">http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log...
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: " rel="nofollow">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.
Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
#65Earlier quoted context omitted.
Ubuntu initially agreed to use Wayland, then they changed their minds and invented Mir.
Does anyone know why?
The current official rationale: https://wiki.ubuntu.com/Mir/Spec#Why_Not_Wayland_.2BAC8_West...
https://plus.google.com/113883146362955330174/posts/PXc93m8n...
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
Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
#66> 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…
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?
Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
#67Earlier quoted context omitted.
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…
Another problem with PulseAudio is with latency and routing, which is why a lot of professional audio programs on Linux use JACK instead of PulseAudio. It's sometimes very hard to get JACK to play nice with PulseAudio, and this is exacerbated by the fact that ALSA only allows one program to use one audio device at a time. So it doesn't always "just work"...
Isn't it kinda the kernel's job to allow multiple processes to access shared resources? Imagine if only one process at a time were allowed to access the disk.
Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
#68Earlier quoted context omitted.
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. I much prefer the GPL, since I think copyleft is (at least partly) what has made Linux the massive success it is, and I think a copyleft licence for a display server would similarly be better. But in this situation, I have to support Wayland over Mir. The reason largely being that Wayland vs. Mir actually gives credence to the argument that Linux can't succeed on the desktop because of fragmentation. Norm…
Also, MIR is using CLA, which sucks.
Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
#69Earlier quoted context omitted.
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)…
I'm sorry, but must be missing something. How does a GPLv3 display server prevent locking down the hardware? Afaik, the anti-TiVoization stuff only applies to the software that's GPLv3, not the stack it's running on.
Some argue that if it makes calls to a GPL application, it's a derivative work, which means it must also be GPL.
This means that if one part of the stack is GPL, everything higher must also be GPL.
Re: Intel rejection of Ubuntu’s Mir patch forces Canonical to go own way
#70Earlier quoted context omitted.
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…
> 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 a…
You are right, I meant 'display server' instead of both 'window server' and 'window managers'.