NVIDIA EGLStreams Support Merged Into KWin For KDE Plasma 5.16

[zman0900]

So, is novidia actually going to maintain this, or will it just rot away in a year or two?

[Britoid]

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.

It's actually systemd/Linux now.

[Charlie68]

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 tried in every way to reproduce the Kmail bug but to no avail, on my PC no problem with Kmail.
The other bug I still have to understand what it is ... however there are still some bugs, which we hope will soon be resolved, but on my pc it still seems to work quite well.

[shmerl]

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.

Lesser surface of the driver, less driver bugs to deal with. OpenGL / EGL story in KWin is far from perfect due to bugs. Vulkan support is also easier to bring up on new hardware, unlike OpenGL (due to the same smaller size like above). So portability potential is higher, if Vulkan is supported in the compositor. Take for example etnaviv effort. They could focus on Vulkan instead of OpenGL first. But if compositors can't use it - too bad.

[Stenka]

Meanwhile gnome since 3.28 (1 year ago) has EGL mutter support and today still as blacklisted... Sad.

[R41N3R]

I tried in every way to reproduce the Kmail bug but to no avail, on my PC no problem with Kmail.
The other bug I still have to understand what it is ... however there are still some bugs, which we hope will soon be resolved, but on my pc it still seems to work quite well.

Did you verify that Kmail was not running through XWayland? The bug is about graphical glitches on native Wayland applications.

[R41N3R]

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.

The bug is there even for maximized windows. The issue is that apps like Kmail or systemsettings can be visible even if they are overlapped by other applications. Firefox on Wayland doesn't work well either because of this bug.

[Charlie68]

Did you verify that Kmail was not running through XWayland? The bug is about graphical glitches on native Wayland applications.

This is not checked, I am running the last version of Plasma on Tumbleweed in the wayland session.

[R41N3R]

This is not checked, I am running the last version of Plasma on Tumbleweed in the wayland session.

Click ALT + SPACE and type kwin to check whether the app runs with XWayland or Wayland. Usually openSuse is very conservative and they default to XWayland almost always if I remember correctly (even if it is not necessary) plus in this case I think the devs of Kmail decided to hide the Wayland version.

[bug77]

Excellent news. Now all that's missing a version of Wayland that can actually do what people need it to.