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

[starshipeleven]

Even if it takes a year or two to materialize (the nvidia guys behind it are using nouveau for their prototype project, which means mesa/nouveau at least might be quick to support it on the OSS side), that's still peanuts in the grand scheme of things.

For Wayland it is not peanuts. (as Wayland needs xWayland)

Noveau is totally irrelevant as people don't buy NVIDIA cards to use them with Noveau, we are talking of blob NVIDIA driver.

I'm still thinking more of 2-4 years than 1-2 given what this is and how low priority it is for them, but I don't have much to back this so whatever.

Every day I bang my head on my desk when I go through debugging/troubleshooting of code that was written 15 years ago (and wasn't always well-written to begin with), and it's this long-term maintenance burden that I'd be worried about here.

This stuff can be dropped easily once NVIDIA blob supports the new API.

[indepe]

You're probably underestimating the timescale of the development of this new API. I'm not holding my breath for it to appear soon.

Although there seems to be theoretical acceptance of the API, the implementation appears to require upstream support in the Linux graphics stack, and seems to be hampered by similar deadlocks. (From what I could tell from email conversations referenced in articles here.)

[chithanh]

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.

Exactly. My users use scientific software that uses CUDA. Not having Nvidia cards is not an option. Unfortunately all this will do is force us to stay on X.

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.

[GizmoChicken]

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.

Alternatively, if and when such a API emerges (and becomes widely adopted), the patches could be removed upstream.

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.

There are any number of reasons why, in the past, a user may have chosen Nvidia over other options. And even now, although more alternatives exist, some (whether right or wrong) feel that Nvidia offers the best solution for their particular use cases.

Nvidia users aren't whining. Rather, someone who has an interest in supporting EGLStreams in XWayland has developed (and will maintain) the patches needed for doing so. If refused merely for ideological reasons, those who refuse the merge will be unnecessarily depriving Nvidia users of the benefits of Wayland.

In any case, as others have pointed out, if the patches aren’t merged, Nvidia users could continue without XWayland support. But that would further impede Wayland adoption within the community.

Those who don't like EGLStreams need not use EGLStreams. Unless you have a technical (and not merely idealogical) argument against supporting EGLStreams in Xwayland, please don’t stand in the way.

[chithanh]

Alternatively, if and when such a API emerges (and becomes widely adopted), the patches could be removed upstream.

But removal of obsolete API rarely happens. (XAA and Xprint come to mind.) The X server still comes with support for long-obsolete APIs and protocol extensions that almost nobody uses today. Preventing such code, which is understood to be useful in a very limited timespan and use case, from entering the mainline codebase is a good thing.

There are any number of reasons why, in the past, a user may have chosen Nvidia over other options. And even now, although more alternatives exist, some (whether right or wrong) feel that Nvidia offers the best solution for their particular use cases.

Sure they have their reasons. Like Windows users have reasons to use Windows. But they don't come to expect the open source community to care about them.

Nvidia users aren't whining. Rather, someone who has an interest in supporting EGLStreams in XWayland has developed (and will maintain) the patches needed for doing so. If refused merely for ideological reasons, those who refuse the merge will be unnecessarily depriving Nvidia users of the benefits of Wayland.

In any case, as others have pointed out, if the patches aren’t merged, Nvidia users could continue without XWayland support. But that would further impede Wayland adoption within the community.

I think the community is moving to Wayland anyway, even if the minority that uses NVidia graphics cannot follow. And the "depriving NVidia users of the benefits of Wayland" is entirely upon NVidia who don't support GBM. Nouveau shows that GBM works fine with NVidia hardware.

Those who don't like EGLStreams need not use EGLStreams. Unless you have a technical (and not merely idealogical) argument against supporting EGLStreams in Xwayland, please don’t stand in the way.

The technical argument has been made by KWin developers, also linked in this thread.

[jpg44]

Perhaps there is technical merit to EGLStreams. 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. It is a little confusing, leading to questions like: "What if one uses an X.org server on hardware with an Nvidia driver, will it work",

[jpg44]

Where is the motivation for nVidia to follow through on their promises if this is merged? As for lack of accelerated nVidia support hurting Wayland adoption ... ha ... not likely. Wayland adoption will pick up when all the major *functionality* falls into place ... which will be pretty soon, hence distros planning to flip to Wayland by default. nVidia users will either have to deal with software rendering, or switch back to X by default. So a handful of Linux users with nVidia GPUs will not be using Wayland, sure. That's really not the end of the world, and in no way stops the majority of Linux users from moving on.

The problem is there is a vast amount of Nvidia hardware out there. Its in a huge number of computers sold. Many people end up with this hardware not because its their own choice but because its not easy to avoid. You can't say that not having decent Nvidia support won't hurt a huge number of users, it will hurt a huge number of users, simply because there is such a vast amount of nvidia hardware. It will have a major negative impact not supporting Nvidia well. This is not a extremely small niche hardware, its on probably 40% of desktop computers. Many of us lack big bags of money to just go out and buy new hardware and are running on computers we bought at flea markets and thrift stores. Many are installing Linux on older hardware that has an Nvidia card to try to give life to an old machine. We did not buy this hardware because we are big Nvidia fans but becuase we have to be frugal and take what we can get and its not always the latest and greatest $400 whiz bang Intel GPU. Linux does need to be receptive to the needs of users and we have a lot of users like myself who have Nvidia hardware, not because we are huge Nvidia fans, but because we have computers we want to use that happens to have nvidia hardware, and it was the only hardware we could afford, or we are trying to revitalize old hardware we got used. Linux cannot ignore such a vast number of users many who are stuck with Nvidia hardware if Linux is going to be something useable to users.

I think Linux graphics community should just swallow the pill and support EGLStreams. By having the attitude "We won't because its Nvidia" really only hurts the end users who have this hardware.

A major market for Linux is to get older computers one might buy at a thrift store new life.

Just bite the bullet and support EGLStreams.

P.S. I've given this more thought, one can empathize over having to support two APIs in compositors. Another solution which has been mentioned is an compatability layer between GBM and EGLStreams. It seems Nvidia's rationale is that its drivers were written for Windows which has a significantly different driver architecture which impacts the structure of the driver, EGLStreams is more similar to the Windows way minimizing the need to rearchitect the driver. Perhaps a good middle ground is an compatability layer between EGLStreams and GBM allowing Nvidia to easily re-use its Windows code on Linux while avoiding the need for compositors to support another API.

[jpg44]

My reasoning isn't ideological, it's technical. See the KDE devs opinion on this subject, I agree with that pretty much 100%, and he has far more authority on this subject than me.

If it gets merged, it has to be supported for the forseeable future. And given how long X has been around, that could be ~30 years or more.

It needs to be aborted now before it gains any traction.



Amen

Coming from Kwin, it doesnt carry much weight. Kwin has terrible performance characteristics and is the worst window manager I have ever used. Absolutely hideous. I dont know how they can manage to make everything so sluggish have such a negative impact on X applications from a Window manager. It slowed down everything and lead to terrible graphics lag. I read the link and it seems to be rather than a critique of EGLStreams API itself, more of "we just don't want to support it". Still, nothing about any failings in the design of the EGLStreams API itself.

[GizmoChicken]

I read the link and it seems to be rather than a critique of EGLStreams API itself, more of "we just don't want to support it". Still, nothing about any failings in the design of the EGLStreams API itself.

I fully agree with your characterization of the linked post written by Martin Flöser.

For what it's worth, although I support EGLStreams, given the limited resources of the KWin team, I feel that "we just don't want to support it" is sufficient reason for the KWin team to decline supporting it. No need to manufacture other excuses. Those in the open source community should be free choose what they will, and won't, work on.

But I find a more recent post by Martin Flöser to be less defensible. I that post, Martin 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, but instead is about Martin’s perceived notion that Nvidia isn't pulling its own weight. That is, it’s about ideology.

In that same post, Martin also argues 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.” Well, looks like yet another manufactured excuse soon won't be applicable.

[jpg44]

Yes. i hear you. I'm mostly just interested in things working for those of us who have Nvidia hardware, and working well, including acceleration. Not having acceleration is really bad, Google Earth will not work for instance.