X.Org Server 1.20 RC4 Released, EGLStreams For XWayland Might Still Land

[GizmoChicken]

Day-to-day usable experience doesn't mean completely bug-free. This is when most of the work had already been done.

GNOME 3.10 (September 2013) was the first release which contained experimental Wayland support, and during the six months prior GNOME 3.9 cycle, the direction and foundational work in GNOME's Wayland support had been laid out.

https://wiki.gnome.org/Initiatives/Wayland

So yes, even at XDC 2013 it was too late. Work was already long underway.

Considering that Nvidia didn't propose Wayland, I think it's pretty amazing how quickly they began working on ways to support Wayland under their driver.

In any case, I demonstrated to you that Nvidia had been discussing its work with the community at least one year earlier than you had realized, yet that's still "too late" for you. Well, based on what was said in that talk and others, I could, if I had the desire to do so, probably find additional disclosures from earlier in 2013, and perhaps even from 2012. But something tells me you've already concluded that anything done by Nvidia after GBM had been release in 2011 would be "too late" for you. So I won't bother.

About NVidia-friendly distributions having to carry Wayland patches, I believe this is where the maintenance burden should go. Those users interested get their distros to do the work. It is not that they each need to maintain a separate XWayland-EGLStreams implementation, it can easily be shared between the distros without having this in mainline.

You do realize that a Red Hat employee has contributed much (most?) of the code for supporting XWayland EGLStreams, right? Something tells me that, if Red Hat refused to contribute the code to Xorg, but had instead only patched their own distributions, the community would be apoplectic, claiming that Red Hat sought an unfair advantage.

But sure, just because you are "indifferent" toward Nvidia, let's shift even more burden downstream to small groups (like Solus) that want to support EGLStreams. /s

[chithanh]

I guess we are not finished with our exchange of ideas yet.

Due to the length of the discussion it seems that you have forgotten what I actually wrote and are now attacking strawmen. So I say it again: GBM implementations in Wayland compositors trace back to before NVidia talked to the community about using EGLStreams in Wayland.

From how the XDC 2013 talk is worded, it seems that this was the initial communication attempt. So I unless you discover earlier references, guess we can agree on the following timeline:

22 June 2011: GBM patches for Mesa posted, for all Gallium3D and Intel classic drivers.
23 June 2011: Initial GBM support for wayland-compositor (now called weston)
7 November 2011: Initial GBM code in GNOME mutter
14 March 2013: Enlightenment/EFL announces their support for Wayland
24 September 2013: NVidia talks about EGLStreams at XDC
25 September 2013: GNOME 3.10 releases with experimental Wayland support (after 6 months in development)
28 February 2014: Enlightenment Evas with Wayland GBM backend released
24 September 2014: GNOME 3.14 releases which works reasonably well on Wayland
10 October 2014: NVidia directly proposes EGLStreams for Wayland, community response: "no way"

"pretty amazing how quickly". Yeah right.

In any case, I demonstrated to you that Nvidia had been discussing its work with the community at least one year earlier than you had realized, yet that's still "too late" for you. Well, based on what was said in that talk and others, I could, if I had the desire to do so, probably find additional disclosures from earlier in 2013, and perhaps even from 2012. But something tells me you've already concluded that anything done by Nvidia after GBM had been release in 2011 would be "too late" for you. So I won't bother.

Nonsense. You did not demonstrate anything relevant to the discussion.
If you look at the timeline, there was the whole gap between late 2011 and early 2013, when not much happened. This is where NVidia should have engaged with the community. Only by XDC 2014 it was clear that NVidia would not support GBM and instead pushing EGLStreams for Wayland (and got soundly rejected).

You do realize that a Red Hat employee has contributed much (most?) of the code for supporting XWayland EGLStreams, right? Something tells me that, if Red Hat refused to contribute the code to Xorg, but had instead only patched their own distributions, the community would be apoplectic, claiming that Red Hat sought an unfair advantage.

What? The Red Hat X server package is open source, how can they keep it to themselves?
Also I am fully aware that the XWayland patch comes from Red Hat. The EGLStreams support for GNOME mutter came from Red Hat too.

But sure, just because you are "indifferent" toward Nvidia, let's shift even more burden downstream to small groups (like Solus) that want to support EGLStreams. /s

I am indifferent towards NVidia proprietary driver users, but I can still express preference towards not burdening mainline with things that are useful only in combination with the NVidia proprietary driver. That burden is better not carried by the whole community, but instead carried by Red Hat and other NVidia-friendly distributions (and they can share the burden between them no problem). That small group you seem to care so much about needs not go alone.

[GizmoChicken]

I guess we are not finished with our exchange of ideas yet.

I was finished when I wrote "Please consider our ideas to have been exchanged." But you won't go away.

it seems that you have forgotten what I actually wrote and are now attacking strawmen.

Perhaps you have forgotten what you wrote:

"I too hope that this won't get merged. If a distro wants to cater to their NVidia proprietary driver users, they can apply the EGLStream patches themselves. Once the common API that meets the needs of both the developer community and NVidia emerges, those patches can be dropped and forgotten about.
. . .

"So your users locked themselves into a proprietary technology controlled by a single vendor? And there is no way out for them? That's too bad but they deserve all the consequences of this short-sighted decision. Same thing I tell people who whine about how much Microsoft Office costs and how Microsoft is strong-arming their customers into subscription models."

I responded to your post. That was the genesis of this discussion.

And no, I haven't created any straw men. Rather, I have responded to your arguments. For example, you wrote:

"It is fully NVidia's fault for not working with the community between 2011 and 2014 and then suddenly insisting on doing it differently from everyone else."

After your statement, I pointed out the Nvidia had been interacting with the community during 2013 (including at XDC2013) and possibly earlier. So no, don't blame me for your arguments being weak as straw. That's on you.

Nonsense. You did not demonstrate anything relevant to the discussion.

As noted above, you wrote: "It is fully NVidia's fault for not working with the community between 2011 and 2014. . ." To repeat, "I demonstrated to you that Nvidia had been discussing its work with the community at least one year earlier than you had realized," namely at XDC2013, and probably earlier.

