Wayland does not contain any NVIDIA defeat devices, and neither does SwayWM. They just use standard Linux GPU interfaces. What I do know is that you can't use the same codepaths you'd use with countless other GPUs, again including AMD and Intel: NVIDIA cards need special cases. This is just as true for KDE and GNOME, which also do not work as well with NVIDIA under Wayland, despite having special codepaths for NVIDIA cards specifically.

This issue isn't new either. In fact, until very recently, it was significantly worse. But progress on NVIDIA's end has been slow, it seemingly gets completely stalled for years at a time.

On the other hand, Nouveau works quite well with Wayland compositors if your card is well-supported, AND you never have to wait on a kernel upgrade because NVIDIA's shim hasn't been updated yet.

There's basically exactly one driver that works this way. It's not a hardware problem, it's not a general GPU issue. There's just one thing it could be.

Same experience here. I get 4k 120hz over HDMI with my puny AMD laptop embedded GPU without tearing on Wayland.

Previous machine with Nvidia GPU (on Xorg) couldn't resume and had atrocious performances because of overheating.

Because wlroots and most Wayland implementations strictly use the kernel abstractions for buffer management, nothing else. They run on literally anything that supports linux’s abstractions, but nvidia drivers did not (it changed recently, not sure about its current state).

Also, xserver used to work with nvidia cards due to goddamn proprietary binary patching done by drivers.

This is from a maintainer of wlroots:

>Maintainer of sway and wlroots here. The Nvidia proprietary driver does not support sway, not the other way around.

>Their standard, EGLStreams, is only implemented by their proprietary drivers, so in order to test that codepath we'd have to use a famously broken and undebuggable driver, which we're not interested in - and make no mistake, we get our hands dirty in the drivers all the time. Their standard also has serious technical problems - lots of really important features simply are not possible to implement based on the proprietary driver. We can't export buffers to clients, overlay planes don't work, buffer presentation timings are impossible... Supporting this driver would be a massive overhaul and would probably make the good drivers worse.

https://news.ycombinator.com/item?id=21628494

Actually, this might not really be that bad of an idea. Certainly for headless CUDA, it has a lot of potential to be useful.

That said, in practice I expect this to suck. There's probably a lot of stuff in the Linux desktop stack that does not deal with heterogeneous graphics cards well right now.