>nVidia refused to support the API that Wayland was using, insisting that their EGLStreams approach was superior

This is a common mischaracterizarion of what happened. This API, GBM, was a proprietary API that was a part of Mesa. Nvidia couldn't add GBM to their own driver as it is a Mesa concept. So instead Nvidia tried to make a vendor neutral solution that any graphics drivers could use which is where you see EGLStreams come into the picture. Such an EGL API was also useful for other nonwayland embedded usecases. In regards to Nvidia's proprietary driver's GBM support, Nvidia themselves had to add support to the Mesa project to support dynamically loading new backends that weren't precompiled into Mesa. Then they were able to make their own backend.

For some reason when this comes up people always phrase it in terms of Nvidia not supporting something instead of the freedesktop people not offering a way for the Nvidia driver to work, which is a prerequisite of Nvidia following such guidance.

▲

mariusor 4 days ago | parent [-]

Sorry, but how can an open source project like Mesa be reliant on a proprietary API?

▲

charcircuit 4 days ago | parent [-]

I mean proprietary API in the sense that the API is solely owned and developed by Mesa. It is not a standardized API, but a custom one specific to their project.

Even today if you use the API your program has to link to Mesa's libgbm.so as opposed to linking to a library provided by the graphics driver like libEGL.so.

▲

mariusor 4 days ago | parent [-]

OK, leaving aside the fact that "proprietary" has a very well defined meaning in this context and using it makes your comment very charged, you're basically telling us that Nvidia was not willing to implement an API for their drivers, but tried to push for one designed by themselves (you're calling it "vendor neutral", but since Mesa is not an actual GPU vendor it's most likely another subtle mistake on your part that completely changes the meaning of your words) and all the other vendors (Intel and AMD at this point), which have already implemented GBM should switch too in the name of this ?

How can you call all of that a mischaracterization? In my humble opinion, and I am not anything more than a bystander in this with only superficial knowledge of the domain, it's you that is trying to mischaracterize the situation.

▲

charcircuit 4 days ago | parent [-]

>leaving aside the fact that "proprietary" has a very well defined meaning in this context

Yes, it does and it is different the the well defined meaning when talking in regards to the software itself. OpenGL is an open API, but the source code for an implementation isn't necessarily open.

>Nvidia was not willing to implement an API for their drivers

They couldn't because this API is a part of Mesa itself. As I mentioned programs link to a Mesa library directly.

>since Mesa is not an actual GPU vendor

They are a driver vendor.

>the other vendors (Intel and AMD at this point), which have already implemented GBM

Support was added to Mesa itself and not to the driver's by those companies. The proprietary, now deprecated, AMD kernel module still doesn't support GBM.

>should switch too in the name of this

I think it is beneficial for standards to be implemented by multiple vendors, so I think they should implement it at least.

>How can you call all of that a mischaracterization?

What people think as Nvidia needing to implement an API is actually an ask for Nvidia to make a Mesa API work.

From my perception essentially the ask was that Nvidia needed to open source the kernel driver like AMD did and then eventually a nvidia gbm backend would be built into Mesa for it. For obvious reasons this was never going to happen. The fact that no agreeable solution was figured out in about a decade, and then Nvidia has to code up that solution for the Mesa project is a failure on Mesa's end. A lot of user pain happened due due to them not willing to work together with proprietary software and focusing solely on supporting open source drivers.

▲

mariusor 4 days ago | parent [-]

> For obvious reasons this was never going to happen.

Well, I guess this is the crux of the problem, and for open-source enthusiasts like me this is not obvious at all. What we can surmise is that Nvidia refused to collaborate, therefore they were the party to blame for the status of their video cards not being supported as well as others' vendors on linux.

▲

charcircuit 4 days ago | parent | next [-]

>What we can surmise is that Nvidia refused to collaborate

I saw more effort on Nvidia's side trying to collaborate than on the Wayland side. I think it's unfair to not call out the people who had a hardline stance of only caring about open source drivers and didn't want to do the work to onboard Nvidia.

	▲	dagmx 4 days ago \| parent [-]
		I think you’re significantly retconning what happened. Mesa did discuss EGL but felt it wasn’t the right choice. https://mesa-dev.freedesktop.narkive.com/qq4iQ7RR/egl-stream... In much the same way that NVIDIA may have felt that EGL was the better choice. However none of your description of the way things are explains why NVIDIA couldn’t have made their own libgbm that matched the symbols of mesa and worked on standardizing the api by de facto.

▲

josefx 4 days ago | parent | prev [-]

It may not just be NVIDIA. From what I understand any open source solution is stuck with second rate graphics support on Linux, simply because the groups behind HDMI and other graphics related standards have overly restrictive licensing agreements. Valve ran directly into that while working on its newest console, the AMD drivers for its GPU cannot legally provide full support HDMI 2.1 .