NVIDIA EGLStreams Support Merged Into KWin For KDE Plasma 5.16

[Termy]

Congratulations to KDE to be persistent enough to get NV to do their part themselfs if they want to do their own thing! Thats what should have happend with gnome, too

[OpenProgger]

This is what happens when you decide to disregard a standard such as GBM (yes, it's been done outside Mesa) and develop your own. You become the one that must provide support since nobody is accepting your method.

By the way, it seems that "Unix Device Memory Allocator" isn't going anywhere...

GBM is an API that is widely supported by open source projects but it's not an standard. It belongs to the developer if they feel motivated to implement other APIs.
But thumbs up for the KWin developers for beeing open for contributions, even if they are not interested to work themselves on it.

[R41N3R]

KWin on Wayland is still not ready, due to:

https://bugs.kde.org/show_bug.cgi?id=387313

https://phabricator.kde.org/T10530

Also, there should be a more focused effort on using Vulkan path for compositors.

This bug should be addressed with priority, but n again no activity in more than one month :-( It is affecting systemsettings, kmail, Firefox Wayland, window effects, ...

[R41N3R]

Will EGLstreams support Xwayland as well? I'm only asking out off interest, my last available Nvidia GPU is in a several years old notebook and the Intel graphics always worked much better on Linux.

[Aeder]

Congratulations to the KDE devs for not doing the work of others for them.

I wonder what worried NVIDIA enough to do this themselves though? Or do they just refuse to let go even 0.5% of their potential market?

[dos1]

ARB_create_context, for example, is also an "extension". But without it opengl 3+ is unavailable for you. Khronos infrastructure is based on extensions.

Of course - that's because OpenGL specification defines which extensions have to be available in order to provide a valid context.

EGL_KHR_stream isn't required by any OpenGL/EGL specification - just like EGL_KHR_platform_gbm.

Desktop GNU/Linux is a GBM platform, so if your driver does not support GBM, you're not really supporting Linux - you're creating your own platform instead. That's why compositors have to support Nvidia separately, which wouldn't be needed had Nvidia actually supported Linux.

[schmidtbag]

KWin on Wayland is still not ready, due to:

https://bugs.kde.org/show_bug.cgi?id=387313

https://phabricator.kde.org/T10530

Also, there should be a more focused effort on using Vulkan path for compositors.

I agree that bug is pretty ugly, though it's very rarely been a problem for me. Usually you just have to enlarge the window enough where it stops being a problem. It's not an ideal solution, but it's not that big of a deal either. So, I'd say Wayland isn't ready to use by default but it's fine for people who realize it's still very much "beta".

I don't really see much of a point in implementing Vulkan. The primary advantage of it is to reduce CPU and PCIe overhead, and the current compositor doesn't seem to be struggling with that a whole lot.

[ssokolow]

EGL_KHR_stream is a standard https://www.khronos.org/registry/EGL...KHR_stream.txt

So is Microsoft OOXML... quite infamously, in fact, given that OpenDocument was already an international standard and OOXML's spec is a monstrous pile of paper encoding a massive pile of legacy Microsoft Office implementation details that other applications must replicate to be compatible. (Stuff like booleans indicating whether the document assumes datetime bugs from the Windows 3.x era when any sane format would rewrite the data to fix the problem when converting from XSL to XSLX.)

[ssokolow]

GBM isn't a standard. It was made specifically for Mesa.

https://en.wikipedia.org/wiki/De_facto_standard

What you're thinking of is known as a "De jure standard".

In law and government, de jure (/deɪ ˈdʒʊəri, di-/; Latin: de iure, lit. 'in law' Latin pronunciation: [deː juːre]) describes practices that are legally recognised, regardless whether the practice exists in reality.^[1] In contrast, de facto ("in fact" or "in practice") describes situations that exist in reality, even if not legally recognised.^[2] The terms are often used to contrast different scenarios: for a colloquial example, "I know that, de jure, this is supposed to be a parking lot, but now that the flood has left four feet of water here, it's a de facto swimming pool".^[3] To further explain, even if the signs around the flooded parking lot say "Parking Lot" (the signs effectively being the "law" determining what it is) it is "in fact" a swimming pool (with the water, the current practical circumstances, determining what it is).

[ssokolow]

Pinging Michael. My post got flagged when I decided to edit in a quote from the relevant paragraph of a Wikipedia page.