Adaptive Sync causes the screen to go blank when the refresh rate drops below a certain value

Make sure that you’re actually using 440.82 first. Ubuntu 20.04 currently installs 440.64 “disguised” as 440.82 for some reason. This also overrides the “legit” 440.82 present in the ppa unless you manually select it. Some other minor problems related to VRR similar to yours (like this one: Adaptive Sync causes screen signal loss after power cycling the monitor) were solved on my machine by simply upgrading to 440.82.

Maybe that’s all it takes. LFC is the only thing that still fails on my end right now.

1 Like

Happy to finally found a thread describing my exact issue.

My panel Acer VG271U is also 48-144Hz.

In Windows the pendulum demo works perfectly, even when forced to a lower FPS I see LFC kick in and refresh rate jumps into the 90s.

I’ve been trying to get Witcher 3 working in Proton but in areas where I’m in the 60s FPS small stutters cause it to drop and I loose display output. My monitor doesn’t do a full reset it just seems to go out of range and then come back. On return it takes an extra second for Gsync to kick in again.

I’ll try raising the minimum variable refresh rate like was mentioned above.

I finally tried the 450.57 drivers and, while they fixed a lot of other problems, this nasty bug is still there… 😟
I wish we had a way to just disable LFC altogether just to be able to see if it’s really the root cause of all this.
I mean… LFC isn’t working properly anyway so why keep it at this point knowing that it could cause much worse problems than occasional tearing.

1 Like

I’m on the 440.100 drivers.

I was also able to help reduce this problem by editing the EDID to a minimum refresh rate of 70Hz. However I am still getting display drop outs in loading screens consistently, and during gameplay although a lot less often.

1 Like

Yeah same thing here on latest drivers and Samsung Odyssey G9 49" with Nvidia 1080

I can confirm the issue on with the driver 450.57 on a 1070

As soon as my fps goes below 48 I get black flickering.
I tried expanding my range to 32hz-75hz but made the problem worse because LFC is not kicking.

Since my monitor does not have LFC on his own I thought putting a larger range would “deactivate” it.

Does the driver emulates LFC for monitors that don’t have it ?

Since my monitor freesync range is kind of short 48-75 and below 48 my monitor flickers, is there a way to “force” LFC ?

I will try to use a higher range like 55-75 to see if it helps.

I did some testing, this was just from general observation but could be totally wrong…

It seems in Windows when FPS drops below 48Hz it then starts frame doubling, so the refresh rate doubles to 90Hz while the game runs at 45 FPS, displaying the same image twice.

In Linux I haven’t noticed any doubling kicking in, as soon as I hit a stutter that send it below 48 FPS I get a black screen so I can’t see what the refresh rate is.

Also worth mentioning I’m on a 1080ti

After playing a little bit with the EDID freesync range of my cheap monitor Acer ET322QU

I went from (48-75) to (51-75) and it stopped 95% of the flicker.

“Flickering” means going from black to normal very fast many times in the span of a second. That’s another known problem with Freesync monitors and Nvidia GPUs. The issue we’re suffering from here makes our monitors go completely blank only to recover after a straight second or so. So is it flickering or is it “blanking” for you?

If your monitor doesn’t have LFC and you still suffer from the same problem as we do, it might be further proof that the currently “borked” LFC implementation that we have now on Linux is not the root cause of the problem but a separate one.

EDIT: I just tried sabotaging again LFC (on Linux this time) by setting my VRR range to 130-240 (so that LFC would never kick-in) and my screen still blanks out… I don’t think we need more proof than this that they are separate problems.

In order to “fully” support LFC, your max refresh rate value must be at least double of your lower VRR range value. With monitors that normally don’t support LFC like yours, you can usually try to extend your lower VRR range value. Setting yours to 37-75 should be enough to enable LFC. Not all monitors can handle this though and, more often that not, you’ll get flickering or blanking as a result. Some cheap monitors can’t even handle the range they advertise and they show these symptoms even without any EDID editing…

1 Like

Agreed it does sound different, my problem is definitely not flicker, the panel goes black for a second or two before showing an image again.

Let’s hope Nvidia can replicate and resolve this

I discovered another little detail that might become relevant at some point (I hope). I recently installed the same game (No Man’s Sky) on both Windows and Linux this time in clean environments.

Since my monitor’s VRR range is 48-240, at some point during the initial loading screen, my monitor’s HUD on Linux shows a stable refresh rate of 48. That checks out but, shortly after, the screen still blanks out.

On Windows though, at the same point during the same loading screen, it always showed a steady 49. Never going all the way down to 48 and never blanking the screen. Since Windows never suffers from this screen blanking bug (unless I try to manually sabotage LFC and set the refresh rate to 47 or lower), I thought this might be relevant.

Maybe it’s a rounding error somewhere rounding “48” down to “47”. I suppose I should be talking about frametimes here instead of Hz but I hope you get the idea…

Since the code base is the same between the two, I also thought of some possible compiler shenanigans going on here… I don’t know what is used to build everything in Windows but, on Linux, I wonder if the nvidia kernel module can be built using clang instead of gcc just to see if something changes…

Also I just realized that it’s been a whole year since I reported this bug. I didn’t organize anything for the occasion but I promise that I’ll come prepared for the second anniversary next year. ;P

I’m also getting this issue with anything full screen. I thought the 460 drivers had fixed it but it has re-emerged. Everything works fine on Windows on the same machine. It’s AOC Gaming 24G2U monitor with a 1060 card.

Also chipping in to say I am still experiencing this issue under Linux, I have done a fresh install since the last time I posted. I am running the 460.32.03 driver.

Well, I recently tried an AMD card with the same exact hardware: same monitor, same cable, same motherboard all except the GPU. Suffice to say that, contrary to my 1070ti, both variable refresh rate and LFC worked perfectly fine.

This black screen bug is a major issue worthy of the “Novideo” meme and should be high on the priority list but, instead, more than a year later, nothing has changed.

I’d still very much like to see this bug fixed or at least addressed in some way or another. Even being able to disable LFC altogether could be a big improvement since occasional tearing when the fps drop would be much better than frequent random black screens.

Is this ever gonna get fixed @aplattner? 😟

1 Like


Hello again :)

Today I decided to revisit using GSYNC on my machine and dropped back to 1 monitor (damn X11).

My face lit up when I turned on the refresh rate display on my monitor and saw a constant 48 (my monitors min refresh rate) during the loading screen. Previously as soon as I saw 48 I was guaranteed a drop but today it didn’t happen.

I have only tested for about 30 seconds as I was so excited I had to reply :D I did get 1 small stutter during my quick test and again there was no drop.

Driver version - 465.27 - Running Arch - just ran updates today.

Any change on your end? Fingers crossed we can finally enjoy GSYNC, it’s sooo smooth

Unfortunately I’m unable to test 465.27 now since all I could get after installing it is a total system freeze after install. This was with multiple distros and all on fresh installs… I guess I’ll have to wait for it to be packaged by main distro.

The changelog mentions a black screen fix with active DP dongles but nothing specific about GSYNC.

The latest driver that I managed to get working is 460.73.01 and it works just as bad as it always did.

Yes unfortunately although I had good success for the first day the issues have returned since.

I hope the NVIDIA are able to get back to their offices and do some more testing for us… Or at least gave us guidance on any help we could provide :-(

Just wanted to add some further details in case this helps.

When the display output drops it almost seems to crash my monitor. If I have the monitor’s menu open at the time it exits out and I have to re-open it when the display comes back.