Same issue here on Wayland with NVIDIA RTX 3090 GPU and proprietary drivers.

Resizing Steam window to a smaller one seems to reduce amount of flickering.

Disabling GPU Accelerated rendering in web views solves the flickering, but UI is unresponsive, slow and barely usable.

same issues on Nvidia RTx 4090 GPU. It flicker.
libEGL warning: egl: failed to create dri2 screen

Same with fedora.
The issue is with the nvidia driver version 545.29.06-1 (and a bit better with 545.29.06-2) when using wayland. it mostly affects chromium based rendering but also other windows and will cause some games to lag quite hard. if you downgrade to nvidia driver version 535.129.03 all works fine.

Same with fedora. The issue is with the nvidia driver version 545.29.06-1 (and a bit better with 545.29.06-2) when using wayland. it mostly affects chromium based rendering but also other windows and will cause some games to lag quite hard. if you downgrade to nvidia driver version 535.129.03 all works fine.

For me problem still occurs under wayland with 535.113.01-2 driver

Oh, sorry, i misread the driver version, will try 535.129.03

Tried 535.129.03 and 535.146.02 (it was recommended for RTX 3060 on nvidia driver download site), it still flickers the same way

Same here. Arch, nvidia 545.29.06-9

I believe we could try fixing this bug by updating the steam client to use latest chromium. Web browser and other web apps work fine and don't show this flickering. Maybe old chromium that Steam uses is the issue?

I see a similar flicker in the wayland/nvidia driver 545 version combination with the latest chromium on fedora.
I do not see this with x or with the older 535 version driver. On my laptop I do only see it on displays connected to the nvidia card but not the laptops internel display when connected (hw mux) to the integrated amd gpu. So basicaly if gnome renders directly to the nvidia card but rendering it via the amd gpu is fine.
That would mean a chromium version upgrade may likely not fix it - it may however still help.
BTW afaik such nvidia driver issues are known to nvidia and they are working on improving things but it is going since quite a while now.

Same issue here. The flickering makes changing game options or making a purchase impossible at times.

Same problem, Using ArchLinux on nVIDIA 3050 Ti Mobile

Same issue, legacy Intel iGPU, no dGPU. I'm on EndeavourOS with KDE. This doesn't seem to be an nvidia issue

Same issue 545.29.06-2 Fedora 39 RTX 4080 Super

I am also hitting this issue on Fedora 39 (both Kinoite and Silverblue "universal blue" images) with Nvidia driver 545.29.06-2 on my 3090.

Same Issue, Arch + Hyprland, RTX 3060
Had similar flickering in Vivaldibrowser (chromiumbased), was able to resolve it using webrtc and ozone flags.
None of these issues appeared on my Arch + Hyprland Laptop (no Nvidia) or on any X WMs

Same issue, Arch + gnome + wayland + nvidia-beta 550.54.14-1 driver RTX 4070 ti super.
Flickering in steam and in address bar of google-chrome and a menus in steam are a mess. I believe it's wayland because it's all fine on x11.

Same issue 550 Fedora 40 RTX 3080

Same issue, Arch + gnome + wayland + nvidia-beta 550.54.14-1 driver RTX 4070 ti super. Flickering in steam and in address bar of google-chrome and a menus in steam are a mess. I believe it's wayland because it's all fine on x11.

Forgot to mention my setup uses Wayland as well, and since I've seen this issue on Intel, that leads me to believe that you're correct in saying it's a Wayland issue (especially since Steam doesn't seem to have native Wayland support, it uses xwayland instead)

Disabling GPU-acceleration in web views significantly reduces flickering, but does not eliminate it. It still flickers frequently, but not quite as dramatically. Additionally, it is much less responsive.

I'm experiencing this in the Library and everywhere else in the Steam client.

I have an RTX 2060S. I'm using Arch Linux with nvidia 550.54.14-4, KDE Plasma 5.27.10, on Wayland.

Similar trouble with Nvidia 550.54.14-4 on Fedora 39 in Gnome Wayland.

Same trouble arch, hyperland/kde

I have a similar issue with Plasma Wayland on Opensuse Tumbleweed. Kernel Version: 6.7.7-1-default. NVIDIA 550.54.14.

