afaict the only people who really care about EGLStream are nvidia. And while GNOME and KDE might have the resources to support both API's (much as they don't want to), smaller projects like sway simply don't have the resources to worry about that.

I think one of the biggest failings of wayland is that it requires so much duplication of effort between different compositors. Ideally, the compositor shouldn't have to care very much about which drivers the user is using for their graphics card.

>Ideally, the compositor shouldn't have to care very much about which drivers the user is using for their graphics card.

That would require a single standard for communication with GPUs and the problem is that Nvidia is refusing to implement that standard.

All it requires is a single standard interface for managing buffers, which exists and is named GBM.

Wayland doesn't care how you draw your buffers, and a custom EGL library as they already do, while gross as hell, is not at all a compatibility problem.

Or some kind of abstraction layer.

Even KDE was only able to gain support for EGLStreams after an NVidia developer Erik Kurzinger contributed the necessary changes to Kwin.

As far as I know that was mostly because they refused to even try and not because it was too hard or even complicated.

If one of the kwin developers had nvidia hardware, likely they would have cared enough to try. And if they didn't, how would they test and maintain the nvidia-specific code? Adding an entirely new code path for rendering would be a large support and testing burden that they may not have had the resources to take on.

> If one of the kwin developers had nvidia hardware,

So what your are saying is that NVIDIA could have just sent them a crate full of low end $50 dollar hardware and been done with it? I find that rather unlikely, or rather as an end user I prefer to think that there wouldn't be that much drama over what amounts to nothing.

Maybe? I don't know.

But, either way, having two completely separate graphics code paths means a much larger maintenance burden than one. Even with hardware to test on, I'd consider it perfectly reasonable to decide to only support one, especially if the odd company out is one with a history of not playing ball with the community.

EGLStreams is heavily used in industrial embedded, eg in nvidia's car platforms.

You got that the wrong way around:

Nvidia's platforms are a large part of industrial embedded, on which the users have no option but to use EGLStream.