intel refuses to support XMir

[glenfordwilliams]

In an interesting change of events, the mainline Intel Linux graphics driver has reverted the patch to support XMir -- the X11 compatibility layer for the Mir Display Server in Ubuntu Linux.

This week there was the surprise of the Intel 3.0 Linux DDX driver coming and with it SNA acceleration is enabled by default and it also integrated support for XMir. There's small work needed to the DDX X.Org graphics drivers to be able to support running XMir, similar to XWayland for Wayland users. The support was merged as Canonical said the XMir API should be stable.

However, this morning the XMir work was reverted. In releasing a new 3.0 xf86-video-intel driver snapshot, Intel's Chris Wilson wrote in a Git commit:

We do not condone or support Canonical in the course of action they have chosen, and will not carry XMir patches upstream.

-The Management

source -http://phoronix.com/forums/showthrea...Mir#post355694

cant say i never expected something like this to happen

[carey]

<[redacted]> they won't accept xmir patches from canonical or at canonical?
<[redacted]> [redacted]: From, and it's not like it's odd that they refuse to include code that will only be used by one distribution.

-- *a Freenode channel*

Let's say that no one wants to pollute Wayland with any specialized code as it will be just a display protocol and nothing else. Imagine if HTTP or FTP had instructions that made it behave differently based on what platform it was dealing with.

[glenfordwilliams]

looking at it from a different perspective intel may be in trouble come to think of it because most of the machines that come preinstalled with a version of ubuntu have intel gpus

[jayrulez]

-- *a Freenode channel*

Let's say that no one wants to pollute Wayland with any specialized code as it will be just a display protocol and nothing else. Imagine if HTTP or FTP had instructions that made it behave differently based on what platform it was dealing with.

XMir has nothing to do with Wayland.

On another note: Intel is invested in Tizen which Ubuntu Touch will compete directly with. Tizen uses Wayland which gives Intel motive to prevent or hinder progression and adoption of Mir.

Their move is not really surprising.

[carey]

XMir has nothing to do with Wayland.

On another note: Intel is invested in Tizen which Ubuntu Touch will compete directly with. Tizen uses Wayland which gives Intel motive to prevent or hinder progression and adoption of Mir.

Their move is not really surprising.

I stand corrected, but because of the graphic server landscape among Unix-likes and because Wayland is going to try to be a protocol and is being worked on so openly, you can bet it will make it to kernel. *BSD, Mac and Windows all come with graphics ready to run out of the box. Linux usually took some configuration to get going properly.

Therefore, as much as Mir claims to be independent it will undoubtedly have to interact with Wayland since most libraries will already be shipping with Wayland support. So far Mir development is being done in secret a la Reiser4. The developers don't like that. It is like being introduced to a subject at university a few days before final exams.

Remember AIGLX vs XGL? This is quite similar. Thing is Mir's methodologies are currently unknown. What is Canonical going to do? Fork everything? or are they planning to make all their base inhouse and leave everyone out? I bet we will be looking at a carefully contrived Linux split by Canonical: they will have to continue on a commercial fork of Linux by forcing some exception in licensing, just like Android. I bet when we check out Toybox and company, Canonical has been funding that?

[jayrulez]

I think you need a bit more intimate knowledge of the situation before you comment so confidently about it.

I stand corrected, but because of the graphic server landscape among Unix-likes and because Wayland is going to try to be a protocol and is being worked on so openly, you can bet it will make it to kernel.

Wayland will not become a part of the Linux kernel. Wayland along with a wayland compositor is just a layer to replace X. X was never a part of the Linux kernel.

*BSD, Mac and Windows all come with graphics ready to run out of the box. Linux usually took some configuration to get going properly.

This is a apples to orange comparison. Linux is just a Kernel. Linux is not distributed with a display server. Distributions layer whatever they want on top. *BSD use the same display and GUI technology as Linux currently.

Therefore, as much as Mir claims to be independent it will undoubtedly have to interact with Wayland since most libraries will already be shipping with Wayland support.

