As you yourself reported, and many others around other threads (non TB-specific) the flicker is still present, I’ve had to patch 525.85 to be able to build it on 6.3 and 6.4 Kernels, because, otherwise, i cannot upgrade the kernel, and clearly, moving to another driver is not possible due to the bug.
@aplattner / @amrits I know there are several cases opened internally on the issue, and frankly, with this issue nearing its 9th month, we would appreciate if it is being given priority.
We are actively working on flickering issue and trying to get internal repro with latest release driver.
I had internal repro with older driver earlier. Would be helpful if you can share nvidia bug report; display model with resolution and refresh rate and concrete repro steps to recreate issue.
Regarding the other issue (suspend issue), it will be great if you can initiate new thread with detailed description, nvidia bug report and repro steps to recreate issue.
Hi @roliverio ,
I have tested the version 535.113.01 in last 2 days and the suspend issue is still there. Maybe it occurs a bit less often, but it is hard to say, because it is very random (in past it went to suspend mode sometimes 10x per hour, sometimes 2x per day).
What I can confirm since version 535.43 is, that displays do not go to suspend if there is +one HDMI monitor connected to my dock station (HP G4 Thunderbolt).
When I use it in 2 x DP displays (1920x1080 60Hz, Philips 243V) configuration, there is this suspend issue,
but when I add third HDMI display - this dock do not have another DP port - none of displays go to suspend, just sometimes after startup, or after resolution change, one of displays is suspended, but never randomly during regular work. Just this small info, if it helps to track the issue.
I am keeping my finger crossed that this issue will be solved soon.
Some other threads mention a workaround by suspending the machine and then resuming it. It apparently solves the problem temporarily until the next reboot. Could you do us a big favor seeing if this workaround works with the Displays on DP through your TB dock?. Thanks!
For my probably related issue, they did put a lot of effort into trying to reproduce my bug.
I also tested the new driver and it solved my issue.
Given that this thread contains no reports if you can repro the issue on Wayland compositors & Windows whatshowever, I don’t see many clues that would help Nividia staff to figure this out, nor am I convinced this ever got filed to the actual bugtracker. You have to take into account that the change introducing your issue might be a bug fix for other people.
I’ve updated to 545.29.06 using the standalone installer (as in, removed all the distro packages) and runt the nvidia native installer.
The flicker is still there, however, just as a reference, i’ve switched the connections on the TB dock from DP to HDMI to the monitors (note that the Xserver still thinks that the displays are DisplayPort), note that if i use the DP native connections from the dock the flicker is much worse at the point of being unable to work, as always. (if i use 525.85 with the monitors in DP to the dock all works flawlessly)
The flicker now is “decent” in the sense that it flickers/blacks out briefly but randomly, however, it takes at least an hour between ocurrences, and, for reference, it’s 4 out of 5 times on the display that’s not set as the primary X display.
A couple of discoveries with the DP to HDMI change:
The NVIDIA driver is now not able to detect GSYNC compatibility of my monitors (it does under DP), even if i’m trying to force the detection of GSYNC compatibility via the Xserver configuration.
nvidia-autoselect setting on “MetaModes” causes the X server to take more time to set the preferred resolution on start.
I’m ultimately adding the Bug report because i feel the issue is close to being solved, and OTOH, i’m fed up with patching new kernels to work with 525.85.