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.
@roliverio
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!
I’ve tested the 545.23 beta driver directly from nvidia (the .run file), with a clean xorg.conf file… the flickering IS WORSE THAN EVER!. i cannot even properly run the debug report.
I cannot believe that this issue is still ongoing.
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.
Please @aplattner / @amrits Take a look on the bug report so as to do a proper case follow-up or to tell me what additional information you would require.
roliverio, you are right, the same summary from my side regarding testing the latest 545.29.06 version. It still flickers, display is going to suspend, but maybe less often, and you are right that probably the non-primary display goes to suspend more often then primary one. Regarding HDMI, in my case it is similar, 2 DP displays and issue is there, if I add third HDMI display, it is better, usualy after system startup one of displays is off, but then it occurs very rarely.
Another issue that I spoted is, with the latest version of drivers, when system is restarted, displays are usually off and I do not see the BIOS screen and then the GRUB menu. I tried to open lid and check GRUB there, but also internal display is off, even when TB dock is disconnected it is still off. But system is responding, when OS is started, displays are enabled again. This does not occur with 525.85 version.
I have been using the 545.29.06 version for while and I would say there is no difference between primary and non primary display, both suffer by this issue moreless same. Also tried to suspend and wake system again to verify that issue is gone as it was rumored, but unfortunatelly I did not notice any difference. One of display is flickering/going to suspend every about 15-30min.
I have definitely traced this back to NVIDIA Drivers, having tried with different monitors and a couple of different docks (a thunderbolt and an USB-4 one which supports DP-Alt) with more than two monitor combinations.
@amrits, @aplattner Whenever you finish tracing back other outstanding issues, please go back to this issue which, as i said, is present on any newer version since 525.85.12. Thanks.