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

[RomuloP]

FYI: the kernel already does allow out-of-tree modules, you can find many out-of-tree drivers, the most notable one being NVIDIA's, or Virtualbox's or VMWare's, or Broadcom's wifi drivers for PC users.

The trick is that the API/ABI used for drivers is subject to change (and usually does change) between releases, out-of-tree modules will have to be adjusted to these changes to keep working, thus requiring some kind of constant maintenance. While the in-tree drivers will be migrated to the new API/ABI by whoever does the change in the kernel (i.e. with no burden on the driver developer).

But this isn't terribly hard to do, for most things.

The Linux kernel project was funded on some rules about code quality/maintainability and copyleft opensource, if contributions don't follow them they won't be merged and will have to stay out-of-tree, maintained by third parties.

I don't see how this is difficult to understand, or bad.

Jesus, read what I write, I like the way it is!, that you can write out-of-tree, at last you can, and sometimes it is needed, simple... I know it all you said, I'm just saying I would love this choice in the current case, of not entering the repo tree if there is so much stress around and just laying out a "modules", until God knows what happen, we move to another protocol, etc...

[chithanh]

Could it be even better than GBM? I don't really care for the attitude "EGLStreams is bad because Nvidia made it". Perhaps it should be supported.

I think you are missing the point of those opposed to adding EGLStreams support.

EGLStreams isn't bad because "NVidia made it" (they didn't, it comes from the Khronos group). The problem is that GBM was developed and agreed upon by the community to be fit for their needs, and then implemented in all open source drivers and Wayland compositors. And only then, NVidia came - without talking to anyone else beforehand, nor participating in the previous work - and dumped an EGLStreams implementation into their drivers, and said they would not support GBM.

And as the KWin developer post outlined, it is not trivial to manage two implementations (GBM and EGLStreams) in their codebase, which means additional burden to support a proprietary driver from a selfish company who is not really interested in working with the community.

[GizmoChicken]

[EGLStreams] comes from the Khronos group.

Good that you realize that EGLStreams comes from the Khronos group.

EGLStreams isn't bad because "NVidia made it" . . . The problem is that GBM was developed and agreed upon by the community to be fit for their needs, and then implemented in all open source drivers and Wayland compositors. And only then, NVidia came - without talking to anyone else beforehand, nor participating in the previous work - and dumped an EGLStreams implementation into their drivers, and said they would not support GBM.

Nvidia certainly did "talk to people" about EGLStreams at XDC in 2014, and probably well before that. You're saying that GBM had been "implemented in all open source drivers and Wayland compositors" before 2014?

And in any case, the "community" of GPU manufacturers comprises of AMD, Intel, and Nvidia. Although GBM may be workable for AMD and Intel, it is not workable for Nvidia. And Nvidia made that clear at least as early as 2014.

And as the KWin developer post outlined, it is not trivial to manage two implementations (GBM and EGLStreams) in their codebase, which means additional burden to support a proprietary driver from a selfish company who is not really interested in working with the community.

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.

And in any case, as I previously posted, Martin Flöser (a KWin dev) recently stated the following:

"Today I would accept a patch for EGLStreams in KWin if NVIDIA provides it. I would not be happy about it, but I would not veto it. If it is well implemented and doesn’t introduce problems for the gbm implementation I would not really have an argument against it. But I expect NVIDIA to do it. I don’t want a contribution from a non-NVIDIA developer. This mess was created by NVIDIA, NVIDIA needs to fix it."

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.

And as I also previously posted, Martin also argues in his post that, even if KWin supported EGLStreams for Wayland, because no EGLStreams support existed (at that time) for Xwayland, “[he didn’t] think that this would give a satisfying experience to NVIDIA users.” With the introduction of EGLStreams for XWayland, yet another manufactured excuse soon won't be applicable.

[chithanh]

Good that you realize that EGLStreams comes from the Khronos group.

I know this, and it is inconsequential to the point why use of EGLStreams with Wayland needs to die (even NVidia recognizes this and has started to work on the common API).

Nvidia certainly did "talk to people" about EGLStreams at XDC in 2014, and probably well before that. You're saying that GBM had been "implemented in all open source drivers and Wayland compositors" before 2014?

