KDE Has Another Week Worth Of Wayland Fixes

[Tom B]

At this point, what still doesn't work with KDE on Wayland?

I tried switching to wayland again at 5.20

1. Spectacle crashes after several launches and won't launch again (segfaults) until you restart the session. Deleting the config file doesn't help.

2. Windows randomly flicker

3. Right clicking a taskbar icon is broken, you can't access the menu because the preview gets in the way

4. It often swaps my displays on suspend/resume so I have to go and rearrange them in the system settings dialog

5. Periodically, you can't close a window by clicking the "X" alone, you have to give the window focus before the X becomes clickable

6. Periodically, the taskbar just stops working for some programs. Clicking an entry does nothing and I have to alt-tab to access an already running minimized program.

7. There is no such thing as a "primary display" in wayland, by design apparently, which means that games will inevitably launch on the wrong screen.

Most of these are too vague to report as bugs they don't happen until hours into a session and randomly at that. When I've tried before they are closed as "works for me" or "unable to reproduce". KDE wayland is *better* than it was but I can't help feel like a second class citizen when using it. It doesn't seem like the KDE devs use it themselves yet or these kind of annoyances would be fixed quickly.

[oiaohm]

Yes because AMD directly contributed to the open source driver which is something that NVidia can't do to nouveau for the IP reasons stated earlier.

That idea of IP reasons does not hold grounds. Releasing the firmware to start up Nvidia card power management or start up the functionality of the card video processing does not require submitting code to nouveau. The reality is nouveau developers extract this firmware from the Nvidia binary drivers for testing anyhow. Only change here is really putting these pieces under a license that can be distributed.

Nvidia has directly contributed to nouveau in past for their embedded platforms. AMD at the start of the open source support had to run two driver teams due to IP issues. So IP reasons is not grounds Nvidia could of they wanted to. Just Nvidia does not want to.

You do realize that there is reason why NVidia isn't doing what you think they should be doing, otherwise they would have done so. Its not like Nvidia is sabotaging themselves. They already stated that the GBM/Mesa infrustructure is completely different from their blob and supporting it directly from their blob would create a massive performance decrease and/or other problems (this was said like 8 years ago). Their Linux driver is actually a massive cross platform binary that is shared for all of their drivers for their OS's with an interface layer that the binary than communicates with the OS/Kernel. Linux is the ONLY OS/platform that is causing them problems and thats because its the only OS/platform that is monolithic and GPL (which causes problems for proprietary drivers). Linux of course has no issues with userspace blobs, but suddenly if its a driver than shit hits the fan.

This was the whole reason behind the design of EGLStream's, it was to make a vendor neutral open standard for compositing/desktops that made no assumptions on the kernel or the driver. Linux didn't want it, so we are stuck here.,

This complete stack of garbage has nothing todo with the Xwayland not working. Reality is Xwayland does not give a rats if its GBM/Mesa or EGLstreams. All it cares about is there is a suitable GLVND vendor librarys. https://gitlab.freedesktop.org/mesa/..._requests/6429 this here shows you can hack Nvidia provided libraries into making one for Xwayland on top of EGLstreams of course is a hack so its not fully functional. With internal Nvidia information making a fully functional set of libraries for Xwayland should be possible.

Remember GLVND vender libraries was make drivers way more simple under X11 and other places.

The reality if Nvidia is serous about EGLStreams and GLVND they should have made matching vendor libraries for GLVND so allowing glamor to work. Glamor in X11 server does not use any GBM parts only depends on standard opengl stuff todo in software old X11 server 2d rendering. Modern day Nvidia cards don't have 2d acceleration hardware any more.

Notice something here Nvidia custom hacking for 2d acceleration goes away with this. Once they give GLVND libraries for Xwayland next X11 server API change also gets to delete the old 2d driver interfaces move all drivers to glamor for 2d acceleration under X11 x.org server. Nvidia is the last user of the 2d driver interfaces. When Nvidia proposed GLVND the one proposing GLVND from Nvidia also said Nvidia would change over to glamor as well. Basically Xwayland not working Nvidia did not keep word.