I have the same issue, Plasma 6 Wayland on EndeavourOS. Kernel Version: 6.7.8-273-tkg-eevdf, NVIDIA driver 550.54.14

I have the same issue

Same Problem for a long time.

550.54.14 Nvidia-Optimus (Geforce 940MX) , wayland, Arch-Linux, Gnome 45.4. Hope it will be fixed some day..

Same Problem for a long time.

550.54.14 Nvidia-Optimus (Geforce 940MX) , wayland, Arch-Linux, Gnome 45.4. Hope it will be fixed some day..

I think this is directly related to NVIDIA not implementing implicit sync. It will hopefully be fixed when Wayland compositors have a working implementation of the new explicit sync protocol: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90

Simon Ser commented last week:

Alright, this looks ready to ship! Will wait for a bit and merge if there are no further comments.

GNOME, KDE, and Weston have given this an ACK which means there will be implementations in all of these compositors hopefully sometime soon.

NVIDIA will be shipping an explicit sync implementation in an upcoming driver release. Hopefully soon!

Arch + Gnome + Wayland + Intel XE
Same

Seemingly it has flickered enough to be satisfied while I left the Store page opened and alt-tabbed to read this thread, flickering is gone. But I am sure it will return on the next run until the protocol mentioned above is implemented on all sides.

Arch + Gnome + Wayland + Intel XE Same

Further proves my theory that this isn't an NVIDIA issue

@Faervan

Had similar flickering in Vivaldibrowser (chromiumbased), was able to resolve it using webrtc and ozone flags.

I'm facing the same issue. Would you mind sharing exactly what those flags were? I already have the ozone flag.

@Faervan

Had similar flickering in Vivaldibrowser (chromiumbased), was able to resolve it using webrtc and ozone flags.

I'm facing the same issue. Would you mind sharing exactly what those flags were? I already have the ozone flag.

have a look at https://github.com/Alex313031/thorium/issues/446#issuecomment-1842656564

I had GPU acceleration disabled already and it was still flickering, now I disabled smooth scrolling in web views and the flickering is gone, for now.

This has been awful for me for some time now, it would be great if Valve could place more focus on the Wayland switchover; it would make the steam deck a much more polished and smooth experience if it could run in Wayland and my desktop being able to run Wayland without Steam constantly giving me a very adverse epilepsy test would be very welcome.

Can also confirm that this isn't just an arch issue, as I am running gentoo with ~amd64 with the proprietary nvidia drivers and kde plasma 6 wayland session.

same issue wayland + fedora 39
driver : 550.67

I'm pretty sure this is an issue with explicit sync, which is needed for XWayland. It should hopefully be fixed with this new Wayland protocol for linux-drm-syncobj-v1.

Explicit sync has now been merged into Mutter, Kwin and Xwayland, and should be available in beta driver 555. So we'll see if this gets better once that makes it into releases.

Though do note that the Wayland part of the driver that supports explicit sync will be coming in 560, but as most users are only experiencing flickering problems with XWayland programs, it shouldn't matter at all.

Though do note that the Wayland part of the driver that supports explicit sync will be coming in 560, but as most users are only experiencing flickering problems with XWayland programs, it shouldn't matter at all.

xwayland also merged explicit sync, so it's gonna be fixed too

Same issue. Fedora 39, Wayland, Nvidia driver 550.67.
Xwayland issue? Ok, but where is Steam native wayland support?

Same issue. Fedora 39, Wayland, Nvidia driver 550.67. Xwayland issue? Ok, but where is Steam native wayland support?

Probably after the Wayland protocols that SDL needs are merged.

Probably after the Wayland protocols that SDL needs are merged.

probably not, wayland don't support overlay for example, so it's need tobe fixed too, and why port for wayland when it's not even 64bits

Probably after the Wayland protocols that SDL needs are merged.

probably not, wayland don't support overlay for example, so it's need tobe fixed too, and why port for wayland when it's not even 64bits

What protocol is missing for supporting the overlay?

What protocol is missing for supporting the overlay?

good question lol, let me check

same with Arch + KDE + Wayland + Nvidia GeForce GTX 1660.

Check this: https://linuxiac.com/wayland-nvidia-explicit-sync-support/

