G-sync causing display signal loss

I wonder if this is a known issue and if someone has any idea in which component the issue is.

I’m using Fedora/Gnome and Nvidia linux driver 430.34 (GTX 1070 card). The issue has existed in several past versions of the linux driver (as long as I’ve had this monitor). Monitor is Samsung LC34F791WQUXEN. This is an ultra-wide (21:9) 34" 100 Hz screen with freesync support. I use displayport cable directly connected to the screen.

After starting the PC and immediately starting a game with G-sync on (and with “Allow G-SYNC on monitor not validated etc.”), everything works fine. The game plays with G-sync and refresh rate looks variable (everything plays smooth and nice). On-screen indicators show FLIP - VSYNC ON and G-SYNC. But when I pause the game and let the Gnome screensaver lock the screen, then unlocks screen and continue gaming, the monitor starts to turning the input off and on every few seconds (like it has lost the signal). To get it to stop losing signal you must quit the game or alt-tab to desktop. This stops the input signal flipping. Now to get it to work again in the game, you can reboot the PC, or simply turn off g-sync in Nvidia settings. Another way without rebooting is to change Resolution in Nvidia-settings from Auto to 3440x1440 and then set resfresh rate to 60 Hz (sometimes toggling a couple of times between 60 and 100 Hz is necessary). Then when starting the game it is like the driver “takes over” and G-sync then drives the refresh rate up to 100 Hz and keeps it on. So toggling screen refresh rate somehow resets the issue.

To me this looks like something maybe in gnome-shell or mutter “disturbs” the Nvidia driver g-sync feature and “takes over” refresh of the screen. There is nothing in logs that would tell anything about the problem. I haven’t found anything similar reported in gnome and mutter issues at their gitlab.

Also when the screen is in the “signal loss mode” (with g-sync turned on) and start for instance VLC media player, the screen also starts losing signal in the same way when viewing video in fullscreen mode. Solution is to turn off g-sync or reboot the computer (or doing the same refresh rate toggling).

As I don’t know in which component this problem lies, I’m asking here now.

1 Like

Please check if the correct screen refresh rate is set in the gnome control center.

It’s set to 99.98 Hz. That’s what I set it to when I bought the monitor.

It is the screen blanking that does it after locking the screen. If you interrupt with a key or mouse before the screen blanking sets in, you can unlock the screen without this happening. But as soon as you let the screen go blank, then it “destroys” g-sync.

I tried another thing. This system has CSM enabled in EFI (BIOS) due to a SAS card (I think) that I used in the past. Now I tried to disable CSM. This enables a bootup screen with HD resolution etc. But now I can’t use G-sync at all. The screen begins turning on and off (same as before) whatever I try (turning off G-sync helps). I had to enable CSM again, and now the behavior is as before.

Edit. Tried to turn off CSM again and after rebooting a couple of times the above cannot be repeated. Initializing with EFI or BIOS shouldn’t have anything to do with the problem. Back to square one.

There is something crazy going on with CSM. Don’t know if it is related to the original problem, though. CSM doesn’t stay off, but turns itself on when doing a power on. It stays off while rebooting only. So something with this motherboard (Asrock Z97 Extreme 4), the graphics card (MSI GeForce GTX 1070 Armor OC 8GB) or the monitor (Samsung LC34F791/CF791) doesn’t like EFI mode. Looks like some other people have the same issue, too. Maybe firmware upgrade could help. I see that there is this: NVIDIA Graphics Firmware Update Tool for DisplayPort 1.3 and 1.4 Displays. Could maybe help, maybe not? The monitor is DP 1.2, though. But I can’t run the tool, looks like there is no linux version. If the Displayport part of firmware is available, maybe it could be flashed with nvflash? Looks like questions like these are not easily googled.

I have a similar issue on a VG271U - although it pretty much happens on any OpenGL/Vulkan game. The screen basically continually turns itself on and off (even without alt-tabbing), currently using the latest KDE/Plasma and NVIDIA driver. Makes Freesync/GSync pretty much useless.

Interesting. I’m using Gnome. As soon as I press Alt-tab output changes from FLIP to BLIT, which disables GSYNC (and display stops turning on and off). You can see the status if you turn on the Graphics API Visual Indicator in Nvidia-settings.

I’m also having the same issue, so far I’ve tried:

1/ Custom EDID with a refresh range from 40-144 to 57-144.

2/ Lowering the refresh rate down to 120hz as well as resolution back to 1080p.

3/ Switching between Gnome & Plasma.

4/ Changing the DP cable to one of better quality.

5/ Different display ports.

On Windows the display works perfectly with gsync compatible on, recent drivers on Linux it happens “less” than it used to but it still goes black when loading shaders etc.

I think LFC – so doubling of frames – does not work.

It may not be the only issue but what I found is interesting.

On Windows the driver seems to apply it’s own LFC range for my monitor of 53-144 hz and I can’t override this via CRU but the most interesting thing is that there appears to be a smoothing curve.

To explain this better I’ll use the following keys:

or < = no doubling

or << = doubling

Now for Win 10 decreasing fps goes like this:

40 fps << << << << 53 fps < < < < 60fps < < < < 80 fps < < < < 144 fps

But increasing fps:

40 fps >> >> >> >> 53 fps >> >> >> >> 60fps > > > > 80 fps > > > > 144 fps

On Linux the other hand, the behaviour has no smoothing (using 53-144 hz EDID in this example):

Down:

40 fps << << << << 53 fps < < < < 60fps < < < < 80 fps < < < < 144 fps

Up:

40 fps >> >> >> >> 53 fps > > > > 60fps > > > > 80 fps > > > > 144 fps

Now I don’t whether there’s other issues with the driver or mutter however the lack of this smoothing behaviour on Linux is probably having an affect especially in cases where fps spikes up then back down again like loading screens.

I would really like this issue resolved soon though, I’ve heard AMD doesn’t have this issue and it’s getting around the time I need to upgrade.

No, AMD also has this issue on old GPUs.

But it could be fixed with this drm/amd/display: Improve LFC behaviour · torvalds/linux@bb2746a · GitHub

Note that there are two issues described in this thread. My original post describes the phenomena of screen going totally black with g-sync after display has been switched off or gone to sleep. I’ve posted a video describing the issue here https://youtu.be/q6-i82U64cc.

Looking at that commit, the desynchronized frames issue causes odd tearing & stutters on AMD rather than display loss we are seeing here.

I’d rather that than the display resetting every 5 minutes as at least that’s partially usable.

Also @jukk

I can sort of reproduce that also, if I manually turn the screen off & on I can’t get the game back on screen without the display losing signal entirely. Only if I turn off G sync it gets back.

I have the exact same issue on Pop!_OS 20.04 and the 455.23 driver.
Kernel: 5.4.0-7642-generic
I am using an ASUS VG27AQ G-Sync Compatible monitor. As soon as my screen goes blank after locking the screen, G-Sync is broken and I have to log out and log back in to make it work again.
Some people have said that a driver update has fixed the issue, but not for me.

So now the Samsung monitor broke and I bought an MSI monitor (MSI Optix MAG342CQRV 34"). Everything works perfectly with this one, so I suppose there was a hardware/software issue with the Samsung.