[Citan]

KDE devs label Wayland support as experimental. So... quite a lot.
I have recently tried KDE Wayland for less than half an hour and have reported 3 bugs as a result.

Cool, only 74 to go!



Sorry, couldn't resist.

Thanks to all people expressing their feedback on Wayland support state, and thanks KDE developers for continued good work. I've yet to make that leap of faith but following evolutions with interest.

[bug77]

Cool, only 74 to go!

More will be revealed once people start actually using KDE over Wayland.

Devs are doing a good work, but it feels like it moves at snail's pace. E.g. a few weeks later the bugs I raised aren't even confirmed yet.

[duby229]

So is it going to come if you want to game on Linux you buy AMD and avoid Nvidia like the plague because is a broken pile of garbage. That is the path we are heading to if Nvidia does not change its path.

OT: Just a funny observation... Covid19 has taught us that people don't actually avoid plagues...

[curfew]

I believe the biggest issue here is Wayland itself. The devs didn't stop at improving the X protocol, they also changed the architecture of the windowing system (see: https://en.wikipedia.org/wiki/Waylan..._Wayland_and_X).
Having your software talk using protocols is easy (relatively speaking), but having it interacting with totally different components is hard.

That's why seeing X striding along after all this time, while Wayland support is still being figured out is not even a little surprising.

Well, no, the "protocol" itself is a massive task to implement alone. That's where the architectural differences stem from: most of the stuff that was in X-specific libraries now need be implemented on the window manager's side. Now I am gonna make every DE dev angry by saying that it is mostly mechanical work in nature. I believe that this work also must be more or less duplicated in order to support not just the native Wayland clients, but also the Wayland-to-Xorg layer called XWayland, and maybe even third time for the Xorg-to-Wayland layer to complete the round trip...

[oiaohm]

OT: Just a funny observation... Covid19 has taught us that people don't actually avoid plagues...

Yes it very much the same. Lot of ways those saying the Linux world has to bend knee to Nvidia is like saying Hurd immunity is going to work with Covid19.

The reality is Valve needs the features of wayland/Xwayland for containment to deal with legacy applications. Its not optional idea here. So either Nvidia properly supports Xwayland or Valve will fund the work of zink so it can be used instead of software rendering in Xwayland when on Nvidia hardware. The result of course of using zink is for steam games on Nvidia will not be the best performing choice.

Gnome backed by Redhat wants to sandbox all applications for security reasons. This again means Xwayland needs to work this is why Redhat have explored the hack to make Xwayland work with Nvidia.

Linux kernel.org has a formal kernel memory-ordering https://lwn.net/Articles/718628/ this is also makes kernel.org oppose Nvidia. You cannot have a formal kernel memory-ordering model confirm correct safe memory function while letting some black box code do memory allocations in kernel space.

X.org with their X11 server agreed to GLVND vender libraries on the idea that over time this would reduce the amount of driver modifications X.org X11 userspace code would have. The original plan at X.org before Nvidia made "EGLStream" is that the number of drivers in the X.org tree would reduce the target would be just modesetting driver remaining. Yes before GLVND this was basically just cut Nvidia out completely. This has expanded up to 2.

While Nvidia hardware had a huge performance advantage over all the alternatives Nvidia was on a position to dictate terms. Nvidia is very soon going to be no longer in that position. Don't say high end CUDA cards either. Most of the high end server cards are not able to run desktop applications well because they are optimised to compute not to graphical. This means this dispute area stops at the 3090 Nvidia .

There are two big things here.

Redhat if it comes to a choice between better security and having best performance for large number of redhat customers better security win. Valve if it comes down to the best performance or the most number of games work at playable speed the most number of games work at playable speed. Both Redhat and Valve answers here say XWayland must work stuff the moderate performance overhead. End user gamer comes along and normally says I want my game to run as fast as possible you can bet if Nvidia does not change the answer from Redhat and Valve will be buy a AMD card or possible by a Intel card and throw that Nvidia card in the bin.

Market coming competitive means hardware vendor loses means to dictate terms instead has to work out how to meet the demands from parties like Valve and Redhat.