We have to wait a few months <3

Have any of you NVIDIA users tried the 555 Beta driver? It implements explicit sync and should fix this issue. Note that you'll need to use a desktop environment that implements explicit sync too, like GNOME 46 or Plasma 6.1, and the latest version of XWayland with explicit sync support.

Stable driver will likely be out in a few weeks otherwise. I have yet to test the Beta driver.

Have any of you NVIDIA users tried the 555 Beta driver? It implements explicit sync and should fix this issue. Note that you'll need to use a desktop environment that implements explicit sync too, like GNOME 46 or Plasma 6.1, and the latest version of XWayland with explicit sync support.

Stable driver will likely be out in a few weeks otherwise. I have yet to test the Beta driver.

I'm not sure if that driver is actually even out in beta. I haven't heard of an ETA for even the beta release.

I'm not sure if that driver is actually even out in beta. I haven't heard of an ETA for even the beta release.

It's out: https://www.nvidia.com/Download/driverResults.aspx/224751/en-us/

@kekkoudesu Niiiiiiiiice!! And looks like there's a PR ready for it on NixOS too! As soon as it hits unstable-small I will absolutely give an update to this.

I have tried the beta 555 on Hyprland/Arch Linux + Nvidia RTX 3060, it fixed all flickering except in Vivaldi (Chromium), Steam as well works without flickering now. Awesome :)

Still broken with the new stable Nvidia 555 driver on KDE Plasma 6.1 (so with explicit sync):

GPU is an RTX 4090.

Resizing the window "fixes" it, but if I change to the library and back to the store, it's broken again.

Still broken with the new stable Nvidia 555 driver on KDE Plasma 6.1 (so with explicit sync):

GPU is an RTX 4090.

Resizing the window "fixes" it, but if I change to the library and back to the store, it's broken again.

I believe this is a separate issue. It can be worked around by disabling GPU accelerated web views in Settings > Interface.

I have an NVIDIA 3060 Ti and am using Wayland with Gnome, my nvidia driver version is 3:555.58.02-1.fc40. The problem is fixed for me (hooray!) :))

It's also been fixed for me with the NVIDIA 555 driver on KDE Wayland. The Steam window starts up invisible, but once resized it works fine even with hardware acceleration on.

GPU is an RTX 4090.
Resizing the window "fixes" it, but if I change to the library and back to the store, it's broken again.