If you look at the timeline, there was the whole gap between late 2011 and early 2013, when not much happened. This is where NVidia should have engaged with the community.

"God bless you, Captain Hindsight! God bless you!"

"pretty amazing how quickly". Yeah right.

All things considered, yes, I think it's pretty amazing how quickly Nvidia began working on ways to support Wayland under their driver. At the earliest stages, Wayland was far from being a sure thing. Indeed, many argued against Wayland with a similar furiousity that some argue (and still argue) against systemd. In that environment, it's not unreasonable for a company like Nvidia to wait for the dust to settle before moving forward. From that perspective, especially considering that it's now 2018 and Wayland is still struggling, the "gap between late 2011 and early 2013" (roughly the gestational period for an elephant) is actually a very short span of time. Aircraft carriers don’t turn on a dime.

Only by XDC 2014 it was clear that NVidia would not support GBM and instead pushing EGLStreams for Wayland (and got soundly rejected).

What's your point? Aren'tyou attempting to argue against merging Xwayland EGLStreams patches into mainline now, in 2018?

If you are attempting to argue against merging Xwayland EGLStreams patches into mainline now, in 2018, your continued references to 2014 are many years out-of-date. Furthermore, you have yet to provide a compelling argument why GBM support and Xwayland EGLStreams support can't coexist in Xserver now, in 2018.

If you are still raging against EGLStreams support for Wayland in general, as you pointed out, the Mutter community merged EGLStreams for Wayland in November 2016. So "[2016] is where [you] should have engaged with the community." Right?

And in any case, no, as I have previously pointed out, Nvidia suggested a preference for EGLStreams during XDC2013, and probably earlier.

What? The Red Hat X server package is open source, how can they keep it to themselves?

Did you not read what I wrote? I wrote: "Something tells me that, if Red Hat refused to contribute the code to Xorg, but had instead only patched their own distributions, the community would be apoplectic, claiming that Red Hat sought an unfair advantage." (Emphasis added.)

That is, I wrote about the implication of Red Hat refusing "to contribute the code to Xorg" and did not in any way suggest that "they keep it to themselves." And if you didn't notice, what I wrote is entirely consistent with what you suggest, namely "NVidia-friendly distributions having to carry Wayland patches" without reliance on Xorg.

The above in mind (namely that I did not suggest Red Hat would "keep [anything] to themselves"), please note that "X Window System distribution is a compilation of code and documentation from many sources" and that "most of these licenses are based on the MIT, X Consortium, or BSD (original and revised) licenses." See https://www.x.org/releases/X11R7.6/d...g-docs/License. See https://www.x.org/releases/X11R7.6/d...s/License.html

So yes, if using only those bits of code in Xserver that is distributed under an appropriate "permissive licenses" (which is the situation for much of the code in xserver), in theory, an improved version of xserver could be released as a blob under a proprietary license. Red Hat won't do that. But they could if they wanted to.

I am indifferent towards NVidia proprietary driver users, but I can still express preference towards not burdening mainline with things that are useful only in combination with the NVidia proprietary driver. That burden is better not carried by the whole community, but instead carried by Red Hat and other NVidia-friendly distributions (and they can share the burden between them no problem). That small group you seem to care so much about needs not go alone.

Under your plan, who should host the "shared" XWayland EGLStreams patches? And if not hosted by Xorg, are you seriously suggesting that an entirely new organization should be created just because you are "indifferent towards NVidia proprietary driver users"?

I'll reiterate: In addition to hurting Nvidia users, your approach hurts small distributions that want to support EGLStreams for XWayland. Distributions funded by the likes of Canonical and Red Hat have the manpower to maintain downstream patches. The small guys don't. Also, your approach will likely lead to distro-specific implementations, which most community members consider a bad thing.

For what it's worth, I use one of the distributions that has the manpower to maintain downstream patches. But I still encourage upstream submission of technically competent patches, which is good for everyone, not just smaller distributions.

As I wrote in my first response to you, “Unless you have a technical (and not merely idealogical) argument against supporting EGLStreams in Xwayland, please don’t stand in the way.”

[chithanh]

I was finished when I wrote "Please consider our ideas to have been exchanged." But you won't go away.

Ah, you want to have the last word in the discussion. Fine with me, I can continue for a while.

And no, I haven't created any straw men. Rather, I have responded to your arguments. For example, you wrote:

"It is fully NVidia's fault for not working with the community between 2011 and 2014 and then suddenly insisting on doing it differently from everyone else."

After your statement, I pointed out the Nvidia had been interacting with the community during 2013 (including at XDC2013) and possibly earlier. So no, don't blame me for your arguments being weak as straw. That's on you.

There was no interaction worth mentioning in XDC 2013. NVidia presented about EGLStreams, and casually mentioned in the very beginning how this could be the way for them for Wayland support. They didn't get into detail about that until XDC 2014 (and this is where the community realized what NVidia's intentions were, and told them "no"). The XDC 2013 talk disproves nothing of what I said.

You are attacking a straw man at best and putting words in my mouth at worst.

As noted above, you wrote: "It is fully NVidia's fault for not working with the community between 2011 and 2014. . ." To repeat, "I demonstrated to you that Nvidia had been discussing its work with the community at least one year earlier than you had realized," namely at XDC2013, and probably earlier.

As you obviously didn't understand either what I said nor what the talk said, this point of yours is moot.

All things considered, yes, I think it's pretty amazing how quickly Nvidia began working on ways to support Wayland under their driver. At the earliest stages, Wayland was far from being a sure thing. Indeed, many argued against Wayland with a similar furiousity that some argue (and still argue) against systemd. In that environment, it's not unreasonable for a company like Nvidia to wait for the dust to settle before moving forward. From that perspective, especially considering that it's now 2018 and Wayland is still struggling, the "gap between late 2011 and early 2013" (roughly the gestational period for an elephant) is actually a very short span of time. Aircraft carriers don’t turn on a dime.