???

So far Mir development is being done in secret a la Reiser4. The developers don't like that. It is like being introduced to a subject at university a few days before final exams.

Mir is publicly developed. See the launchpad page: http://launchpad.net/mir
Mir was in development about a mere 6 months before it was publicized. It has been developed in public for way longer than that.

Remember AIGLX vs XGL? This is quite similar. Thing is Mir's methodologies are currently unknown.

http://launchpad.net/mir
https://wiki.ubuntu.com/Mir/

What is Canonical going to do? Fork everything? or are they planning to make all their base inhouse and leave everyone out? I bet we will be looking at a carefully contrived Linux split by Canonical: they will have to continue on a commercial fork of Linux by forcing some exception in licensing, just like Android. I bet when we check out Toybox and company, Canonical has been funding that?

What exactly has Canonical forked?

Please do not pay lip service to the propaganda perpetuated by certain entities whether unknowingly (in your case) or by dubious efforts to spread misinformation.

[carey]

I think you need a bit more intimate knowledge of the situation before you comment so confidently about it.


Wayland will not become a part of the Linux kernel. Wayland along with a wayland compositor is just a layer to replace X. X was never a part of the Linux kernel.

This is a apples to orange comparison. Linux is just a Kernel. Linux is not distributed with a display server. Distributions layer whatever they want on top. *BSD use the same display and GUI technology as Linux currently.

At present X is a server application. It is not the same across systems. Linux distros have a huge backend difference from *BSDs. One time we used to create config files with Xorg -configure. Now, doing so usually results in breakage. You are encouraged instead to make adjustments using modular config files. On *BSDs Xorg -configure does not break things.

Linux also has more going on in the background than is supported by *BSDs: KMS is only just coming to them and binary drivers don't usually work with non-Linux.

???

Mir is publicly developed. See the launchpad page: http://launchpad.net/mir
Mir was in development about a mere 6 months before it was publicized. It has been developed in public for way longer than that.

http://launchpad.net/mir
https://wiki.ubuntu.com/Mir/

What exactly has Canonical forked?

Please do not pay lip service to the propaganda perpetuated by certain entities whether unknowingly (in your case) or by dubious efforts to spread misinformation.

See what ignorance causes? Thanks for being a down-to-earth person. I visited the links, and Mir is a good project. It is following the tradition of providing options as solutions. As a user, I have experienced how hard adapting to forced changes can be (sysvinit -> systemd on Arch Linux).

There is talk going on about Wayland replacing Xorg. Lots of people want that to happen. But, there are others who say replacing something that has been working satisfactorily for more than 2 decades with a newcomer is becoming a bad habit in Linux kernel development. The seniors are encouraging options, not replacements.

I am not a developer nor a programmer. With these things I get easily misled. But 1 thing is certain: Linux* development is breaking, bloating --and some other bad Bs -- much that was good. There is too much that is being piled onto known bad code. ReactOS fished out a deep bug the other day(http://reactos.org/pita-bugs-part-3). (They say EFI is responsible.) Linux devs also stumbled across a USB awakening bug, but unlike other those OS Linux just takes rough patches and move on til they can fix it. Seeing as the kernel is many places right now, time is a luxury.

What saves the linux kernel is that you are able to flip builds options. As long as something cumbersome and dangerous does not become a necessity, the kernel should be fine?

I don't think there was ever a bad war in FOSS development. Even though the wrong product may have won, we still get benefits, because choices always remain. So, more choices, less SPOFs.

Addendum:

I agree. Intel is being mischievous ... again. They have been stabbing many in the back. They drew Apple from PPC, which [hearsay] "was superior", then stuck them with security crap they never had to handle; they reneged on deals with NVidia; they killed Meego ( a previous favourite of mine) for no reason other than to sabotage Nokia (though Nokia is just as bad); I bet they have been playing dirty with AMD and the other processor makers too. As much as Intel has been responsible for much of the tech in systems now, karma is still a brindled witch that bites.