As title says, FreeSync stops working for me after I alt+tab or minimize the fullscreened game window. I mentioned the issue in RADV VRR merge request on Mesa gitlab -https://gitlab.freedesktop.org/mesa/mesa/merge_requests/672 - because I can only reproduce it with Vulkan games, but M. Danzer mentioned other people had it with radeonsi/OpenGL so the problem likely is in xf86-video-amdgpu. All drivers (kernel, mesa, xf86) are latest from git.
As discussed in https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/commit/260d6f0e3c270ebfd7319f2f8fa67beececa68f5#note_145169 I can get Freesync back in World of Warcraft by maximizing other windows over top of WoW and minimizing them all until just WoW is left. Bioshock Infinite is an OpenGL game which displays similar behavior - after alt-tabbing out of the game and returning, Freesync doesn't work. Bioshock minimizes itself if it loses focus, so the trick described above doesn't work. It needs to be closed and run again to get Freesync back. Michel Dänzer suggested it might be a bug in the code keeping track of which window is flipping and whether or not Freesync should be enabled for it.
Please attach the corresponding Xorg log file and output of dmesg, captured after reproducing the problem.
Created attachment 144049 [details] xorg log
Created attachment 144050 [details] dmesg
Created attachment 144119 [details] [review] VRR debugging output Please build the driver with this patch attached, reproduce the problem and attach the resulting Xorg log file. If you can capture the log file locally after each step and then add markers for each step in the attachment, that would be extra helpful.
Created attachment 144141 [details] Xorg log with debugging patch and notes My Xorg log with the debugging patch and notes about what I was doing.
Created attachment 144280 [details] [review] VRR debugging output Thanks, but I had trouble making sense of it. Can you try again with this patch instead? BTW, it looks like VRR is unintentionally enabled during normal desktop operation for you, possibly because the variant of kwin you're using isn't blacklisted in Mesa. This might contribute to the problem.
I can't reproduce the problem any more. I updated to Plasma 5.15.5 from 5.15.0 and now Freesync is properly working whenever I switch back to a game. I had the issue with Freesync not re-activating properly ever since Freesync started working on Linux, and now it's just disappeared. Perhaps it was a KDE bug after all? I am still seeing Freesync active on the desktop, but it doesn't seem to be causing problems now.
(In reply to Peter from comment #8) > Perhaps it was a KDE bug after all? Probably just luck that newer KDE doesn't trigger it anymore. Even a broken compositor / window manager shouldn't be able to cause these symptoms. > I am still seeing Freesync active on the desktop, but it doesn't seem to be > causing problems now. Your compositor should definitely get blacklisted in Mesa though.
I think I am still seeing the same bug, it's just that I'm only hitting it once every few weeks which makes it hard to produce useful information. I see WoW stuttering and Freesync not working, and then I have to try and remember what I was just doing. Today I switched back to WoW and saw Freesync not working. I switched out and back, still no Freesync. I alt-tabbed out and checked my Xorg log file. This was at 110209.766. When I switched back to WoW again, I had Freesync. The relevant section seems to be from 109971 to 110309 in my log file. Alt-tabbing produces those "Deleting VRR property for window 0x2f44c50" lines, but clicking a window on the taskbar doesn't. I think I alt-tabbed away from WoW at 109971.346, and then alt-tabbed three times and clicked WoW once. Between 110209 and 110309 I looked at my log file and made a note of what I'd just been doing, then clicked WoW on the taskbar and had Freesync back at 110309.
Created attachment 144718 [details] Xorg log with second debugging patch
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/issues/3.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.