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?
This sounds like dumb management decision that hopefully community outrage will cause Intel to reverse.
I say this not because I support Canonical's decision to build XMir or even run Ubuntu, but because I don't think politics of this nature should see source code removed from kernel. I would encourage other kernel developers to re-apply the patches.
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.
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.
There's not a lot of bloat in the system and that could be removed in a recompile, absolutely nothing to do with X11.
And why, precisely, is a "client/server relationship" bad, wrong or misguided? What issue, exactly, does it raise?
Other than being X11's way of solving access to hardware and being an old idea?
X11 was no more "made for dumb terminals" than Windows was made for cheap hardware.
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.
Well I'm not paranoid. I give my trust to those who deserve it and Canonical definitely do not.
Mother is the best bet and don't let Satan draw you too fast.
That was pretty off-topic, there AC. You even left us guessing about which part of hicksville you call home (Georgia perhaps?).
Crimey
Dad recently purchased a Windows 8 laptop, but the FujiXerox DocuPrint 203A printer doesn't have a Windows 8 driver. Some posts suggest that it is a rebadged Brother HL-2040.
I was using Windows as an example of why closed sourced drivers are bad for hardware longevity. Should my parents throw out a perfectly useable printer simply becausse FujiXerox cannot be bothered to release a new driver?
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.
The greybeards already had GL backends from their commercial unix vendors and thus had no itch to scratch.
X.org/XFree86 were slow lumbering beats who thought 'Who will ever need 3d acceleration'.
And the young upstarts decided 'we can do better', did it without proper engineering practices, regression testing, or any real concern for retaining the old feature set (without either clearly delineating the new one up front, or at least starting in a seperate branch, the XFree86->Xorg transition not withstanding) and basically ruined everything that once made X great, while leaving all the important new features in a constant state of flux for what... 10 years now?
As somebody who's used it, modern X is 'good enough', but it's also horribly broken. And the attitude regarding that brokenness is 'Fix it yourself', regardless of fact that many of those fixes span multiple modules and may or may not require YET ANOTHER BREAKAGE to accomplish.
Really?
OH My God! Canonical is Black People!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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
This needless display system might put the fledgling Linux gaming industry on the back foot. Games need good drivers quite often. Steam only runs on Ubuntu (officially) and this silly bullying may cause them much more harm then the benefits they may get (and what are they after all!)
What on earth are you talking about?
I suspect the major reason for the Windows behavior is that the driver gets polled for the version it was intended for at install or load time and Windows says no to further operation if it is less than some value. As a result, modifying the driver to do no more than say it is for a higher version is enough for it to suddenly work with what is really unmodified code. Perhaps with minor changes but we're not talking about the way it can be in linux where the whole interface to the class of hardware is changed enough that the driver has to have some re-write (not a massive amount usually). But then, which one is the friendlier OS behavior? Saying no to a perhaps working driver in order to promote development claiming to support your shiny new OS version or saying to driver vendors that the OS has changed and modified drivers are needed to support these named changes? Which you are welcome to grep the kernel for all instances of and fix yourself if you please. It might be promoted as a problem on linux but I think I agree, the linux behavior is much friendlier to developers and users.
I could be wrong, but I'm pretty sure the Windows driver interface hasn't changed since Windows 2000 was released.
There are two exceptions to this: Sound Drivers and Display Drivers.
The former changed when Windows "enhanced" sound drivers in Windows Vista. And by "enhanced" I mean such useful things as killing hardware acceleration in order to have separate volume sliders for each app and adding effects like making things sound like they were in a Bathroom or Auditorium.
The latter changed when Windows added desktop compositing, also in Windows Vista... and has continued changing as Microsoft realizes that some of the original assumptions they had were faulty... such as having a copy of each window's draw area in both system and video memory for GDI windows*.
* Which, as far as I know, is all non-fullscreen windows.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Their Linux drivers are open source. What "secret methods" are you smoking?
This is the prime reason why I'm not moving to Wayland and I'm sticking with X11 for the time being: ssh -X.
Wrong LFN, that one's the GNAA-approved release.
Who cares what the Intel rejects support. They're a bunch of rejects.
The mind conceives, the body achieves, the spirit manifests.
[Multi-window multitasking is] not really a market segment it is a use case.
Every use case, such as multi-window multitasking, has a corresponding market segment of people who regularly use it. Page 4 of an Ars Technica article about OS features useful to the market segment of creative professionals (discussion) mentions multi-window multitasking features, and page 5 decries Microsoft's focus on retooling its OS for "consumption" (passive viewing of works created by others) of one thing at a time.
Hardware acceleration of audio is pointless today given how little system resources it takes to mix multi-channel audio in realtime... but apart from that, both WDDM and UAA introduced in Vista moved large parts of the graphics and sound drivers out of the kernel, which is a huge stability gain.
Drivers for two specific types of hardware changed. Everything else (input devices, printers, SATA, north/south-bridge, etc...) didn't.
No, the issue with moving to newer versions of Windows with older hardware is that the manufacturers didn't make 64-bit drivers for those devices. Windows XP 64-bit was basically non-existent and had very little driver support. Vista 64-bit appeared in small numbers, while win7 64-bit made up the majority of win7 installs iirc.
Oh, did I mention 32-bit Windows drivers don't work on 64-bit Windows?
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011