NVIDIA's List Of Known Wayland Issues From SLI To VDPAU, VR & More

[piotrj3]

Not as bad as what you think. Lets look at it.

https://forums.developer.nvidia.com/...release/214275

"WAYLAND PROTOCOL OR COMPOSITOR LIMITATIONS"[/LIST][/LIST]
First point is this Wayland compositor or Wayland protocol problem? The answer is in fact no. Do note that Nvidia developer mentions here needs new EGL extensions. These all turn out to be limitations caused by using EGL.. SLI and Multi-GPU Mosaic have been Nvidia features as well so without Nvidia support those cannot be implemented.


Second point Is this a Wayland compositor problem. Again no. If in just terminal mode without X11 server loaded there is no way to turn of video memory by RTD3 either. This is a driver blackboxing problem. Remember eglstreams was meant to be workable without X11 server loaded. This RTD3 defect is Nvidia fault and lack of agreement with other GPU vendors.


Note here that this is Nvidia EGL implementation. The Intel and AMD version that in mesa does Indirect GLX just fine with Wayland so this is Nvidia issue.


This one is Nvidia EGL implementation. Intel and AMD have a few EGL extensions to do this that Nvidia does not implement that link to this problem yes part of fixing this is DMA BUF support then the extensions around it. Yes this is not supporting Glamor as well.


Due to not having a good Nvidia driver as pure Intel and AMD laptops don't have this. So there has been no hardware platform to test these features on due to Nvidia poor driver support by Wayland compositors. Do note they say on X11 what happens if user does not have X11 loaded and is wanting to run using eglstreams... This has been broken for quite some time.

Yes it comes just 1.

Fixing this most likely will not need Wayland protocol changes this will most likely be EGL extension and Xwayland fix. Nothing Wayland compositor has to worry about.

birdie the reality here is everything list here was not supported by Nvidia eglstreams either. This is not damning for Wayland protocol you need to read it a lot more carefully and pay attention to how much is Nvidia unique problems and how much of this list simple did not work right if you did not have X11 server loaded. Remember Nvidia said you could do stuff headless with eglstreams. Does this now explain why lot of Wayland compositor developers were going bugger supporting Nvidia as far too much was busted.

Yes KDE lead developer pushed the problem back on Nvidia developers as well because the problems are really Nvidia developers own caused issues that they have to fix since they have not been willing to provide firmware to open source drivers as well.

Half of Wayland's issues you listed are not Nvidia's fault. They are fault that simply a lot of linux stack is implicit sync made and nvidia driver is explicit sync. And that issue would be solved by EGLstreams and actually Intel engineer said that even somewhere.

Also tons of bugs comes from that devs are using intel/AMD being of open source driver stack and that means during development things gets tested automatically against those drivers. Nvidia does not have this privilage and this is not Nvidia's driver poor quality. If you asked any opengl/Vulkan developer who has the best opengl/vulkan driver they would say Nvidia and say there were more issues with AMD/Intel.

[c117152]

Didn't expect anything else from oiaohm. Again, Linux and Wayland are perfect and NVIDIA is making stuff up.

Wayland (and its compositors) is nowhere near close to what Android, Windows, MacOS and iOS offer bug again, not Wayland's problems. Oh, wait, no screen tearing (or maybe not)! and it's secure (or maybe not)! And it certainly supports HDR! Oh, wait. A victory!

Let's have this conversation again a decade later.

1. The Firefox bug you linked lists Gecko/WebRender's issues. Not Wayland's. The reason the bugs seem to persist is because Mozilla doesn't prioritize the Desktop linux beyond X. e.g. Chrome doesn't have these issues nowadays.
2. Wayland is a protocol and library implementation and both are secure. What you're complaining about is a lack of sandboxing on the linux desktop. That has nothing to do with Wayland or its library.
3. That's Weston missing a feature. Not a bug.

[yariv]

The Frame Lock, Genlock and Swap Groups features can probably be implemented with VRR displays and some compositor smarts, not sure if these actually require new protocol or EGL extensions.

[birdie]

1. The Firefox bug you linked lists Gecko/WebRender's issues. Not Wayland's. The reason the bugs seem to persist is because Mozilla doesn't prioritize the Desktop linux beyond X. e.g. Chrome doesn't have these issues nowadays.
2. Wayland is a protocol and library implementation and both are secure. What you're complaining about is a lack of sandboxing on the linux desktop. That has nothing to do with Wayland or its library.
3. That's Weston missing a feature. Not a bug.

Alright, so it all must be working, right? I'm chasing ghosts and Wayland is perfect, right?? Wayland fans are something, a whole level above "Linux lovers" in terms of "It's not our fault, it's all perfect!"

And surely HDR works in mutter and Kwin under Wayland, right? What, it doesn't? I mean more than a decade ago Windows Vista already supported HDR displays near perfectly and in Wayland it's just "Wait a little bit more?"

Must be NVIDIA's fault!

[oiaohm]

Didn't expect anything else from oiaohm. Again, Linux and Wayland are perfect and NVIDIA is making stuff up.