Are we trying to rewrite history?

Wayland/Weston 1.0 release was in 2012.

GBM has been around since 2011 and yes, all Gallium3D drivers and the Intel classic Mesa driver implemented it from the start:
https://www.phoronix.com/scan.php?pa...item&px=OTU4Nw

And in any case, the "community" of GPU manufacturers comprises of AMD, Intel, and Nvidia. Although GBM may be workable for AMD and Intel, it is not workable for Nvidia. And Nvidia made that clear at least as early as 2014.

I am saying the "community", not the "community of GPU manufacturers". This includes driver projects which do not have manufacturer backing (nouveau, etnaviv, early freedreno etc.).

And even so, there exist many more GPU vendors than just AMD, Intel and NVidia. The whole embedded Wayland scene (Tizen etc.) is largely happening without these three. I think Qualcomm alone sells an order of magnitude more GPUs than NVidia.

No one is forcing the KWin devs to implement EGLStreams. The KWin devs are free to implement it, or not implement it.

Did I claim otherwise? The community is of course free to reject this, and I welcome if more would.

"Today I would accept a patch for EGLStreams in KWin if NVIDIA provides it. I would not be happy about it, but I would not veto it. If it is well implemented and doesn’t introduce problems for the gbm implementation I would not really have an argument against it. But I expect NVIDIA to do it. I don’t want a contribution from a non-NVIDIA developer. This mess was created by NVIDIA, NVIDIA needs to fix it."

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.

Nope. He knows what is going on.
Case in point: DX12 support in Dolphin emulator. Code was submitted by a single entity and left to rot. Eventually it became too much of a maintenance burden, and held up progress in other areas, and had to be thrown out. This is an important lesson why a party with a vested interest in EGLStreams needs to submit and maintain the code, and the only such party is NVidia.

And as I also previously posted, Martin also argues in his post that, even if KWin supported EGLStreams for Wayland, because no EGLStreams support existed (at that time) for Xwayland, “[he didn’t] think that this would give a satisfying experience to NVIDIA users.” With the introduction of EGLStreams for XWayland, yet another manufactured excuse soon won't be applicable.

This is not a manufactured excuse. This is called balancing upsides and downsides, and the usefulness of KWin EGLStreams is very limited without XWayland EGLStreams. Now the upsides may change depending on whether the patch is accepted, but the downsides remain the same.

[GizmoChicken]

I know this, and it is inconsequential to the point why use of EGLStreams with Wayland needs to die (even NVidia recognizes this and has started to work on the common API).

But this fact is not inconsequential when refuting those (maybe not you) who falsely claims that EGLStreams was conceived specifically by, and only for, Nvidia. Hope you realize that, too.

Are we trying to rewrite history?

I'm not. Are you?

In your previous post, you wrote:

"The problem is that GBM was developed and agreed upon by the community to be fit for their needs, and then implemented in all open source drivers and Wayland compositors. And only then, NVidia came - without talking to anyone else beforehand, nor participating in the previous work - and dumped an EGLStreams implementation into their drivers, and said they would not support GBM."

That is, you argue that GBM had been widely implemented by Wayland compositors before Nvidia began discussing EGLStreams (which was no later than 2014, and probably much earlier).

Even today, Wayland arguably is still in its infancy, and certainly is still growing and developing. Although Wayland had been conceived, the sheets were still warm in 2014. To say that in 2014 "the community" had solidified on GBM being the universal solution for Wayland (at a time when Wayland was, at best, in early gestation) is disingenuous.

Exactly when Wayland graduated from gestation to birth is debatable. But I would argue that, whatever its birthday, Wayland currently suffers from failure thrive. A dose of vitamin Nv may just be what the doctor ordered for a healthy start to life.

And even so, there exist many more GPU vendors than just AMD, Intel and NVidia. The whole embedded Wayland scene (Tizen etc.) is largely happening without these three. I think Qualcomm alone sells an order of magnitude more GPUs than NVidia.