And all this work becomes ultimately inconsequential because NVidia didn't talk nor cooperate in time.
Besides, mesa support for GBM was written by a single developer in a few months, and not for a single driver, no, for all of them.

And that there is/was a Wayland controversy that is comparable to the systemd controversy is an absurd claim to make.

What's your point? Aren'tyou attempting to argue against merging Xwayland EGLStreams patches into mainline now, in 2018?

If you are attempting to argue against merging Xwayland EGLStreams patches into mainline now, in 2018, your continued references to 2014 are many years out-of-date. Furthermore, you have yet to provide a compelling argument why GBM support and Xwayland EGLStreams support can't coexist in Xserver now, in 2018.

I tried to explain why the Wayland EGLStreams reception by many in the community is the one we are seeing today. Which must be completely surprising to you, given it was "pretty amazing how quickly" NVidia started supporting Wayland. Such interaction. Much discussion with the community. Not.

And I used it to explain when it became too late. 2018 is past 2014, so if 2014 is too late then 2018 is even more too late.

Reality check:
Look at discussions in the community about Wayland EGLStreams. Here for example: https://lists.freedesktop.org/archiv...ch/027559.html
They refer to XDC 2014, not XDC 2013, as the point when the technical details were presented and the actual interaction happened, and it ended with a "no way".

If you are still raging against EGLStreams support for Wayland in general, as you pointed out, the Mutter community merged EGLStreams for Wayland in November 2016. So "[2016] is where [you] should have engaged with the community." Right?

GNOME community accepted the EGLStreams patches, that was their decision. If they want to carry the burden for NVidia so be it. I would have suggested not to, same thing which I suggest here.

Did you not read what I wrote? I wrote: "Something tells me that, if Red Hat refused to contribute the code to Xorg, but had instead only patched their own distributions, the community would be apoplectic, claiming that Red Hat sought an unfair advantage." (Emphasis added.)

That is, I wrote about the implication of Red Hat refusing "to contribute the code to Xorg" and did not in any way suggest that "they keep it to themselves." And if you didn't notice, what I wrote is entirely consistent with what you suggest, namely "NVidia-friendly distributions having to carry Wayland patches" without reliance on Xorg.

The above in mind (namely that I did not suggest Red Hat would "keep [anything] to themselves"), please note that "X Window System distribution is a compilation of code and documentation from many sources" and that "most of these licenses are based on the MIT, X Consortium, or BSD (original and revised) licenses." See https://www.x.org/releases/X11R7.6/d...g-docs/License. See https://www.x.org/releases/X11R7.6/d...s/License.html

So yes, if using only those bits of code in Xserver that is distributed under an appropriate "permissive licenses" (which is the situation for much of the code in xserver), in theory, an improved version of xserver could be released as a blob under a proprietary license. Red Hat won't do that. But they could if they wanted to.

Do you even read what you write? Even the mere suggestion that Red Hat would make their xserver package proprietary is asinine. So if they had added XWayland EGLStreams only to their X server and not bothered to further contribute it, then it would of course still be open source in any scenario that is even remotely conceivable.

If Red Hat releases this code under MIT/X11/BSD open source licenses then it doesn't open them to justified criticism when they do not additionally post this code to xorg-devel.

Under your plan, who should host the "shared" XWayland EGLStreams patches?

GitHub will be fine. In fact any git repository that is not xorg/xserver mainline.

As I wrote in my first response to you, “Unless you have a technical (and not merely idealogical) argument against supporting EGLStreams in Xwayland, please don’t stand in the way.”

I don't stand in the way, I have no power over what gets accepted and what not. I am only pointing out from the sidelines why I think that not merging this code to mainline is preferable. And that users who locked themselves into poopy proprietary tech had it coming.

[GizmoChicken]

Ah, you want to have the last word in the discussion. Fine with me, I can continue for a while.

You have yet to provide a technical (and not merely idealogical) argument against supporting EGLStreams for Xwayland now, in 2018. So I think you mean that you can continue making the same idealogical arguments.

When you are ready to start making a technical argument (such as what, if anything, the patches are likely to break or disrupt), please do. I'd be eager to read them.

There was no interaction worth mentioning in XDC 2013.

Did you attend XDC 2013? And if so, did you engage James Jones in any discussion regarding EGLStreams? And if you attended, but didn’t engage James Jones in any discussion regarding EGLStreams, why not?

The XDC 2013 talk disproves nothing of what I said.

Admit it. Until I provided the link, you had no idea that Nvidia presented anything related to EGLStreams at XDC 2013. True?

You are attacking a straw man at best and putting words in my mouth at worst.

I created no straw man. Also, I didn’t put any words in your mouth, nor did I type anything on your keyboard.

As you obviously didn't understand either what I said nor what the talk said, this point of yours is moot.

And all this work becomes ultimately inconsequential because NVidia didn't talk nor cooperate in time.
Besides, mesa support for GBM was written by a single developer in a few months, and not for a single driver, no, for all of them.

And that there is/was a Wayland controversy that is comparable to the systemd controversy is an absurd claim to make.

I tried to explain why the Wayland EGLStreams reception by many in the community is the one we are seeing today. Which must be completely surprising to you, given it was "pretty amazing how quickly" NVidia started supporting Wayland. Such interaction. Much discussion with the community. Not.

And I used it to explain when it became too late. 2018 is past 2014, so if 2014 is too late then 2018 is even more too late.

Reality check:
Look at discussions in the community about Wayland EGLStreams. Here for example: https://lists.freedesktop.org/archiv...ch/027559.html
They refer to XDC 2014, not XDC 2013, as the point when the technical details were presented and the actual interaction happened, and it ended with a "no way".

In the above, I’m seeing lots of repetition regarding what Nvidia did, and didn’t do, during the period from 2011 to 2014. Nothing new. But I’m not seeing any technical arguments (such as what, if anything, the patches are likely to break or disrupt) against supporting EGLStreams in Xwayland now, in 2018. Did I miss something?

