When adaptive sync / VRR is set to "Automatic" in "Display Configuration", it's always enabled in full-screen programs, even when `adaptive_sync` is set to `false` for that particular program in `/usr/share/drirc.d/00-mesa-defaults.conf`. E.g. adaptive sync is blocked by default for Firefox in `00-mesa-defaults.conf`, but adaptive sync still gets enabled when setting Firefox to full-screen in KDE. Because of this, moving (and stopping) the cursor in full-screen mode in Firefox causes the refresh rate to rapidly fluctuate between the lowest refresh rate (e.g. 48 Hz) and highest refresh rate (e.g. 240 Hz). This causes a lot of brightness flickering on VA monitors (and possibly some IPS monitors as well). There also doesn't seem to be a way in KDE to disable VRR for a specific program. The only related rule property that can be added in "Window Rules" is to block compositing, which doesn't help. So two problems: 1. KDE seems to ignore `/usr/share/drirc.d/*.conf`, at least for `adaptive_sync`. Is this a KDE bug or is there a problem somewhere else? 2. KDE doesn't have any way to force disable (nor enable) VRR just for a specific program. Adding an "adaptive sync" rule property to "Window Rules" seems like a simple solution. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 Kernel Version: 6.6.1-arch1-1 (64-bit) Graphics Platform: Wayland Graphics Processor: AMD Radeon RX 6650 XT (driver: amdgpu)
It's not a bug, Mesa enabling or disabling vrr for specific fullscreen programs is an X11 thing and has no relevance on Wayland. The brightness flicker is something that I consider a bug, and one that should be fixable in KWin.
(In reply to Zamundaaa from comment #1) > It's not a bug, Mesa enabling or disabling vrr for specific fullscreen > programs is an X11 thing and has no relevance on Wayland. > The brightness flicker is something that I consider a bug, and one that > should be fixable in KWin. The brightness flicker is fixable by disabling VRR for any fullscreen desktop programs with (frequent) user input, like Firefox. I just tested it in Windows 10, and there VRR is also disabled in browsers when they're fullscreen. And as many programs/games don't play nice with VRR (causing flickering and/or stuttering), it would be very nice to be able to add a rule property in Window Rules that controls VRR for a certain window/program. As a side note, being able to add a rule property in Window Rules that can automatically set a refresh rate depending on the program/game would also be great. Though a lot less important than being able to control VRR per program/game.
*** Bug 485144 has been marked as a duplicate of this bug. ***
I did a system upgrade, including some KDE packages (to v6.0.4) , and now the brightness flickering even happens when watching a video in fullscreen. Before the update, watching a fullscreen video would set the refreshrate to its maximum, preventing flickering. The only workaround is to disable VRR completely (from Automatic -> Never in system settings).
There's a regression in 6.0.4 release of kwin. I've downgraded it back to 6.0.3 and everything is fine here. Adaptive Sync seems stuck at 74hz at any refresh rate. This behaviour can be confirmed best with https://github.com/Nixola/VRRTest Mangohud can't make sense of what it is seeing as launching any application with mangohud results in flickering hud and mangohud thinking FPS is 0. GPU utilization is unstable with games I've tested. Utilization goes up and down (e.g alternating between 70 and 99/100).
To add to my last comment, utilization going up and down costs around 20% in average FPS. Looking at the same place from the same angle results in average FPS of 96 with kwin 6.0.3 whereas it's jumping between 74 and 78 with kwin 6.0.4.
(In reply to Ataberk Özen from comment #5) > There's a regression in 6.0.4 release of kwin. I've downgraded it back to > 6.0.3 and everything is fine here. I just tried playing a game and it stutters like crazy, even with VRR completely disabled through my monitor. I tried downgrading all plasma packages to 6.0.3, but plasma wouldn't start anymore.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5626
Git commit fba948b39f6e3b2e70caa1880903f8fb17faf6d9 by Xaver Hugl. Committed on 19/04/2024 at 21:06. Pushed by zamundaaa into branch 'master'. scene/workspacescene: don't check direct scanout candidates for a pixmap We don't need a pixmap for direct scanout, and the drm backend destroys the pixmap when direct scanout is successful... so this check created a loop of direct scanout working and not working, and worse, the client reallocating its buffers each time. Related: bug 485639, bug 485730, bug 485712 M +1 -11 src/scene/workspacescene.cpp https://invent.kde.org/plasma/kwin/-/commit/fba948b39f6e3b2e70caa1880903f8fb17faf6d9
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5629
Git commit fbd780186c76764617dba0365b9ca3de7cfe2f86 by Xaver Hugl. Committed on 21/04/2024 at 14:55. Pushed by zamundaaa into branch 'Plasma/6.0'. scene/workspacescene: don't check direct scanout candidates for a pixmap We don't need a pixmap for direct scanout, and the drm backend destroys the pixmap when direct scanout is successful... so this check created a loop of direct scanout working and not working, and worse, the client reallocating its buffers each time. Related: bug 485639, bug 485730, bug 485712 (cherry picked from commit fba948b39f6e3b2e70caa1880903f8fb17faf6d9) M +1 -11 src/scene/workspacescene.cpp https://invent.kde.org/plasma/kwin/-/commit/fbd780186c76764617dba0365b9ca3de7cfe2f86
*** Bug 487697 has been marked as a duplicate of this bug. ***