Wayland (and its compositors) is nowhere near close to what Android, Windows, MacOS and iOS offer bug again, not Wayland's problems. Oh, wait, no screen tearing (or maybe bugzilla.mozilla.org/show_bug.cgi?id=1587060 --not--)! and it's secure (or maybe github.com/Aishou/wayland-keylogger--not--)! And it certainly supports HDR! Oh, gitlab.freedesktop.org/wayland/weston/-/merge_requests/124 --wait--. A victory!

Let's have this conversation again a decade later.

birdie stop moving the goal posts. Not one of those 3 that you just linked was in the Nvidia list. The Nvidia list are Nvidia particular problems. I did not say there were not other problems.

Interesting point is the mozilla bug mentions that the problem with tearing was not appearing when using Intel and AMD with update drivers. Turned out to be a driver bug https://gitlab.freedesktop.org/mesa/mesa/-/issues/1992 Not wayland protocol. Yes part uploading textures under X11 would also causes flicker/tearing.

That keylogger one is kind of a joke and you fell for it hook line and sinker as normal birdie. What is the point of putting LSM protections around X11 server when the X11 protocol says you can key log anything. Wayland protocol is designed to be secure so if you protect the wayland compositor and wayland applications with lower down layers it does come protected.

The HDR one is real problem.

Birdie there are a lot problems that turn out to be vendor or driver problems not wayland protocol problems. Yes some cases Wayland compositors made existing random opengl issues under X11 totally repeatable bugs instead of hard to diagnose intermitt bugs

birdie there are a list of faults that are intel or amd particular as well that are bought out by running Wayland compositors being faults that really did existed with or without wayland compositor. The difference is how repeatable they were.

I did not say Nvidia was making stuff up. There are such things as Nvidia drivers particular problems just like there are AMD or Intel particular problems with their drivers. These driver problems have very little linkage to the wayland protocol.

https://en.wikipedia.org/wiki/File:W...r_protocol.svg Take a close look at this diagram birdie. Notice all the usage of EGL.

Wayland layout moves a lot outside Wayland protocol and Wayland domain. Yes EGL is not wayland protocol.

https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt

Yes disputes over EGL are argued over at khronos group. Yes Nvidia was massively backing the EGLStreams solution while Intel AMD... were backing the DMA-BUF solution on Linux, freebsd.... This is a EGL implementation dispute. Lot of things Nvidia says new EGL extentions are need are in fact already implemented for AMD and Intel on the DMA-BUF backend. Of course since Nvidia was not involved in the writing of the EGL DMA-BUF stuff there is going to be issues. This is Nvidia problem to resolve at EGL Khronos group.

Lot of so called Wayland problems are not Wayland problems instead EGL khronos group problems including the fight over EGLStreams vs DMA-BUF solutions.

Yes yelling at Wayland protocol developers over a problem that has to be addressed at EGL khronos group is not going to get you anywhere. These are problems you need to yell at AMD/Intel/Nvidia... graphics driver developers so they can raise solutions with Khronos.

[rmnscnce]

it's secure (or maybe not)!

To be fair, wayland-keylogger doesn't prove that Wayland -- by itself, is a not secure protocol. The software injects itself into Wayland library functions and adds code that prints input strokes to the standard output. You can see this in the 82nd line of Keylogger.cpp downwards.

[V1tol]

For those who want some VAAPI on NVIDIA (inc Wayland), I recommend https://github.com/elFarto/nvidia-vaapi-driver. Works great in Firefox (with disabled RDD sandbox ofc).

[birdie]

To be fair, wayland-keylogger doesn't prove that Wayland -- by itself, is a not secure protocol. The software injects itself into Wayland library functions and adds code that prints input strokes to the standard output. You can see this in the 82nd line of Keylogger.cpp downwards.

The point of Wayland [defenders] was that Wayland applications cannot possibly snoop on each other. So, instead we have a trivial perfectly working keylogger which any Wayland application can implement and snoop as much as it wants and still "Wayland is secure". LOL. Remember a Wayland compositor is a user application which means any rogue user application can alter how the compositor is launched and have all the fun. And relaunching it is not strictly necessary. Solution: isolate the compositor, only ... nah, who cares?

In ten years we'll surely have something working and secure I guess. Meanwhile I will continue to enjoy my insecure Xorg.

[rmnscnce]

which any Wayland application can implement and snoop as much as it wants

Not quite. wl_keyboard_listener will only be able to poll input from inside the context of the app window itself. This is why wayland-keylogger's README stated that to get the software working one must inject libwayland-keylogger.so into every single application.

Remember a Wayland compositor is a user application which means any rogue user application can alter how the compositor is launched and have all the fun

Fair enough, that's a good point. To add, this is not something that can be fixed with Wayland itself. Injecting custom library functions, regardless of the display protocol (or whatever the technology one's talking about), is always a security risk. That's why environment hardening (e.g. by using SELinux policies) is also a crucial piece of the desktop security puzzle.

[ehansin]

Reading this and reading the comments, I had the thought that nVidia pointing out shortcoming and talking about them, whether the fault of the nVidia driver or Wayland itself, can really only (well mostly) be a good thing. I feel it just put more momentum on making thing better going forward. What is wrong with that??!