GNOME community accepted the EGLStreams patches, that was their decision. If they want to carry the burden for NVidia so be it. I would have suggested not to, same thing which I suggest here.

In 2016, when the GNOME community accepted the EGLStreams patches into Mutter, although KWin may have begun adding Wayland support, arguably KWin wasn’t yet ready for production use as a Wayland compositor. So, arguably, the Mutter community represented the entirety of usable Wayland compositors in 2016. And even if you don’t accept that KWin wasn’t yet usable as a Wayland compositor, the Mutter community undeniably represented the the largest faction of those using Wayland compositors in 2016. So if you are still raging against EGLStreams support for Wayland in general, again, by your own logic, "[2016] is where [you] should have engaged with the community." Or at least that’s what “Captain Hindsight” would say.

Moreover, although the need for EGLStreams support for Xwayland was foreseeable in 2016 (and therefore find that that your claim accrued in 2016), you are only now, in 2018, voicing your opposition to EGLStreams support for Xwayland, after nearly all the work has already been done. Sorry, but I arbitrarily degree (much like you arbitrarily decree) that two years after your claim accrued is “too late” to bring your claim. The statute of limitations has run. Claim denied and case dismissed. Or at least that’s what “Judge GizmoChicken” would say. (See, you’re not the only one who can contrive an absurd argument asserting that it is “too late” to perform an action.)

Do you even read what you write? Even the mere suggestion that Red Hat would make their xserver package proprietary is asinine. So if they had added XWayland EGLStreams only to their X server and not bothered to further contribute it, then it would of course still be open source in any scenario that is even remotely conceivable.

I read what you wrote. You asked “how can [Red Had] keep it to themselves?” Why you asked such an “asinine” question, I don’t know. But I answered it nonetheless. And I stand by my answer.

If Red Hat releases this code under MIT/X11/BSD open source licenses then it doesn't open them to justified criticism when they do not additionally post this code to xorg-devel.

I’m pleased that you feel that way. But if you haven’t noticed, everyone is criticized for everything in the open source community, whether justified or not. So I continue to believe that, unless Red Hat at least tries to merge these patches into mainline (rather than only patch their own distributions), the community would be apoplectic, claiming that Red Hat sought an unfair advantage, or least complaining that Red Hat doesn’t “give back” to upstream.

With the above in mind, maybe Red Hat doesn’t truly want the patches merged into mainline. Maybe they actually only want to patch their own distributions. And maybe you are here to act as a plant to provide them cover for doing so. (I jest. You’re clearly not a plant of that sort.)

GitHub will be fine. In fact any git repository that is not xorg/xserver mainline.

You proposed the idea, so you own it. Please set up the git repository for all of the patches that don’t comply with your personal standards, and be prepared to administer that git repository.

Or here’s another option: Create your own fork of Xserver, and strip out any patches that don’t comply with your personal standards. But I suspect you won’t receive much interest in your fork.

I have no power over what gets accepted and what not.

Finally, we agree on something! Having finally reached agreement on something, I truly hope this concludes our discussions.

[chithanh]

You have yet to provide a technical (and not merely idealogical) argument against supporting EGLStreams for Xwayland now, in 2018. So I think you mean that you can continue making the same idealogical arguments.

Others like the KWin developer have already made the technical argument, no need to do it again. I have just verified (and explained to you) why I think that this argument is plausible and not only theoretical, by pointing to a real-world case where such problems actually manifested.

Did you attend XDC 2013? And if so, did you engage James Jones in any discussion regarding EGLStreams? And if you attended, but didn’t engage James Jones in any discussion regarding EGLStreams, why not?

Admit it. Until I provided the link, you had no idea that Nvidia presented anything related to EGLStreams at XDC 2013. True?

I can only repeat the suggestion to educate yourself. Look at the community discussions about Wayland EGLStreams. They refer to XDC 2014 as the point when it became clear what NVidia wanted. Quoting NVidia from XDC 2014: "Based on the EGLDevice and EGLOutput ideas discussed at XDC 2013, we'd like to propose an alternative approach to [GBM] filling the above roles." XDC 2014 is when the actual specifics were talked about.

The XDC 2013 talk I did not know about, but there was nothing in it which left an impression on the community. So the point that the cooperation started only in 2014 still stands. And in any case it was too late at that time as well. If NVidia had made their XDC 2014 talk a year earlier already, it would probably have been received in the same way.

I read what you wrote. You asked “how can [Red Had] keep it to themselves?” Why you asked such an “asinine” question, I don’t know. But I answered it nonetheless. And I stand by my answer.

There is no conceivable way that Red Hat makes their xserver package proprietary. This would go so much against company culture that it would rather cause a rebellion and mass exodus of employees before actually happening. This means the only possible interpretation of the idea "not contributing" is that they keep it in their own repositories as open source, and not submit it for mainline inclusion. Nothing objectionable with that.

The rest of your point is therefore moot.

You proposed the idea, so you own it. Please set up the git repository for all of the patches that don’t comply with your personal standards, and be prepared to administer that git repository.

Or here’s another option: Create your own fork of Xserver, and strip out any patches that don’t comply with your personal standards. But I suspect you won’t receive much interest in your fork.

As I said, I am indifferent to what exactly happens with the code as long as it is not mainlined. The solution with github is no better or worse than those users switch to Windows for all I care.

But if the code is mainlined, then it becomes the entire community's problem.

Having finally reached agreement on something, I truly hope this concludes our discussions.

Why? I think raising mutual understanding between users through dialogue is never a bad thing. At some point the discussion can become heated, but in the end it helps understanding why someone thinks the way they do (even if one disagrees).

[GizmoChicken]

But if the code is mainlined, then it becomes the entire community's problem.

If the code is merged, then it becomes the entire community's benefit. Those who want to partake in the benefit, can. Those who don't want to partake in the benefit, need not. Maintaining the merged code is primarily the burden of those who have a vested interest in maintaining it. Sure, there is a risk that the code may, eventually, be abandoned. But that risk exists with all community maintained code. At least here, those who have a vested interest in maintaining the code would appear to include Red Hat. I think I think Red Hat can handle it, don't you? And really, wouldn't you rather the code be maintained by Red Hat (relatively trustworthy) rather than by Nvidia?

