545.29.02 introduced sporadic flickering, especially visible during typing

Hi! After upgrading from 535.113.01 driver to 545.29.02, I started noticing very annoying flickering, especially visible during typing in text editors or terminal. It looks as if display jumps several frames back for a moment.

I’ve recorded a video showcasing this effect: https://www.youtube.com/watch?v=h1yU2Ue5Oxk
For comparison, here’s how it looks without the regression (on 535.113.01 driver): https://www.youtube.com/watch?v=At6lyLi-3N8

I’ve tested the latest beta driver (550.40.07) - it also exhibits the same issue.
Nvidia open-source drivers also have this regression. Unfortunately all changes between 535 and 545 arrived in one huge commit, so I wasn’t able to bisect the problem further.

Not all applications seem to be affected by this problem. Apps using OpenGL for rendering seem to be unaffected (glxgears, VLC, Firefox, etc).
Mouse cursor movement is also not affected.
Interestingly, starting a screen recording (I used Kazam) supresses the flickering almost completely. I’ve managed to detect several instances of flickering even when doing the screen recording, but they weren’t present in the screen recording output.

Attaching the nvidia-bug-report.log. I hope it contains the necessary system info, but please don’t hesitate to ask for any additional info if needed.
nvidia-bug-report.log.gz (1.0 MB)

Looks like you’re on Xorg without compositor. Which WM are you using?

I’m using Xmonad.
Indeed, I’m not running a compositor.

I have the same issue on openSUSE Tumbleweed with nvidia driver 550.67.
Using KDE 6 / kwin window manager, compositor is enabled as far as I can tell.

0000:00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)
0000:01:00.0 3D controller: NVIDIA Corporation TU117M [GeForce GTX 1650 Mobile / Max-Q] (rev a1)

qdbus6 org.kde.KWin /Compositor

property read bool org.kde.kwin.Compositing.active
property read QString org.kde.kwin.Compositing.compositingNotPossibleReason
property read bool org.kde.kwin.Compositing.compositingPossible
property read QString org.kde.kwin.Compositing.compositingType
property read bool org.kde.kwin.Compositing.openGLIsBroken
property read bool org.kde.kwin.Compositing.platformRequiresCompositing
property read QStringList org.kde.kwin.Compositing.supportedOpenGLPlatformInterfaces
signal void org.kde.kwin.Compositing.compositingToggled(bool active)
signal void org.freedesktop.DBus.Properties.PropertiesChanged(QString interface_name, QVariantMap changed_properties, QStringList invalidated_properties)
method QDBusVariant org.freedesktop.DBus.Properties.Get(QString interface_name, QString property_name)
method QVariantMap org.freedesktop.DBus.Properties.GetAll(QString interface_name)
method void org.freedesktop.DBus.Properties.Set(QString interface_name, QString property_name, QDBusVariant value)
method QString org.freedesktop.DBus.Introspectable.Introspect()
method QString org.freedesktop.DBus.Peer.GetMachineId()
method void org.freedesktop.DBus.Peer.Ping()

Tested 550.67 on my machine, flickering is still present (feels like it’s a bit less frequent, but is definitely still there).

Running a compositor (xcompmgr) has no effect.

Previously I assumed only “simple” applications exhibited this problem, and GPU-accelerated ones don’t (OpenGL, etc). However on 550.67 I noticed flickering even on Alacritty (GPU-accelerated terminal emulator).

535.171.04 (latest from the 535 branch) works without issues. And thankfully it still compiles on the latest kernels (I have Linux 6.8.5 currently, which broke compilation of 535.113.01 drivers.

Tested 550.78, still experiencing the same flickering. Feels like it’s somewhat reduced, but still very much present.

To test an assumption that the issue arised from my very custom setup (XMonad WM, etc), I tried out a plain XFCE4 desktop. No luck - same flickering appears in all the apps.

Decided to test a Beta driver as well (555.42.02). Same issue persists.

Is there anything more substantial that I can do to help debug this issue?

Currently I’m testing out new driver versions and praying that the bug goes away. However that doesn’t seem like a fruitful approach, since the bug is out for half a year already and apparently isn’t going to fix itself.

Tested the 560.31.02 driver - same issue, flickering is still persent (and very annoying).

Updated to 535.183.01 driver - works without any issues (however, doesn’t compile on 6.10 kernel right now, had to downgrade back to 6.9 - but I suspect that will be fixed soon).

Tested 565.57.01 driver - still the same issue.

535 drivers continue to work. But I’m very worried that soon they will stop being updated, and new kernel releases will soon break them (as they do currently every couple of months).

Can somebody tell me for how long the 535 branch of drivers is going to be maintained?

Since the 535 driver is (latest) part of the Long Term Support Branch (LTSB), it has a total support lifespan of three years. So I think we can expect it to remain stable and supported through to mid-2026.
I have had the same issues with the 550 and 560 driver by the way, so I’m also trying to downgrade now…

→ R535 Long Term Support

So I have 1.5 years more, plus 2-3 years on top of that during which I can hope just keep running an older Linux version. And maybe during this windo I will switch to a different hardware.

I’m very sad that state of Nvidia support is so abysmal. It’s not like I’m asking them to read tea leaves - I am very much willing to spend significant amount of time trying to debug the issue myself. All I need is some pointers about where to look.

But nobody cares.

Hmm I think that Linux kernels will support older NVidia drivers for a very long time. So that will not be the problem.

You just need to make sure that you lock the driver packages in your package manager to prevent an update as soon as you want to update your OS.

The other point is that the long-term NVidia drivers 470 and 535 were released in July 2021 and June 2023.

Therefore, one could assume that there will continue to be an overlap of 1 year in which one could upgrade to the next LTSB stable driver.

I think this is also the only reasonable and reliable approach: to jump to the next LTSB stable driver and avoid the other branches under all circumstances (new feature branch and even the production branch, if you ask me).

Hmm I think that Linux kernels will support older NVidia drivers for a very long time. So that will not be the problem.

In my experience it actually was a problem multiple times already.

For example upgrading from linux 6.7.5 to 6.8.5 caused nvidia 535.113.01 compilation to break, which was fixed by upgrading nvidia to 535.171.04.

Then linux 6.8.5 => 6.9.9 broke nvidia 535.171.04, but nvidia 535.183.01 worked. And most recently linux 6.9.9 => 6.11.9 forced me to upgrade nvidia to 535.216.01.

So that’s why I fear that if Nvidia stops supporting 535 drivers then I will very quickly become locked into a particular kernel version. That’s not an end of the world, Linux provides quite a stable interface and running an older kernel will be okay for quite a while, but I think that after couple years the cracks will start to show.

I think this is also the only reasonable and reliable approach: to jump to the next LTSB stable driver and avoid the other branches under all circumstances (new feature branch and even the production branch, if you ask me).

But it was my understanding that “stable” driver is selected from one of the “production” branches. And since all production branches so far contain The Flickering Bug, we can assume that next LTSB will also suffer from it.