Slashdot Mirror
Intel Rejects Supporting Ubuntu's XMir
An anonymous reader writes "Just days after Intel added XMir support to their Linux graphics driver so it would work with the in-development the X11 compatibility layer to the Mir display server premiering with Ubuntu 13.10, Intel management has rejected the action and had the XMir patch reverted. There's been controversy surrounding Mir with it competing with Wayland and the state of the display server being rather immature and its performance coming up short while it will still debut in Ubuntu 13.10. Intel management had to say, "We do not condone or support Canonical in the course of action they have chosen, and will not carry XMir patches upstream." As a result, Canonical will need to ship their own packaged version of the Intel (and AMD and Nouveau drivers) with out-of-tree patches."
Though Intel will be open to an alternative to X11 they are in no way obliged to carry an immature release just because Canonical wants to push theirs.
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
Why does the Intel Xorg graphics driver have to know anything about XMir, which, as far as I understand it, is just an Xorg driver for running Xorg as a Mir client?
When will Linux finally use standard ABIs and APIs for drivers just like very other OS on the planet?
Why can't you just use one driver written a few years ago and use it universally across all distros due to this? The other free BSDs have this and you can install the extra compat libraries to accomplish this. I guess RMS thinks that is oppressive and wants opensource hardware even though patent holders from the likes of the h.264 consortorium forbid it!
Before I get flamed remember the article mentioned ATI and NVidia drivers as well so Intel is not the asshole here. Rather they different kernels and distros being redone requiring new QA and recompiling with every release.
There is a reason many old time linux users like myself only run CentOS in a VM Now. It is because Redhat provides ABIs and APIs that do not change for 5 years. Unfortunately it also means an out of date distro as well which is not fair to non server users (even a few server users who need a newer app or framework.)
http://saveie6.com/
I trust them more than Canonical, that's for sure.
Mother is the best bet and don't let Satan draw you too fast.
Dumb framebuffer wars begun have they?
So when Ubuntu 13.10 ships, it will force you to use XMir?
If so, thanks for the warning. The last thing I want to do is deal with an unstable graphics driver. It's taken years for X11 with NVidia drivers to get stable, and I don't want to touch XMir with someone else's 10-foot pole for until it's been in use for at least 2-3 years.
I do not fail; I succeed at finding out what does not work.
Canonical decided to write their own Mir display server instead of adopting the existing Wayland. They stated their reasons for doing so, but I'm not convinced they really had to start their own project instead of modifying Wayland.
It seems only fair to me that if Canonical wants to do their own thing, they'll have to put in the effort to maintain it. Because that is what this is about: Intel management decided that they're not going to pay their engineers to maintain code that benefits only Canonical.
I think Mir is a case study in how to correctly identify problems and then going about solving them all wrong.
See, the good thing about Wayland is, it does the right thing in having a limited scope. It aims to do one thing and do it well: provide an API for GUI clients to share buffers with a compositor.
And the problem with Wayland is, of course, that... it has a limited scope. Screen management? Input handling? Buffer allocation? "A modern desktop needs all that!" say the Ubuntu devs, and yeah, that's absolutely correct. "That's a client concern," say the Wayland devs, and guess what? From their point of view, that's correct too. (Although Wayland since started working on an input handling API.)
Now, the important thing to realize is, when the Wayland guys say that something is a client concern, as I understand, they don't necessarily mean the GUI applications, no. They mean the compositor.
Meaning that a whole lot of the stuff desktop shells rely on is, in fact, not provided by Wayland itself.
That's where Weston comes in: it's supposed to be an example (a "reference implementation", to use the designated words) of how to write a compositor. But... not necessarily in a way that meets the higher level needs of desktop shells. Unsurprisingly, both KDE and GNOME will be using their own compositors.
So basically, a whole lot of the desktop integration on top of Wayland will be, as it were, left as an exercise to the reader.
With all that in mind, I think the highest outcome end game is somewhat clear: frame-perfect rendering through the Wayland API of Mir-composited KDE/GNOME/Unity clients.
Or in other words, Mir should probably be a set of APIs to handle all the admittedly important desktop integration -- clipboard, multi-screen layout, input and gestures, systray/notification requests... -- with an optional and replaceable compositor thrown in.
All the points of contention that I know of, mainly that Canonical requires server-side buffer allocation (presumably for mobile ARM platforms) where Wayland does it client-side, could have been resolved with some diplomacy and a mutual willingness to reach a satisfactory compromise.
But instead, it looks like the report card is just going to say, "Doesn't play well with others." As usual. What a sad mess and wasted opportunity.
-- B.
This sig does in fact not have the property it claims not to have.
That was pretty off-topic, there AC. You even left us guessing about which part of hicksville you call home (Georgia perhaps?).
Crimey
More like disinterested third party sees which way the winds are blowing and decides to pull resources away from supporting what is going to be an also-ran. Intel has been a very good citizen where it comes to provided chipset and video driver support to the Linux community. They are still making drivers for X.org ( you know the display server people actually use ) and likely will develop drivers for Wayland.
Why you or anyone else ( who does not run Ubuntu ) would want them dividing their efforts a third way writing software that will only be useful to a tiny segment escapes me. Normally I am not anti-choice but the best outcome here is for MIR to go down in flames.
The one factor that has made desktop UNIX/Linux a reality is the near universality of X11. Despite all the toolkit and desktop environment / window manager fights X11 was something software devs could depend on being there. As far as end users some integration issues aside they could run multiple toolkits and other high level stuff when needed. It would be really hard though for users to efficiently run multiple display servers. The display server is pretty much a core platform component now. I honestly think MIR is a Cononical attempt to create a walled garden for their platform. It isn't about better software for them but control.
I am glad Intel is abandoning the platform; hopeful Cononical's garden will simple become a ghetto.
No comment on closed/open source drivers but I was just thinking about that problem. If there is no working driver for Win8, maybe your dad could run a little virtual machine as a printer server using an older version of Windows? So you would pass through the printer USB device to the VM. It's a bit clunky solution, but might keep the printer going.
Intel heavily supports Wayland, including employing the primary developer. Isn't this move on their part simply saying, we're dogfooding Wayland, and Canonical needs to handle XMir itself? Snark aside, doesn't that seem like a reasonable move on their part?
"Ahh! I see you're in that indeterminate Schrodinger state where - oh, uh
> OpenGL and glx run many windows DirectX games under Wine FASTER than Windows running DirectX.
>
> Many games ported to use Linux and OpenGL natively show up FASTER than their Windows relation, either OpenGL
> (being faster on Windows than DirectX) or DirectX on Windows.
I can testify to this as well, having run Need for Speed Hot Pursuit as well as Roadrash under WINE.
There is a cost to keeping the code in there, even if it's not supported. If interfaces change, the unsupported code can break the build. Finding things in the code, by reading or grep, becomes harder since there is more of it. Static code analysis might flag issues in the unsupported code. Bugs will probably be filed that they'll then have to close as WONTFIX.
Also the question is what purpose would be served by keeping unsupported code in the main repository. If it's not regularly updated and tested, it will be broken sooner or later. Canonical will have to maintain the code anyway, so there will be a separate repository somewhere that contains the working version of XMir support.
Sadly nvidia's slowest graphics cards have a 29W TDP, and the chip he's talking of is a combined CPU+GPU at 18W TDP. Meaning no, there's no nvidia graphics in a netbook or tiny PC. And blaming the victim is lame, you can't change the graphics on a laptop with a GPU in the CPU.
If you're arguing that no one should by affordable laptops, why not. I like using desktops (and CRT monitors).
We'll see if 22nm Atom is better (with something like Ubuntu 14.04 - not necessarily the main edition - if you want driver support out of the box). Still there could be framerate issues, as an inferior driver costs you CPU cycles.