There is no conceivable way that Red Hat makes their xserver package proprietary.

in my response to your question ("how can [Red Hat] keep it to themselves?"), I wrote, among other things, the following: "Red Hat won't do that. But they could if they wanted to."

I am indifferent to what exactly happens with the code as long as it is not mainlined. The solution with github is no better or worse than those users switch to Windows for all I care.

Thanks for your honesty.

The XDC 2013 talk I did not know about

I knew it! And thanks again for your honesty.

Look at the community discussions about Wayland EGLStreams. They refer to XDC 2014 as the point when it became clear what NVidia wanted. Quoting NVidia from XDC 2014: "Based on the EGLDevice and EGLOutput ideas discussed at XDC 2013, we'd like to propose an alternative approach to [GBM] filling the above roles."

"In the above, I’m seeing lots of repetition regarding what Nvidia did, and didn’t do, during the period from 2011 to 2014. Nothing new. But I’m not seeing any technical arguments (such as what, if anything, the patches are likely to break or disrupt) against supporting EGLStreams in Xwayland now, in 2018. Did I miss something?"

But I do thank you for providing a quote from the slides presented by Andy Ritger at XDC 2014. That quote further invalidates your statement ("It is fully NVidia's fault for not working with the community between 2011 and 2014. . .") and further validates my statement ("Nvidia had been interacting with the community during 2013 (including at XDC2013) and possibly earlier."). Also, please refer the the slides from the presentation given by James Jones by XDC 2013, and note the proposals relating to EGLStreams.

Others like the KWin developer have already made the technical argument, no need to do it again.

"Being willing to accept a patch if supplied by Nvidia, but unwilling to accept an equally good patch if supplied by a third party, reveals that the resistance isn’t about any technical aspects of the patch. Nor does it support the notion 'to manage two implementations (GBM and EGLStreams) in their codebase' would be constitute an undue 'burden' on the KWin developers, especially if the patches were supplied by others. Rather, the statement underscores that Martin's resistance is about ideology and his dislike for Nvidia."

"You have yet to provide a technical (and not merely idealogical) argument against supporting EGLStreams for Xwayland now, in 2018."

"When you are ready to start making technical argument[s] (such as what, if anything, the patches are likely to break or disrupt), please do. I'd be eager to read them."

I think raising mutual understanding between users through dialogue is never a bad thing. At some point the discussion can become heated, but in the end it helps understanding why someone thinks the way they do (even if one disagrees).

Given that we are both mostly repeating ourselves at this point, I think we pretty much both know what the other thinks by now. But if you want to continue....

"But even if Nvidia did submit their proposal at the last minute, I don't see why it would be a problem. The first solution is not necessarily the best solution. And for that matter, provided that code is properly maintained and doesn't cause conflicts, I don't see a problem with two (or more) solutions being available."

With what, if anything, in the immediately preceding quotation do you agree? With what, if anything, in the immediately preceding quotation do you disagree? Please discuss why you agree and/or disagree.

[chithanh]

If the code is merged, then it becomes the entire community's benefit.

No, it is only to the benefit of a single manufacturer and their customers. That in itself would not be reason to be critical, but in addition this manufacturer leeches off the community by keeping their driver closed, the cooperation with the community is severely lacking and sometimes non-existent, and the customers knowingly buy into this.

in my response to your question ("how can [Red Hat] keep it to themselves?"), I wrote, among other things, the following: "Red Hat won't do that. But they could if they wanted to."

Your original comment was "if Red Hat refused to contribute the code to Xorg, but had instead only patched their own distributions, the community would be apoplectic, claiming that Red Hat sought an unfair advantage."

And in no conceivable scenario "refusing to contribute" can mean that Red Hat would keep the code proprietary. Only someone with complete ignorance of the distro could consider this a possibility.

This means the only reasonable interpretation of this phrase is that Red Hat includes this as open source, but does not submit for upstream inclusion. And that is not grounds for criticism.

"In the above, I’m seeing lots of repetition regarding what Nvidia did, and didn’t do, during the period from 2011 to 2014. Nothing new. But I’m not seeing any technical arguments (such as what, if anything, the patches are likely to break or disrupt) against supporting EGLStreams in Xwayland now, in 2018. Did I miss something?"

"Being willing to accept a patch if supplied by Nvidia, but unwilling to accept an equally good patch if supplied by a third party, reveals that the resistance isn’t about any technical aspects of the patch. Nor does it support the notion 'to manage two implementations (GBM and EGLStreams) in their codebase' would be constitute an undue 'burden' on the KWin developers, especially if the patches were supplied by others. Rather, the statement underscores that Martin's resistance is about ideology and his dislike for Nvidia."

You are still wrong. The issue is two-fold. Why the KWin developer dislikes maintaining two code paths is a complexity issue. Why the KWin developer wants only code from NVidia is a software maintenance issue. As I explained in the Dolphin example, both have manifested in a real-world situation.

But I don't expect you to understand it, because you don't want to understand. You are so fixated on how the KWin developer has an alleged ideological reason for this.

But I do thank you for providing a quote from the slides presented by Andy Ritger at XDC 2014. That quote further invalidates your statement ("It is fully NVidia's fault for not working with the community between 2011 and 2014. . .") and further validates my statement ("Nvidia had been interacting with the community during 2013 (including at XDC2013) and possibly earlier."). Also, please refer the the slides from the presentation given by James Jones by XDC 2013, and note the proposals relating to EGLStreams.

I have seen the presentation, and my point still stands. Note how the presentation slides do not mention Wayland nor GBM.

Find me anyone, any mailing list posting from the community which refers to XDC 2013 as the point when they realized what NVidia wanted wrt. GBM and EGLStreams.

