We do often include affiliate links to earn us some pennies. See more here.

If you own a NVIDIA GPU and run a Wayland session, you might have experienced visual glitches with some applications. They can be minor or quite extreme. This issue only seemed to affect XWayland applications and is explained in detail on the xserver issue tracker.

It was explained that the NVIDIA driver does not support "implicit buffer synchronization", which is what is used across the open-source stack. This is why AMD and Intel GPUs don't face the same issues, as drivers for those cards have implicit sync support. That being said, explicit synchronization can benefit all graphics drivers.

While the NVIDIA driver could implement implicit sync support, it wasn't a complete fix and could have some downsides, so the conversation shifted to creating an Explicit Sync Wayland protocol. That merge request, which was opened two years ago and worked on by several people from different projects like GNOME, KDE, Wlroots, and NVIDIA, was just merged on March 20th.

That's not the end of it, though. Support needs to be implemented in compositors, graphics drivers, and XWayland.

Once all the merge requests that depended on this protocol are merged, the flickering issue on Wayland with NVIDIA GPUs should hopefully be gone for good.

NVIDIA is targeting the 555 driver series for their Explicit Sync support. The Beta release of the 555 driver is expected on May 15th.

Beta release is currently targeted for May 15. It will include support for both the Wayland explicit sync protocol for EGL applications and the counterpart X11 explicit sync protocol for GLX and Vulkan X11 applications.

KDE's Kwin compositor has a patch ready to go as soon as the NVIDIA driver is out.

Once the matching Xwayland and NVidia driver updates are out, most problems with NVidia on Wayland will be gone.

GNOME's Mutter compositor also has a merge request that seems to be almost-ready.

Additionally, wayland-protocols 1.34 has now been released with these new staging protocols:

 * xdg-toplevel-drag

This protocol enhances regular drag and drop by allowing attaching a toplevel window to a drag. This can be used to implement e.g. detachable toolbars and browser tab drag behavior that can be seen in other platforms.

 * xdg-dialog

This protocol allows setting dialog specific hints on a toplevel, more specifically marking them as modal.

 * linux-drm-syncobj

This protocol will allow explicit synchronization of buffers using DRM synchronization objects. While being a protocol that is unlikely to be widely used directly by applications and toolkits themselves, it is an important building block for improving Vulkan and OpenGL drivers.

Here's to a flicker-free Wayland future.

Article taken from GamingOnLinux.com.
17 Likes
About the author -
author picture
I started using Linux in 2020. I'm a visual novel aficionado with an appreciation for indie games. I can also be found playing big-budget multiplayer games with friends. The day Rainbow Six: Siege's anti-cheat works in Proton will be the day all my gaming is done on Linux.
See more from me
8 comments

tartif Mar 21
Excellent summary, thank you.
ivarhill Mar 21
View PC info
  • Mega Supporter
Fantastic news, will be exciting to see this make it to end users!
STiAT Mar 21
Finally. I hope they merge those on F40 once the driver comes around the corner. It is the one visual glitch which really annoys me on Wayland. Well, there are no others so far :D.

And well done .. good summary of the issue and the work put into this.


Last edited by STiAT on 21 March 2024 at 7:04 pm UTC
pilk Mar 21
This is excellent news, the flickering is one of two major annoyances left for me. (The other is electron apps randomly going blank.)
I tried Wayland again with a temporary KDE Neon install, but that flickering problem was obnoxious. If that gets fixed, I'm definitely jumping ship for good.
pilk Mar 22
Quoting: GuestWhat is the refresh rate on your monitor?
The main one is 60hz, and the second one is 75hz (which I limited to 60hz to make sure I don't have display issues).
They're just regular hand-me-down monitors. One from 2014, the other from 2006.


Last edited by pilk on 22 March 2024 at 6:47 am UTC
CalebQ42 Mar 23
Good to see this is finally being fixed(ish). This is one of the main reasons I switched to AMD nearly a year ago as the issue ultimately comes down to NVIDIA deciding they want to do something a different way then everyone else and letting their users have a bad time. From the research I've done, there are some benefits to explicit sync over implicit sync, but since every other driver already has implicit sync no one was in too much of a rush to add it.
Quoting: CalebQ42Good to see this is finally being fixed(ish). This is one of the main reasons I switched to AMD nearly a year ago as the issue ultimately comes down to NVIDIA deciding they want to do something a different way then everyone else and letting their users have a bad time. From the research I've done, there are some benefits to explicit sync over implicit sync, but since every other driver already has implicit sync no one was in too much of a rush to add it.
It seems like almost everybody is in favor of explicit sync: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317#note_1358617

There's a link to this article included: https://lwn.net/Articles/814587/

QuoteExplicit synchronization is the future of graphics and media. At
least, that seems to be the consensus among all the graphics people
I've talked to. I had a chat with one of the lead Android graphics
engineers recently who told me that doing explicit sync from the start
was one of the best engineering decisions Android ever made. It's
also the direction being taken by more modern APIs such as Vulkan.
I can't claim to have researched the topic in detail beyond what was necessary for me to understand the significance of this protocol for my flickering issue on Wayland, but this doesn't actually seem like a controversial issue: everybody wants explicit sync.

Glad to see this issue is finally going away, though.
Luke_Nukem Mar 25
Just to add a tidbit more info to the above:

The graphics stack in Linux was designed around openGL, which is inherently implicit sync. At the time the entire openGL spec was single threaded state machine and so the sync was implicit from that. Later came threaded openGL, but the state-machine design stayed.

So the reality is we have a ton of very slow moving legacy to deal with.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.