Some compositors haven’t updated yet to my knowledge. I think KDE has something in the aur but not the wider release until their 6.1 release in June. I’m not 100% though
You’re correct. While the stable version of KDE Wayland is usable right now with the new driver with no flickering issues, etc., it technically does not have the necessary patches needed for explicit sync. Nvidia has put some workarounds in the 555 driver code to prevent flickering without explicit sync, but they’re slower code paths.
The AUR has a package called kwin-explicit-sync, which is just the latest stable kwin with the explicit sync patches applied. This combined with the 555 drivers makes explicit sync work, finally solving the flickering issues in a fast performant way.
I’ve tested with both kwin and kwin-explicit-sync and the latter has dramatically improved input latency. I am basically daily driving Wayland now and it is awesome.
Last piece of puzzle is to add cli mtp support on wayland, i have 2 laptops one on AMD and second on Nvidia and with wayland on AMD while Nvidia with x11, and i can’t use jdupes on my mtp connections on wayland and i can’t “cd” into mtp connection while gui apps doing fine on wayland
XWayland (and therefore Zoom, IntelliJ IDEA, any game that runs on Wine, etc) has been borderline unusable for years due to Nvidia not supporting the way a system synchronises its rendering with the GPU, but recently all of the changes that facilitate a newer, better (and most importantly, a directly supported by Nvidia) way of synchronising got merged. This driver is the final piece of the puzzle and I can confirm that all Xwayland flickering has gone away for me.
Nvidia didn’t implement implicit sync because it was stupid and also didn’t really solve anything, it still had performance issues.
The real problem with explicit sync wasn’t Nvidia, it was the fact everything and everybody has to implement it. This problem was worse under a stack like Wayland where every piece has to reinvent the wheel.
The missing piece of the puzzle wasn’t one piece, it was all of them: explicit sync had to be implemented in the kernel, and in drivers, and in graphical libraries, and in compositors, and in apps and so on.
Nvidia released it after it was stable in the kernel.
They don’t care about Wayland or any other userland applications except their own. They don’t have to schedule their development around Wayland, why would they? It’s an emerging stack that’s not yet in use across all the Linux desktop, which is like 1% of their user base anyway.
Great points. Especially the last one, there’s been a lot of vitriol directed at Nvidia lately for “dragging their heels” or whatever, but I don’t blame them for not wanting to implement a crappy stopgap and I certainly do not blame them for the time it took to get e.g the Wayland protocol merged. I think people simply love complaining in the Linux community.
Does that mean I can switch to Wayland from x11??
Yes, now is actually a pretty nice experience using Wayland with this driver
i’ve heard that one a few times before.
Some compositors haven’t updated yet to my knowledge. I think KDE has something in the aur but not the wider release until their 6.1 release in June. I’m not 100% though
You’re correct. While the stable version of KDE Wayland is usable right now with the new driver with no flickering issues, etc., it technically does not have the necessary patches needed for explicit sync. Nvidia has put some workarounds in the 555 driver code to prevent flickering without explicit sync, but they’re slower code paths.
The AUR has a package called kwin-explicit-sync, which is just the latest stable kwin with the explicit sync patches applied. This combined with the 555 drivers makes explicit sync work, finally solving the flickering issues in a fast performant way.
I’ve tested with both kwin and kwin-explicit-sync and the latter has dramatically improved input latency. I am basically daily driving Wayland now and it is awesome.
Last piece of puzzle is to add cli mtp support on wayland, i have 2 laptops one on AMD and second on Nvidia and with wayland on AMD while Nvidia with x11, and i can’t use jdupes on my mtp connections on wayland and i can’t “cd” into mtp connection while gui apps doing fine on wayland
Wait Wayland is bad on Nvidia in the dark times before today?
XWayland (and therefore Zoom, IntelliJ IDEA, any game that runs on Wine, etc) has been borderline unusable for years due to Nvidia not supporting the way a system synchronises its rendering with the GPU, but recently all of the changes that facilitate a newer, better (and most importantly, a directly supported by Nvidia) way of synchronising got merged. This driver is the final piece of the puzzle and I can confirm that all Xwayland flickering has gone away for me.
Nvidia didn’t implement implicit sync because it was stupid and also didn’t really solve anything, it still had performance issues.
The real problem with explicit sync wasn’t Nvidia, it was the fact everything and everybody has to implement it. This problem was worse under a stack like Wayland where every piece has to reinvent the wheel.
The missing piece of the puzzle wasn’t one piece, it was all of them: explicit sync had to be implemented in the kernel, and in drivers, and in graphical libraries, and in compositors, and in apps and so on.
Nvidia released it after it was stable in the kernel.
They don’t care about Wayland or any other userland applications except their own. They don’t have to schedule their development around Wayland, why would they? It’s an emerging stack that’s not yet in use across all the Linux desktop, which is like 1% of their user base anyway.
Great points. Especially the last one, there’s been a lot of vitriol directed at Nvidia lately for “dragging their heels” or whatever, but I don’t blame them for not wanting to implement a crappy stopgap and I certainly do not blame them for the time it took to get e.g the Wayland protocol merged. I think people simply love complaining in the Linux community.
There’s a simple solution. Open up your drivers Nvidia, like Intel and AMD have done.
Not if you need color management. Anyone who creates anything could use color management.
Doesn’t KDE basically have color management with 6 or 6.1 or something?