According to Phoronix, NVidia even apologized for the handling of their EGLStreams proposal. I mean, when does NVidia apologize at all? They didn't apologize for the GTX 970 3.5GB RAM issue, they did not apologize for Bumpgate, even when Linus Torvalds called them out for being the worst company he ever had to work with, they remained defiant. And if now they apologize, that should raise an eyebrow.

"You have yet to provide a technical (and not merely idealogical) argument against supporting EGLStreams for Xwayland now, in 2018."

"When you are ready to start making technical argument[s] (such as what, if anything, the patches are likely to break or disrupt), please do. I'd be eager to read them."

Having two rendering paths instead of only one is a major increase in complexity. It will not only cause more work in implementing a compositor, but also make maintenance harder and hinder future progress.

"But even if Nvidia did submit their proposal at the last minute, I don't see why it would be a problem. The first solution is not necessarily the best solution. And for that matter, provided that code is properly maintained and doesn't cause conflicts, I don't see a problem with two (or more) solutions being available."

Disagree.
If the proposal had been strictly better and every driver had benefited, then the community would certainly have given it a warmer reception. This is now being attempted with the new allocator library (but progress is slow, only two commits this year so far...).
If the proposal had come at early stages, then something common could have been worked out before GBM was implemented everywhere.
But instead it came late, and is only useful for NVidia.
The EGLStreams code is not a trivial addition, and that the original author is going to maintain it indefinitely is questionable, as explained before.

With what, if anything, in the immediately preceding quotation do you agree? With what, if anything, in the immediately preceding quotation do you disagree? Please discuss why you agree and/or disagree.

I hope this clears up where I stand.

[GizmoChicken]

No, it is only to the benefit of a single manufacturer and their customers.

You seem to be suggesting that, for a feature to benefit the community, that feature must be used by each-and-every member of the community. If so, that's an absurd suggestion.

In addition to the many members of the community who use Nvidia products, Red Hat (also a member of the community) provides paid support to many users of Nvidia products. So the patches certainly can benefit Red Hat. Indeed, if the patches couldn't benefit Red Hat, I suspect Red Hat employees wouldn't be writing and contributing them.

But sure, the patches may not directly benefit you. I guess that's all you care about.

That in itself would not be reason to be critical, but in addition this manufacturer leeches off the community by keeping their driver closed, the cooperation with the community is severely lacking and sometimes non-existent, and the customers knowingly buy into this.

"Then don’t buy from Nvidia. Problem solved. Now you can focus your efforts on more productive tasks."

Your original comment was "if Red Hat refused to contribute the code to Xorg, but had instead only patched their own distributions, the community would be apoplectic, claiming that Red Hat sought an unfair advantage."

As you correctly point out, I previously wrote: "if Red Hat refused to contribute the code to Xorg, but had instead only patched their own distributions, the community would be apoplectic, claiming that Red Hat sought an unfair advantage." And as I discuss below, I stand by that statement.

And in no conceivable scenario "refusing to contribute" can mean that Red Hat would keep the code proprietary. Only someone with complete ignorance of the distro could consider this a possibility.

This means the only reasonable interpretation of this phrase ["refus[ing] to contribute"] is that Red Hat includes this as open source, but does not submit for upstream inclusion.

Either you are confused by our exchange, or you are attempting to confuse others.

I completely agree that the most reasonable interpretation of the phrase "refus[ing] to contribute" (as found in my earlier statement) is that "Red Hat includes this as open source, but does not submit for upstream inclusion" (as you propose). Indeed, your proposed interpretation of the phrase is what I meant when I first wrote the comment; your proposed interpretation of the phrase is what I meant when I submitted the comment, and your proposed interpretation of the phrase is what I mean by the phrase now.

Yet, in response to my unambiguous statement (which you now seem to understand), you asked: "What? The Red Hat X server package is open source, how can they keep it to themselves?"

As you now point out: "Only someone with complete ignorance of the [Red Hat] distro could consider [Red Hat not releasing code as open source] a possibility." Even so, you asked how Red Hat could avoid releasing their code ("how can they keep it to themselves?"), and I unambiguously answered: "Red Hat won't do that."

I suspect you remember the comments better than you letting on. But just in case you don't, the full comment can be found here:

Did you not read what I wrote? I wrote: "Something tells me that, if Red Hat refused to contribute the code to Xorg, but had instead only patched their own distributions, the community would be apoplectic, claiming that Red Hat sought an unfair advantage." (Emphasis added.)

That is, I wrote about the implication of Red Hat refusing "to contribute the code to Xorg" and did not in any way suggest that "they keep it to themselves." And if you didn't notice, what I wrote is entirely consistent with what you suggest, namely "NVidia-friendly distributions having to carry Wayland patches" without reliance on Xorg.

The above in mind (namely that I did not suggest Red Hat would "keep [anything] to themselves"), please note that "X Window System distribution is a compilation of code and documentation from many sources" and that "most of these licenses are based on the MIT, X Consortium, or BSD (original and revised) licenses." See https://www.x.org/releases/X11R7.6/d...s/License.html

So yes, if using only those bits of code in Xserver that [are] distributed under appropriate "permissive licenses" (which is the situation for much of the code in xserver), in theory, an improved version of xserver could be released as a blob under a proprietary license. Red Hat won't do that. But they could if they wanted to.

To reiterate: You asked "What? The Red Hat X server package is open source, how can they keep it to themselves?" and I answered “Red Hat won't do that.”

Because you asked "how can [Red Hat] keep it to themselves?", in addition to unambiguously stating that "Red Hat won't do that," I explained to you how, under the terms of most "permissive" licenses (and subject to other qualifications), what Red Hat could do "in theory" if they wanted to.

I hope that you now understand our conversation.

And that is not grounds for criticism.

Failure to contribute upstream is often met with criticism in the open source community. And I suspect you know that and are just being obtuse.

