If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

We will see what happens when its not distro-specific anymore when/if MIR runs on other distros. time will tell.

*If* that ever happens (and I think it unlikely, myself), then I'd expect the KDE developers to at least consider accepting the patches. But even then, I'd expect them to be judging on technical merits, and from what we know about Mir being an unstable target in terms of API (as the Mir devs acknowledge), they may still be reluctant to accept them without some guarantee of stability from the Mir upstream...

Comment

Probably Mir, as it was several months in development, before it was announced. That's what Canonical said and not neglected by NVidia/AMD.

Well, considering a few facts about the whole situation, if they did tell nVidia and AMD of Mir before the public announcement, they (the management, who calls the shots on this subjects) are just a bunch of douchebags. They didn't tell the LightDM maintainer, who they expected since the original announcement to support Mir, even when AFAIK he's a Canonical employee, they just kept with the official statement that they'd use Wayland, when they knew six months ahead that they wouldn't (if they still expected to use Wayland, they wouldn't even start all the work on Mir), but they do tell nVidia? Not only they are liars, they are total jerks.

But it's not a surprise, it has always been the case, and it's just what you'd expect from them: they are looking a what it will cost them to support something, and what they will gain, and when. Then they make decisions based on that. But until there is actual support, they'll never confirm anything. If you ask them about mir support, you'll get the same answer.

Comment

BTW, is there any write-up which deals with the complexity of an EGL driver for Wayland/Mir compared to an X driver?

AFAIK, some stuff is delegated to the driver, like multi-monitor handling.
OTHO, it sounds like a driver for Wayland/Mir is far easier to support for AMD/NVidia as you have not to deal
with all the 2d-cruft present/required for X (which causes many problems and burns lots of man hours, I guess).

Comment

BTW, is there any write-up which deals with the complexity of an EGL driver for Wayland/Mir compared to an X driver?

AFAIK, some stuff is delegated to the driver, like multi-monitor handling.
OTHO, it sounds like a driver for Wayland/Mir is far easier to support for AMD/NVidia as you have not to deal
with all the 2d-cruft present/required for X (which causes many problems and burns lots of man hours, I guess).

Is this correct?

Before I write anything else, I must make you notice you should take what I'm about to say with a grain of salt, because my knowledge in the area is too shallow.
But, as I see it, what you said is correct by the wrong causes. It doesn't need to deal with X specifics, which are an extra to the support they need to add just for running on Windows (which is their main target in general because of market share), but supporting 2D has nothing to do with the X specifics. I don't know if OpenGL and EGL deals with it, but some cards (I'm not sure if modern cards still ship it) have a 2D engine and it could be managed by a driver even with no X. The problem would be, in the case OpenGL and its derivatives doesn't deal with it, you need another generic interface.
About the complexity, I guess it's the same as an OpenGL driver, since AFAIK is a specification derived from it.

Comment

*If* that ever happens (and I think it unlikely, myself), then I'd expect the KDE developers to at least consider accepting the patches. But even then, I'd expect them to be judging on technical merits, and from what we know about Mir being an unstable target in terms of API (as the Mir devs acknowledge), they may still be reluctant to accept them without some guarantee of stability from the Mir upstream...

I should point out that the Mir devs have retracted the statement about the API being unstable so we have to assume that is no longer the case.
Furthermore, in relation to the KWin team, as I said before they have the right to rip out any code that introduces bugs and vulnerabilities as seen when they dumped their tiling window function much to the dismay of the community.
That said, it would be up to the Canonical team to supply those patches in the first place, but there should be no reason for the KWin team to reject those contributions outright simply because they're distro specific.

And an apology is an apology. Some people can be stubborn and not accept it, but that doesn't negate the fact that it exists.

But it's not a surprise, it has always been the case, and it's just what you'd expect from them: they are looking a what it will cost them to support something, and what they will gain, and when. Then they make decisions based on that. But until there is actual support, they'll never confirm anything. If you ask them about mir support, you'll get the same answer.

Well, that definitely has more substance than pure speculation. I take back what I said about NVidia and Wayland. Still, I think it's more about supporting both, Mir and Wayland through EGL.

Comment

That said, it would be up to the Canonical team to supply those patches in the first place, but there should be no reason for the KWin team to reject those contributions outright simply because they're distro specific.

Upstream will and does often reject distro specific patches across many free software projects because maintenance and testing is a shared burden not just for the specific distro but also for the upstream developers who are more often than not, volunteers. Otherwise there is no reason, those patches couldn't just stay in the distro repository in the first place.

Comment

I should point out that the Mir devs have retracted the statement about the API being unstable so we have to assume that is no longer the case.

No, we have NOT to assume that.
If you retract one time, you can retract another time and so on. And in case of Ubuntu, they seem able to retract an impressive frequency.
Ubuntu: "We will utilize wayland"
Ubuntu: "We need to retract: we will utilize Mir because wayland repeats X's mistake"
Ubuntu: "We need to retract again: we will utilize Mir, but wayland does not suffers the same X problems"
Ubuntu: "Mir is protocol agnostic (?) and tailored around unity, so API can be changed every times it needs."
Ubuntu: "We need to retract: API no more begin unstable... bla bla bla"

Comment

I should point out that the Mir devs have retracted the statement about the API being unstable so we have to assume that is no longer the case.

That's interesting. Where did you see that?

That said, it would be up to the Canonical team to supply those patches in the first place, but there should be no reason for the KWin team to reject those contributions outright simply because they're distro specific.

I somewhat agree, but:

If Canonical is supplying the patches, and Canonical is the only ones using the patches, what does it even need to go upstream for? The only real reason would be to get upstream to maintain it over time, so Canonical doesn't have to do so anymore. That is asking them to take on more work just to help out Canonical, and it doesn't seem like they are in the mood to do so right now.