You seem to think these other GPU vendors are opposed to alternatives to GBM. Even if they are opposed to alternatives to GBM (which they aren't), I don't see the relevance. Again, what matters is that community members who have an interest in supporting EGLStreams in XWayland have developed (and will maintain) the patches needed for doing so. Whoever (whether AMD, Intel, other GPU vendors, or just you) refuses the merge will be unnecessarily depriving Nvidia users of the benefits of Wayland. And no, it is not Nvidia's fault.

Did I claim otherwise? The community is of course free to reject this, and I welcome if more would.

Good to know that you agree that KWin is free to reject supporting EGLStreams. To reiterate, by rejecting EGLStreams, KWin is not burdened by the introduction of EGLStreams for Xwayland upstream. And if you don't use EGLStreams, neither are you.

Nope. [Martin Flöser (a KWin dev)] knows what is going on.
Case in point: DX12 support in Dolphin emulator. Code was submitted by a single entity and left to rot. Eventually it became too much of a maintenance burden, and held up progress in other areas, and had to be thrown out. This is an important lesson why a party with a vested interest in EGLStreams needs to submit and maintain the code, and the only such party is NVidia.

You are seriously comparing interest in maintaining support for the "Dolphin emulator" to interest in maintaining support for a hugely popular brand of discrete GPUs?

And are you really in a position to state that no one other than Nvidia has a vested interest in EGLStreams? While I agree that patches should be accepted only from those who demonstrate the ability and willingness to maintain them, it is silly to argue that only Nvidia meets that criteria. But in any case, with regard to KWin, like I wrote before (with which you seem to agree), no one is forcing the KWin devs to implement EGLStreams.

This is not a manufactured excuse. This is called balancing upsides and downsides, and the usefulness of KWin EGLStreams is very limited without XWayland EGLStreams. Now the upsides may change depending on whether the patch is accepted, but the downsides remain the same.

Well, at least you admit that the absence of an EGLStreams for Xwayland solution can no longer be relied upon by KWin as an excuse for not supporting EGLStreams for Wayland. I hope that Martin Flöser provide such an admission.

Be honest: You hate Nvidia and Nvidia users. ("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.") Rather than make room for those community members who want to support Nvidia (without any cost to you, I'll add), you would seem to prefer that Nvidia users exit from the Linux community and use Windows instead. Not very inclusive of you.

[chithanh]

But this fact is not inconsequential when refuting those (maybe not you) who falsely claims that EGLStreams was conceived specifically by, and only for, Nvidia. Hope you realize that, too.

You need to see the context here. While NVidia did not invent EGLStreams, they were the ones to come up with the idea of using EGLStreams for Wayland. At a time when the whole community (literally everyone who cared about Wayland except NVidia) had already agreed on GBM.

This is what people mean when they say that EGLStreams is a NVidia-specific thing.

I'm not. Are you?

In your previous post, you wrote:

"The problem is that GBM was developed and agreed upon by the community to be fit for their needs, and then implemented in all open source drivers and Wayland compositors. And only then, NVidia came - without talking to anyone else beforehand, nor participating in the previous work - and dumped an EGLStreams implementation into their drivers, and said they would not support GBM."

That is, you argue that GBM had been widely implemented by Wayland compositors before Nvidia began discussing EGLStreams (which was no later than 2014, and probably much earlier).

Even today, Wayland arguably is still in its infancy, and certainly is still growing and developing. Although Wayland had been conceived, the sheets were still warm in 2014. To say that in 2014 "the community" had solidified on GBM being the universal solution for Wayland (at a time when Wayland was, at best, in early gestation) is disingenuous.

You are intentionally being obtuse here.

GBM has been released in 2011 with full driver support in Mesa (all Gallium drivers + Intel classic driver).
The reference Wayland compositor Weston originally introduced GBM.
GNOME mutter supports Wayland with GBM since November 2011 (EGLStreams support was merged only in November 2016).
Enlightenment Evas DRM backend (supports only GBM) was released in February 2014.
KDE KWin timeline I am less firm, but I found slides from Akademy 2014 that in September 2014 KWin still rendered via Weston on Wayland.
NVidia XDC presentation which you linked to earlier was in October 2014.

This means that all the Wayland compositors in existence when NVidia talked about EGLStreams at XDC 2014 were using GBM already, directly or indirectly.

There is one Wayland compositor which was developed afterwards, namely Sway (0.1 release in March 2016). If you want, read the Sway lead developer's opinion on NVidia and EGLStreams (not that it matters).

Exactly when Wayland graduated from gestation to birth is debatable. But I would argue that, whatever its birthday, Wayland currently suffers from failure thrive. A dose of vitamin Nv may just be what the doctor ordered for a healthy start to life.

What?

(I have reordered the following quotes by topic)

Whoever (whether AMD, Intel, other GPU vendors, or just you) refuses the merge will be unnecessarily depriving Nvidia users of the benefits of Wayland. And no, it is not Nvidia's fault.

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. Do note that Nouveau implements GBM fine, so it is not a hardware problem, only a matter of driver support.

You are seriously comparing interest in maintaining support for the "Dolphin emulator" to interest in maintaining support for a hugely popular brand of discrete GPUs?

I suggest that you educate yourself and read about the reasons why Dolphin developers dropped DX12 support and realize how similar they are to the reasons why KWin developers are not interested in EGLStreams.

Again, what matters is that community members who have an interest in supporting EGLStreams in XWayland have developed (and will maintain) the patches needed for doing so.

And are you really in a position to state that no one other than Nvidia has a vested interest in EGLStreams? While I agree that patches should be accepted only from those who demonstrate the ability and willingness to maintain them, it is silly to argue that only Nvidia meets that criteria. But in any case, with regard to KWin, like I wrote before (with which you seem to agree), no one is forcing the KWin devs to implement EGLStreams.

No graphics vendor besides NVidia wants to use EGLStreams for Wayland compositors.

Sure there may be some community members with interest, especially those who have bought NVidia hardware to use under Linux, but as KWin developer's blog post it is NVidia's responsibility to support them. Those users cannot be expected to be around when they switch hardware or lose interest for other reasons.

Be honest: You hate Nvidia and Nvidia users.

Nope. I am indifferent to NVidia proprietary driver users. They can go use Windows for all I care. NVidia itself is a company I consider not a good member of the community, unethical, and untrustworthy, and would not buy from them. But I do not hate NVidia.

The comment about locking oneself into single-vendor controlled proprietary technology is a general one, it applies to CUDA as well as Microsoft Office "Open" XML, proprietary operating systems, closed messaging platforms, etc.: You deserve all the pain that is caused if that vendor chooses to forsake you.

[GizmoChicken]

In my previous post, I wrote:

"In your previous post, you wrote:

'The problem is that GBM was developed and agreed upon by the community to be fit for their needs, and then implemented in all open source drivers and Wayland compositors. And only then, NVidia came - without talking to anyone else beforehand, nor participating in the previous work - and dumped an EGLStreams implementation into their drivers, and said they would not support GBM.'

That is, you argue that GBM had been widely implemented by Wayland compositors before Nvidia began discussing EGLStreams (which was no later than 2014, and probably much earlier).

Even today, Wayland arguably is still in its infancy, and certainly is still growing and developing. Although Wayland had been conceived, the sheets were still warm in 2014. To say that in 2014 "the community" had solidified on GBM being the universal solution for Wayland (at a time when Wayland was, at best, in early gestation) is disingenuous.

Exactly when Wayland graduated from gestation to birth is debatable. But I would argue that, whatever its birthday, Wayland currently suffers from failure [to] thrive. A dose of vitamin Nv may just be what the doctor ordered for a healthy start to life."

You are intentionally being obtuse here.

GBM has been released in 2011 with full driver support in Mesa (all Gallium drivers + Intel classic driver).
The reference Wayland compositor Weston originally introduced GBM.
GNOME mutter supports Wayland with GBM since November 2011 (EGLStreams support was merged only in November 2016).
Enlightenment Evas DRM backend (supports only GBM) was released in February 2014.
KDE KWin timeline I am less firm, but I found slides from Akademy 2014 that in September 2014 KWin still rendered via Weston on Wayland.
NVidia XDC presentation which you linked to earlier was in October 2014.

This means that all the Wayland compositors in existence when NVidia talked about EGLStreams at XDC 2014 were using GBM already, directly or indirectly.

There is one Wayland compositor which was developed afterwards, namely Sway (0.1 release in March 2016). If you want, read the Sway lead developer's opinion on NVidia and EGLStreams (not that it matters).

Who’s being obtuse? Weston is a reference compositor that has never been, and probably never will be, used outside of development. And as for Mutter (and the other compositors the you mentioned), regardless of whether they had initial GBM support in 2014, I can assure you that none of them (including Mutter) was actually usable in the real world (namely, outside of development and testing) as a Wayland compositor in 2014. And a "Wayland compositor" that isn't actually usable as a "Wayland compositor" isn't much of a "Wayland compositor" in my view.

Indeed, my point (which I tried to depict via metaphor), was that, while Nvidia may not have been present at the earliest moments of conception (early 2011?), Nvidia was active with Wayland during its early gestational period (including 2014), which is well before Wayland had actually become useful to most users (much more recently). That is, it’s not like in 2014 Wayland was feature complete and couldn’t be improved upon. Indeed, I submit that Wayland hasn’t reached that stage even today.

Sorry that you didn’t appreciate my metaphor. I was especially pleased with my observation that “Wayland currently suffers from failure [to] thrive.” and that a “dose of vitamin Nv may just be what the doctor ordered for a healthy start to life.” And I stand by that observation, namely that we’ll see a growth spike in Wayland usage once Wayland offers better support for Nvidia GPUs.

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.

You’re still living in the land of time between 2011 and 2014? In any case, no, I’m afraid we’ll just have to disagree regarding the allocation of fault. And I doubt we’ll ever agree on this.

As an aside, I'm under the impression that Nvidia was working on Wayland before 2014. How much before 2014, I don't know for certain. But even assuming that they only began working on Wayland in 2014, as outlined above, Nvidia was involved at what must be considered (from the perspective of 2018) the early stages of Wayland development.

Do note that Nouveau implements GBM fine, so it is not a hardware problem, only a matter of driver support.

I think we can agree that Nouveau's performance is suboptimal. Like it or not, those who want top performance out of their Nvidia cards must use the proprietary Nvidia drivers. And that’s why “community members who have an interest in supporting EGLStreams in XWayland have developed (and will maintain) the patches needed for doing so.”

I suggest that you educate yourself and read about the reasons why Dolphin developers dropped DX12 support and realize how similar they are to the reasons why KWin developers are not interested in 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.

Sure there may be some community members with interest, especially those who have bought NVidia hardware to use under Linux, but as KWin developer's blog post it is NVidia's responsibility to support them. Those users cannot be expected to be around when they switch hardware or lose interest for other reasons.

Again, I don’t care whether KWin does, or doesn’t, support EGLStreams. As mentioned above, many commercial users (again, like the one who you criticized elsewhere in this thread) depend on Nvidia cards. As for the “some community members” who “may” have interest in maintaining EGLStreams in Xwayland, more than some of them are being paid to do so by their employers. So yes, I expect them to be around for as long as they want a paycheck. If/when they leave, they’ll be replaced. Hope that puts an end to your concerns.

Nope. I am indifferent to NVidia proprietary driver users.

Well, they say that the opposite of love isn’t hate, but indifference. So maybe you’re right.

[NVidia proprietary driver users] can go use Windows for all I care.

Thanks for confirming your aversion to inclusivity in the Linux community.

NVidia itself is a company I consider not a good member of the community, unethical, and untrustworthy, and would not buy from them.

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

[chithanh]

Who’s being obtuse? Weston is a reference compositor that has never been, and probably never will be, used outside of development. And as for Mutter (and the other compositors the you mentioned), regardless of whether they had initial GBM support in 2014, I can assure you that none of them (including Mutter) was actually usable in the real world (namely, outside of development and testing) as a Wayland compositor in 2014. And a "Wayland compositor" that isn't actually usable as a "Wayland compositor" isn't much of a "Wayland compositor" in my view.

GNOME claimed "day-to-day usable experience" with Wayland for GNOME 3.14 release, September 2014, one month before the NVidia XDC EGLStreams talk.

You’re still living in the land of time between 2011 and 2014? In any case, no, I’m afraid we’ll just have to disagree regarding the allocation of fault. And I doubt we’ll ever agree on this.

No. I am tracing back NVidia's fault to the time between 2011 and 2014 that they failed to engage in a meaningful way with the Wayland community. Repairing this now requires working with the community on a common API which, at current pace, may not be ready for another couple of years. What makes it harder is that the developer community has no real reason to throw away the GBM work as it works fine for them. While they have plenty reasons to reject EGLStreams.

I think we can agree that Nouveau's performance is suboptimal. Like it or not, those who want top performance out of their Nvidia cards must use the proprietary Nvidia drivers. And that’s why “community members who have an interest in supporting EGLStreams in XWayland have developed (and will maintain) the patches needed for doing so.”

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.

Should have known better than buying NVidia cards for use under Linux.
It's not that every time someone asks, they get the reply "yeah works great, but you'll need a proprietary driver from NVidia that does exactly what NVidia wants it to do".

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.

I try to explain it again. There are technical similarities, namely that Dolphin and KWin output via rendering backends. Adding one more backend which someone with limited interest throws over the wall is a recipe for future problems. Those problems is what KWin developer feared in the blog post, and those problems are which actually manifested in Dolphin and culminated in the defenestration of its DX12 backend.

The purpose of this example was to counter your claim that the KWin developer presented a "manufactured excuse". He didn't, he pointed to very real problems that application developers actually face.

As for the “some community members” who “may” have interest in maintaining EGLStreams in Xwayland, more than some of them are being paid to do so by their employers. So yes, I expect them to be around for as long as they want a paycheck. If/when they leave, they’ll be replaced. Hope that puts an end to your concerns.

It doesn't. Once they move on from NVidia, the code is there to rot.
Only NVidia cannot move on from NVidia. They can move on from EGLStreams however once the successor standard is ready.

Thanks for confirming your aversion to inclusivity in the Linux community.

I'm all for inclusivity in the Linux community.
systemd or epoch/openrc/runit/s6/shepherd/sysv-init/...? Be my guest.
LibreOffice or OpenOffice? Why not both?
ffmpeg or libav? I wish they would all hug and apologize, and then continue to work on one library.

But the company which we are talking about is not a community member. It is for the most part a selfish outsider which leeches off Linux, ignores everyone they can afford to ignore, and contributes back only where necessary. I don't need to remind you of this:


or this

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

Oh, I stopped buying from NVidia around 2001, read here why (in German) if you are interested.

I simply explained in this thread why I think the XWayland EGLStreams patches would better be rejected by the mainline X.org server, and only be included by distros that cater to NVidia users. The exchange of ideas is never an unproductive task.

[GizmoChicken]

GNOME claimed "day-to-day usable experience" with Wayland for GNOME 3.14 release, September 2014, one month before the NVidia XDC EGLStreams talk.

I thank you for conceding that GNOME had "day-to-day usable experience" with Wayland no earlier than September 2014. While I reserve the right to dispute whether the experience truly was "day-to-day usable" in September 2014 (I didn't find it to be usable even until about 2016, at the earliest), for the sake of argument, let's assume the characterization is accurate.

As I wrote before, "Nvidia certainly did 'talk to people' about EGLStreams at XDC in 2014, and probably well before that."

Here's a link to a talk at XDC in 2013 in which James Jones from Nvidia discusses some, admittedly preliminary, work on Nvidia's EGLStreams approach:

https://www.youtube.com/watch?v=DoZiLJBwvCU

So, no, Nvidia didn't "suddenly insist[] on doing it differently from everyone else" at the last minute, and certainly not after a usable Wayland compositor had been released.

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.

I simply explained in this thread why I think the XWayland EGLStreams patches would better be rejected by the mainline X.org server, and only be included by distros that cater to NVidia users.

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.

The exchange of ideas is never an unproductive task.

Please consider our ideas to have been exchanged.

[chithanh]

I think you are applying double standards here.
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.

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.