The above in mind, personally, I would not criticize Red Hat if they refused to merge their patches upstream. As far as I’m concerned, Red Hat is free to do anything permissible under applicable law. Nonetheless, I stand by my original statement, namely: "if Red Hat refused to contribute the code to Xorg, but had instead only patched their own distributions, the community would be apoplectic, claiming that Red Hat sought an unfair advantage." While I personally feel that such criticism would be unwarranted, if Red Hat doesn't at least attempt to merge the patches into mainline, Red Hat would be criticized for not "giving back" upstream. Not by me, and apparently not by you, but by many in the community, nonetheless.

Why the KWin developer dislikes maintaining two code paths is a complexity issue.

"Being willing to accept a patch if supplied by Nvidia, but unwilling to accept an equally good patch if supplied by a third party, reveals that the resistance isn’t about any technical aspects of the patch. Nor does it support the notion 'to manage two implementations (GBM and EGLStreams) in their codebase' would be constitute an undue 'burden' on the KWin developers, especially if the patches were supplied by others. Rather, the statement underscores that Martin's resistance is about ideology and his dislike for Nvidia."

Why the KWin developer wants only code from NVidia is a software maintenance issue. As I explained in the Dolphin example, both have manifested in a real-world situation.

But I don't expect you to understand it, because you don't want to understand. You are so fixated on how the KWin developer has an alleged ideological reason for this.

"Again, I don’t care whether KWin does, or doesn’t, support EGLStreams." "No one is forcing the KWin devs to implement EGLStreams. The KWin devs are free to implement it, or not implement it."

"But other members of the compositor community, including some Mutter devs and some Mir devs, want to implement EGLStreams, both for Wayland and for XWayland. Providing EGLStreams for XWayland upstream, rather than forcing downstream patches, would reduce the maintenance burden on those Mutter devs and Mir devs, without imposing any additional burden on those KWin devs who don't want to implement EGLStreams. The KWin devs should not stand in the way of the Mutter devs, the Mir devs, or anyone other member of the community, who want to support EGLStreams."

"Millions (hundreds of millions?) of Nvidia cards have been sold, and many commercial users (like the one who you criticized elsewhere in this thread) depend on Nvidia cards. Comparing community interest in supporting Nvidia GPUs to community interest in supporting the Dolphin emulator makes no sense. Or at least it makes no sense to me. But then again, you didn’t get my conception/gestation/childhood metaphor, so I guess we see things differently."

"As mentioned above, many commercial users (again, like the one who you criticized elsewhere in this thread) depend on Nvidia cards." "Sure, there is a risk that the code may, eventually, be abandoned. But that risk exists with all community maintained code. At least here, those who have a vested interest in maintaining the code would appear to include Red Hat. I think Red Hat can handle it, don't you? And really, wouldn't you rather the code be maintained by Red Hat (relatively trustworthy) rather than by Nvidia?"

I have seen the presentation [given by James Jones at XDC 2013], and my point still stands. Note how the presentation slides do not mention Wayland nor GBM.

Let me remind you that you and I are discussing whether support for "EGLStreams for Xwayland" should be merged into mainline Xserver.

"If you are attempting to argue against merging Xwayland EGLStreams patches into mainline now, in 2018, your continued references to [what happened in 2014, 2013, and earlier] are many years out-of-date. Furthermore, you have yet to provide a compelling argument why GBM support and Xwayland EGLStreams support can't coexist in Xserver now, in 2018."

But in any case, "I do [again] thank you for providing a quote from the slides presented by Andy Ritger at XDC 2014. That quote further invalidates your statement ("It is fully NVidia's fault for not working with the community between 2011 and 2014. . .") and further validates my statement ("Nvidia had been interacting with the community during 2013 (including at XDC2013) and possibly earlier."). Also, please refer the slides from the presentation given by James Jones by XDC 2013, and note the proposals relating to EGLStreams."

James Jones made clear during his XDC 2013 presentation that his work applied to Wayland, but wasn't limited to Wayland. That is, his goal was for his work to be window system agnostic, and to "get out of the way of new window systems" whether Wayland, or Mir, or otherwise.

Find me anyone, any mailing list posting from the community which refers to XDC 2013 as the point when they realized what NVidia wanted wrt. GBM and EGLStreams.

Consider that you bring cake to a party, you place that cake in a prominent location, and you invite all party attendees to partake in eating the cake. If the party attendees don't have an appetite for your cake, and later don't rave about your cake after the party, that doesn't negate the fact that you brought cake.

Nvidia discussed preliminary work relating to EGLStreams to the community at a prominent event in 2013, namely at XDC 2013. That the community didn't have a appetite for what Nvidia presented doesn't negate that fact "Nvidia had been interacting with the community during 2013 (including at XDC2013) and possibly earlier," which is what I claimed.

Please also note the last slide presented, in which James Jones invites members of the community to ask "Questions?" about anything presented, and note that James Jones answered several questions asked of him, thereby "interacting with the community."

According to Phoronix, NVidia even apologized for the handling of their EGLStreams proposal. I mean, when does NVidia apologize at all? They didn't apologize for the GTX 970 3.5GB RAM issue, they did not apologize for Bumpgate, even when Linus Torvalds called them out for being the worst company he ever had to work with, they remained defiant. And if now they apologize, that should raise an eyebrow.

You're grasping.

Having two rendering paths instead of only one is a major increase in complexity. It will not only cause more work in implementing a compositor, but also make maintenance harder and hinder future progress.

Let me remind you, again, that you and I are discussing whether support for "EGLStreams for Xwayland" should be merged into mainline Xserver. Also, for a technical argument, I had hoped you would discuss what, if anything, the patches are likely to break or disrupt. But I guess that’s the best you could do, so thanks for trying.

With regard to work related to implementing a compositor, "No one is forcing the KWin devs [or the devs for any Wayland compositor] to implement EGLStreams [or support EGLStreams for Xwayland]. The KWin devs are free to implement it, or not implement it."

As for making maintenance of Xserver harder, "those who have a vested interest in maintaining the code would appear to include Red Hat. I think Red Hat can handle it, don't you? And really, wouldn't you rather the code be maintained by Red Hat (relatively trustworthy) rather than by Nvidia?"