Got the same issue. I disabled GPU accelerated rendering and the issue disappeared, though still I'm getting some flickering when switching between the tabs "Store", "Library" or hovering mouse over a menu items. It's not so ugly like on the original report (in the comment here: https://github.com/ValveSoftware/steam-for-linux/issues/10313#issue-2054768030), but it's not ideal.
I'm running nVidia beta driver 560.35.03 on Ubuntu 24.04, MSI GeForce RTX 4060

I've had the same issues with Steam on a fresh Fedora KDE installation with dnf upgrade, v560 installed and a RTX 3070. Even worse: The whole desktop started to flicker after like 10 minutes, with windows being very glitchy when maximized or moved around. Returning to MS Windows is what fixes it for me

I had a similar issue, I'm not sure if this is the same as yours but my fix was to add --enable-features=UseOzonePlatform --ozone-platform=wayland to the launch options, so open terminal and type steam --enable-features=UseOzonePlatform --ozone-platform=wayland

Definitive A/B reproduction: Steam's bundled CEF (Chromium 126) is the culprit, not the compositor stack

Spent several hours tonight (2026-04-12) on a fresh-rebooted system narrowing this down. Posting here because the thread has been quiet since September 2024 and the test below is, as far as I can tell, the first one in this thread that conclusively rules out the compositor stack (mutter / Nvidia / direct scanout / DP link / XWayland) and pins the bug to Steam's bundled CEF specifically.

System

• Ubuntu 24.04.4 LTS, GNOME Wayland (mutter 46.2)
• Nvidia RTX 4090, driver 580.126.09 open kernel module
• XWayland 23.2.6
• LG UltraGear 1440p240 primary on DP-3, tested at 120 / 144 / 239.97 Hz
• Steam buildid 1773426488, bundled CEF Chromium 126.0.6478.183

The clean A/B test on the same monitor at 240 Hz with the same test video

A short 10-second 1080p30 H.264 mp4 (a screen recording, ~316 KB), played in three different clients on the same monitor at the same refresh rate, in the same Wayland session:

Same compositor, same monitor, same refresh rate, same Nvidia driver, same XWayland, same Wayland session, same test video. The single variable that differs between "clean" and "broken" is the Chromium version inside the client. Crucially, Vivaldi runs the identical HTML5 video.requestFullscreen() code path that Steam's trailer player uses, and it works perfectly — so the bug isn't in the HTML5 fullscreen API itself, it's in Steam's pinned older CEF.

What's NOT the variable

Refresh rate is not it. I tested LG DP-3 at 1440p@120, 1440p@144, and [email protected] Hz with Steam's trailer player; all three flicker identically. Then I ran mpv and Vivaldi fullscreen at 1440p@240 Hz on the same monitor — both clean. So the DP link / refresh rate / VRR theories from earlier in this thread are exonerated, at least for my hardware.

Direct scanout / mutter / Nvidia explicit sync are not it. Mutter 46.2 has explicit sync, Nvidia 580 has explicit sync, XWayland 23.2.6 has explicit sync. The mutter binary contains the direct-scanout symbols (clutter_stage_view_take_scanout, cogl_onscreen_direct_scanout, etc.) and clearly takes that path for fullscreen surfaces. Mpv and Vivaldi exercise this path without trouble. Only Steam CEF triggers the bug.

A fix for this presumably landed upstream in Chromium somewhere between version 126 and 133, probably as part of the explicit-sync work that rolled across mutter / KWin / XWayland 24.1+ / Nvidia 555+ during 2024. Steam's bundled CEF is on the wrong side of that window.

Workarounds I tried that DO NOT work (saving other people the time)

I tried every workaround mentioned in this thread plus a few extras. None of them get Ozone Wayland flags into the steamwebhelper process. Documenting the failure modes:

1. Adding --enable-features=UseOzonePlatform --ozone-platform=wayland to Steam launch options (or to all 10 Exec lines in ~/.local/share/applications/steam.desktop). The flags reach steam.sh and the main /steam binary — visible in their argv via ps -ef. But Steam's launcher filters them out before forwarding to steamwebhelper. Inspecting the parent ./steamwebhelper process command line shows only the translated --disable-gpu / --disable-gpu-compositing (from Steam's -cef-disable-gpu flag); the --enable-features and --ozone-platform flags are stripped. So the comment from @E3nviction earlier in this thread doesn't actually take effect on current Steam, at least not on my build.

2. Modifying ~/.local/share/Steam/ubuntu12_64/steamwebhelper_sniper_wrap.sh to inject the flags directly into the exec ./steamwebhelper line. Steam's bootstrap restores this file from a baked-in copy on every launch. Confirmed by the file mtime reverting from "just now" back to the upstream package date (2025-01-23 00:04:18), and the modification disappearing. There is some integrity check / file restoration step in the bootstrap that I didn't trace further.

3. Modifying ~/.local/share/Steam/ubuntu12_64/steamwebhelper.sh (the outer wrapper, which already uses set -- to inject sandbox args on lines 102/104, so injection there is structurally supported). My modification survives launch — it's NOT integrity-checked. But modern Steam bootstrap does not call this script at all. The process chain in current Steam is:

   /usr/bin/steam → /home/$USER/.local/share/Steam/ubuntu12_32/steam (bootstrap)
       → srt-bwrap → pv-adverb → steamwebhelper_sniper_wrap.sh → ./steamwebhelper
   

   There is no steamwebhelper.sh process in the tree. The outer wrapper appears to be vestigial — preserved as a manual launch path but bypassed by the modern Steam bootstrap binary.

4. Disabling GPU acceleration via -cef-disable-gpu -cef-disable-gpu-compositing in the .desktop Exec line. These flags reduce Bug 1 (Nvidia Xid 56 from general Steam UI use) — I went from 6 Xid 56 clusters per session to 0 during normal browsing. But they do NOT prevent the fullscreen video flicker. I had these flags active throughout all the testing above and the trailer player flickered identically with or without them. (The Xid 56 cluster on fullscreen entry still fired even with the flags in place.)