In any case, it seems that you "are still raging against EGLStreams support for Wayland in general." If so, "again, by your own logic, '[2016] is where [you] should have engaged with the community.’"

"Moreover, although the need for EGLStreams support for Xwayland was foreseeable in 2016 (and I therefore find that that your claim accrued in 2016), you are only now, in 2018, voicing your opposition to EGLStreams support for Xwayland, after nearly all the work has already been done. Sorry, but I arbitrarily decree (much like you arbitrarily decree) that two years after your claim accrued is “too late” to bring your claim. The statute of limitations has run. Claim denied and case dismissed. (See, you’re not the only one who can contrive an absurd argument asserting that it is “too late” to perform an action.)"

Disagree.
If the proposal had been strictly better and every driver had benefited, then the community would certainly have given it a warmer reception. This is now being attempted with the new allocator library (but progress is slow, only two commits this year so far...).
If the proposal had come at early stages, then something common could have been worked out before GBM was implemented everywhere.
But instead it came late, and is only useful for NVidia.
The EGLStreams code is not a trivial addition, and that the original author is going to maintain it indefinitely is questionable, as explained before.

I, too, am looking forward to the new allocator library. Beyond that, it seems that we don’t agree on much. I see no point in arguing any further between us on this topic. Rather, I hope we can agree to disagree.

[chithanh]

You seem to be suggesting that, for a feature to benefit the community, that feature must be used by each-and-every member of the community. If so, that's an absurd suggestion.

Nope. You put words in my mouth again, and trying to hide it by splitting the quote. I said that this alone is not reason to be critical.
Also, your argument suffers from false dilemma (excluded middle).

As you correctly point out, I previously wrote: "if Red Hat refused to contribute the code to Xorg, but had instead only patched their own distributions, the community would be apoplectic, claiming that Red Hat sought an unfair advantage." And as I discuss below, I stand by that statement.

Failure to contribute upstream is often met with criticism in the open source community. And I suspect you know that and are just being obtuse.

And that is a most stupid argument. You can fork open source code or patch for your own distribution, and not submit to original upstream, that is totally fine and ethical. Not even the FSF would criticize such a move as long as user freedom is preserved.

"Being willing to accept a patch if supplied by Nvidia, but unwilling to accept an equally good patch if supplied by a third party, reveals that the resistance isn’t about any technical aspects of the patch. Nor does it support the notion 'to manage two implementations (GBM and EGLStreams) in their codebase' would be constitute an undue 'burden' on the KWin developers, especially if the patches were supplied by others. Rather, the statement underscores that Martin's resistance is about ideology and his dislike for Nvidia."

I explained to you why it is not the case. I am sorry that you do not see the connection, or rather trying to close your eyes by splitting quotes again.

The burden on the KWin developers is both the complexity and the maintenance issue, whereas the first is grounds for disliking such patches and the second grounds for only accepting code from NVidia.

"Millions (hundreds of millions?) of Nvidia cards have been sold, and many commercial users (like the one who you criticized elsewhere in this thread) depend on Nvidia cards.

I do not criticize anyone for buying from NVidia. You are making this up.

I just say that the decision to buy into proprietary single-vendor technology is short-sighted, and if that causes problems later, they are totally deserved.

Comparing community interest in supporting Nvidia GPUs to community interest in supporting the Dolphin emulator makes no sense. Or at least it makes no sense to me.

You are still not understanding the point of the comparison, this is why it makes no sense to you.
The point in Dolphin comparison is entirely to demonstrate the validity of the KWin developer's argument in a real-world situation. How the complexity increases and the maintainability and future development is hindered from the second API (which is part of the argument), and how without a party that has a long-term interest is prone to stop caring (this is why KWin wants only code from NVidia).

"As mentioned above, many commercial users (again, like the one who you criticized elsewhere in this thread) depend on Nvidia cards." "Sure, there is a risk that the code may, eventually, be abandoned. But that risk exists with all community maintained code. At least here, those who have a vested interest in maintaining the code would appear to include Red Hat. I think Red Hat can handle it, don't you? And really, wouldn't you rather the code be maintained by Red Hat (relatively trustworthy) rather than by Nvidia?"

Me? I prefer to have the code outside mainline.

Please also note the last slide presented, in which James Jones invites members of the community to ask "Questions?" about anything presented, and note that James Jones answered several questions asked of him, thereby "interacting with the community."

You're grasping.

Let me return that remark.

If there had been any meaningful cooperation, surely there would have been left any kind of discussion spilled over from XDC 2013 to various mailing lists. You see that for the 2014 event, but not for the 2013 one. This is especially noteworthy given the sharpness of the community response in 2014. I wonder what was the difference.

In any case, it seems that you "are still raging against EGLStreams support for Wayland in general." If so, "again, by your own logic, '[2016] is where [you] should have engaged with the community.’"

I am not raging. I am (calmly) expressing my preference for that to not be merged to mainline. However by the length of your essays on the topic it seems that you are a bit agitated.

"Moreover, although the need for EGLStreams support for Xwayland was foreseeable in 2016 (and I therefore find that that your claim accrued in 2016), you are only now, in 2018, voicing your opposition to EGLStreams support for Xwayland, after nearly all the work has already been done. Sorry, but I arbitrarily decree (much like you arbitrarily decree) that two years after your claim accrued is “too late” to bring your claim. The statute of limitations has run. Claim denied and case dismissed. (See, you’re not the only one who can contrive an absurd argument asserting that it is “too late” to perform an action.)"

Saying that NVidia's proposal came too late is not arbitrary but based on development situation (in mainline codebases, no less). EGLStreams XWayland patches are only now under consideration for merging to mainline (and seemingly two Red Hat developers instead of only one pushing for it now).

I, too, am looking forward to the new allocator library. Beyond that, it seems that we don’t agree on much. I see no point in arguing any further between us on this topic. Rather, I hope we can agree to disagree.

It was my understanding from the start that our positions are not reconcilable. Provoking thought is however reason enough for me to enter discussions. Everybody agreeing in the end needs not be a goal.