5. Disabling smooth scrolling, resizing the window, switching between Library / Store tabs to retrigger — variations of partial workarounds mentioned earlier in this thread. I confirm they're partial at best and don't apply to fullscreen video specifically.

So all software-side workarounds for the Steam side of the problem are blocked by Valve's design: either the launcher filters the flags, or the runtime restores the wrapper, or the wrapper isn't called. There is no way (that I've found) for an end-user on a stock Steam install to get Ozone Wayland flags into the CEF child process without modifying Steam's bootstrap binary itself, which is presumably checksummed too.

Workaround that DOES work

Watch Steam trailers in any modern Chromium-based browser (Vivaldi, Chrome, Edge — anything Chromium ~130+) at https://store.steampowered.com/app/<appid> instead of in the Steam client. The store page loads, the trailer plays, fullscreen works perfectly. Tested clean on the exact same monitor and refresh rate where Steam's trailer player flickers.

It's annoying — context switch out of Steam to find the same trailer in a browser tab — but it's the only thing that survives a Steam client update, and it's 100% reliable.

Why this matters — the affected installed base is growing fast

This bug is no longer a niche edge case, and the trajectory of who it affects is moving in one direction. A few signals worth weighing:

• Linux share on the Steam Hardware Survey has roughly tripled since 2020, from under 1% to ~2.5–3% as of early 2026, with consistent month-over-month growth. That's not just Steam Deck — desktop Linux Steam users are growing too, and the absolute number of seats keeps climbing as Valve's overall MAU does.

• Wayland is now the default session on every major desktop distribution that ships recent GNOME or KDE. Ubuntu 24.04 LTS, Fedora 40+, openSUSE Tumbleweed, Pop!_OS 24.04 with Cosmic, recent Endeavour/Arch installer defaults, SteamOS 3.x. X11 is increasingly the legacy fallback for users who actively choose it. Every new Linux Steam install lands on Wayland by default, and that share will only grow.

• Nvidia on Wayland is no longer broken at the driver layer. Nvidia 555+ drivers ship explicit sync, and mutter 46 / KWin 6.1 / XWayland 24.1+ all consume it. The "Nvidia + Wayland is unusable" excuse from a year ago does not apply anymore — and the test above proves it: the same Wayland + Nvidia + XWayland stack runs modern Chromium HTML5 fullscreen video completely cleanly. The platform is ready; it's only Steam's pinned old CEF that isn't.

• The Steam Deck halo effect brings new desktop Linux users to Steam every month. People who like the Deck try Linux on their main PC. Many of them land on Wayland-by-default distros with Nvidia GPUs (because that's what gaming PCs come with). They are your future install base, and right now their first experience of the Steam client on their daily driver is "the trailer player visibly breaks."

• This bug actively hurts your storefront conversion. The trailer player inside the Steam client is the primary way users evaluate whether to buy a game. When it flickers and the window goes unclickable mid-trailer, the user has two options: give up evaluating the game (lost sale), or context-switch out to YouTube or to the same trailer in a browser tab (you lose the in-client analytics on what's being watched, and you train the user that the Steam client is the worst place to watch trailers). Both outcomes are revenue and engagement losses, on a growing-share platform, for a bug that has a known fix sitting upstream.

Suggestion

This issue was filed 2023-12-23 and is at 53 comments across more than two years. The bug is real, reproducible, and definitively pinned to the CEF version inside the Steam client (not the user's compositor, GPU, monitor, refresh rate, or driver — those are all confirmed working with the same fullscreen API in modern Chromium browsers on the same machines). Bumping Steam's bundled CEF to a version based on Chromium 130+ in the next client update would resolve it.

This isn't asking Valve to write new code. It's asking you to take an upstream component update that fixes a real customer-facing issue on the fastest-growing segment of your install base — a segment Valve is also actively investing in via the Steam Deck and SteamOS. The cost-to-impact ratio of this specific fix is genuinely lopsided in your favor.

I'm happy to provide more details, full log captures, dmesg/journalctl snapshots, or run additional tests if anyone from Valve wants to look at this. The repro is deterministic on my machine and I've narrowed it about as far as I can without source access to Steam's CEF integration layer.