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. ***
I've also been having constant issues with VRR on automatic mode enabling on programs like firefox, mpv, virtual machine manager and so on. While they are on full screen it causes the refresh rate constantly jump between 45 hz and 165 hz causing my display to flash pretty badly. I think the severity on this bug should probably be increased as this flashing I think could seriously cause someone epilepsy. SOFTWARE/OS VERSIONS Distro: Arch Linux Kernel Version: 6.10.6-arch1-1 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 GPU: RX7900 XT Mesa: Mesa 24.1.6-arch1.1
Sorry meant to say flicker not flash*
I don't think a simple blocklist is really the way to go. This could happen in any application depending on what it's doing, and some screens are probably more sensitive to it than others. There was an interesting discussion around this in https://github.com/swaywm/sway/issues/5076. Sway doesn't even have the "auto" option that KDE currently has, but I think the other options discussed there sound promising.
I am also experiencing this issue intermittently. I can't identify how to reproduce it reliably just yet. But I've noticed that sometimes when Adaptive Sync is set to "Always", and you let your screen/mouse idle, the frame rate drops to ~48fps and that is when I notice the flicker. I have a 120hz monitor. When the Adaptive Sync is changed to "Automatic" or "Never", then the screen frame rate stays at 120fps and the flicker no longer happens. Fedora 41 Kernel 6.11.5 Plasma 6.2.2 Frameworks 6.7.0
I can reproduce this on my 360 Hz Monitor (Dell AW2725DF) with Adaptive Sync set to automatic. It does not show when I record the screen with OBS. It happens when I right click a Firefox Picture-In-Picture YouTube video that is fullscreened/maximized/double clicked and the context menu, that would otherwise show up when clicking on a title bar pops up. Also happens on fullscreened KeepassXC, systemsettings, bottles, chromium, steam when I move the mouse cursor on the window. HDR is turned on. I lowered the brightness with the powerdevil applet. The color of the window also changes depending if its fullscreened or not. It seems like it wants to be brighter (back to 100%) for a short amount of time and then remembers to lower the brightness thus resulting in a flicker? When I activate the show fps effect it flickers only when I trigger full screen (I bound it to keyboard). When I disable HDR/use 100% Brightness with HDR the flicker is way more subtle. When I disable adaptive sync the supposed HDR/Brightness issues go away. When I set it to "always" the flicker is like twice as bad. Is this still the same bug or unrelated will open a bug if necessary. Will happily logs. Operating System: Bazzite 41 KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.7.0 Qt Version: 6.8.0 Kernel Version: 6.11.5-307.bazzite.fc41.x86_64 (64-bit) Graphics Platform: Wayland Graphics Processor: AMD Radeon RX 6750 XT Output: 1 DP-2 enabled connected priority 1 DisplayPort Modes: 1:2560x1440@60! 2:2560x1440@360* 3:2560x1440@240 4:2560x1440@144 5:2560x1440@120 6:1920x1200@60 7:1920x1080@240 8:1920x1080@120 9:1920x1080@120 10:1920x1080@60 11:1920x1080@6012:1920x1080@60 13:1920x1080@50 14:1920x1080@30 15:1920x1080@30 16:1920x1080@25 17:1920x1080@24 18:1920x1080@24 19:1600x1200@60 20:1680x1050@60 21:1600x900@60 22:1280x1024@75 23:1280x1024@60 24:1440x900@60 25:1280x800@60 26:1152x864@75 27:1280x720@60 28:1280x720@60 29:1280x720@50 30:1024x768@75 31:1024x768@60 32:800x600@75 33:800x600@60 34:720x576@50 35:720x480@60 36:720x480@60 37:720x480@60 38:720x480@60 39:640x480@75 40:640x480@60 41:640x480@60 42:640x480@60 43:720x400@70 44:1600x1200@60 45:1280x1024@60 46:1024x768@60 47:1920x1200@60 48:1280x800@60 49:2560x1440@60 50:1920x1080@60 51:1600x900@60 52:1368x768@60 53:1280x720@60 Geometry: 0,0 2048x1152 Scale: 1.25 Rotation: 1 Overscan: 0 Vrr: Automatic RgbRange: unknown HDR: enabled SDR brightness: 465 nits SDR gamut wideness: 100% Peak brightness: 465 nits Max average brightness: 277 nits Min brightness: 0.0003 nits Wide Color Gamut: enabled ICC profile: none Color profile source: sRGB Brightness control: supported, set to 100%
In my case when adaptive sync is in "automatic" mode, the brightness flickering seems to be noticeable when for instance a game runs below 80 fps. Meanwhile on "always" setting, flickering happens every mouse movement.
Same issue here as @renner03 on plasma 6.2.2. Mostly fullscreen apps with dark background show the issue (with "automatic" VRR). Moving the mouse stops the flickering in most apps.
Using Plasma Wayland here on arch linux and I notice its pretty bad flicker at times with HDR enabled as well. I believe this flicker is also passing off into games that run via proton/gamescope and is a bit unfortunate. I use a 4090 on a LG C4 for testing. Doesn't happen under Windows. I believe VRR is also have issues because the frames presented appear to be rather rough after a short period of time.
This got much worse after a recent update, if I run mpv on a 240hz with a disable adaptive sync window rule it still flickers around the 230-250hz range while it previously would have been locked at 240hz
(In reply to calvin from comment #21) > This got much worse after a recent update, if I run mpv on a 240hz with a > disable adaptive sync window rule it still flickers around the 230-250hz > range while it previously would have been locked at 240hz Scratch that, it's actually related to this: https://discuss.kde.org/t/adaptive-sync-refresh-rate-becomes-unstable-after-log-out/20197 Looks like overclocking my GPU made it flicker, I set it back to high and it was fine, hopefully upcoming AMDGPU clock changes in 6.13 don't break vrr.
I am also experiencing this on My computer with an MSI 321UP QD-OLED. It's a bit weird though, on Firefox, the refresh rate is 165hz when a video is playing or mouse is moving, but goes down to 48 Hz when video is paused and cursor isn't moving. On Chrome, the refresh rate is goes down to 48 Hz when video is paused and cursor isn't, it goes to 165 Hz when cursor is moving, but it's very unstable when video is playing, fluctuating from 48 to 165 Hz and everywhere in between...
I'm experiencing a similar phenomenon when I have VRR set to "Always" and it defaults to 48hz instead of the set desktop refresh rate of 120hz and when short animations play (such as steam animated avatars), the refresh rate cycles through the range repeatedly rather than just setting to 120hz. I took a short video on my phone ( https://youtu.be/nj7FB1_pWw8 ), I would use "Automatic" VRR which appears not to have this particular issue on my configuration but that gives me a black screen every time it switches on or off which makes it unusable. It would be very nice if the "Always" VRR refresh rate would set to the desktop refresh rate and only 'unlock' when "Automatic" VRR would enable. My specs: Screen: Samsung QN90C 43-inch (With Freesync Premium Pro compatibility) Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.2 Kernel Version: 6.13.10-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 7800 XT Product Name: X570 Steel Legend
Operating System: CachyOS Linux KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.9.0 Kernel Version: 6.14.2-2-cachyos (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 94.2 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4090 Monitor: Asus PG32UCDM 4K 240HZ Freesync Premium Pro 48-240hz Manufacturer: ASUS When Adaptive sync is set to always, refresh drops to 48hz and stays there until the mouse cursor is moved. When the mouse cursor is moved, it ramps up to 240hz. This will sometimes black screen my OLED monitor after a bit. When it is set to automatic, watching full screen video like Youtube, causes the refresh to change erratically from 48-240hz and sometimes this will black screen my OLED monitor. This makes VRR unusable in the state that it is in. The default behavior should be determined by the gpu. If the gpu can output 240fps then the refresh rate should be 240hz.
(In reply to AdamKafei from comment #24) > I'm experiencing a similar phenomenon when I have VRR set to "Always" and it > defaults to 48hz instead of the set desktop refresh rate of 120hz and when > short animations play (such as steam animated avatars), the refresh rate > cycles through the range repeatedly rather than just setting to 120hz Yes, that's what adaptive sync does, it matches the refresh rate of content on the screen. If there's no movement on the screen, it goes to the minimum refresh rate. > It would be very nice if the "Always" VRR refresh rate would set to the desktop refresh rate and only 'unlock' when "Automatic" VRR would enable. I would like to do that, but it's a bit more challenging than it seems. We don't actually set any refresh rate with VRR, we just push frames to the kernel, and it makes the screen follow the rate of those frames. If we start constantly pushing frames to keep the screen at full refresh rate, the kernel will also keep the GPU fully enabled, wasting lots of power. Maybe we could start doing it on external displays only, because it shouldn't be much of a problem on desktop PCs... but we really need actual driver APIs for doing this stuff properly. (In reply to Tim from comment #25) > When Adaptive sync is set to always, refresh drops to 48hz and stays there > until the mouse cursor is moved. When the mouse cursor is moved, it ramps up > to 240hz. This will sometimes black screen my OLED monitor after a bit. When > it is set to automatic, watching full screen video like Youtube, causes the > refresh to change erratically from 48-240hz and sometimes this will black > screen my OLED monitor. This makes VRR unusable in the state that it is in. That's unrelated to this, and a driver bug, which you can report at https://forums.developer.nvidia.com/c/gpu-graphics/linux
How is mine a driver bug yet exactly what people are reporting?
Brightness flicker means that the image gets *a tiny bit* brighter or darker, not that the display turns off for a moment. What you have is almost certainly that the driver lets the display go out of its supported refresh rate range, making it turn off instead.
> I would like to do that, but it's a bit more challenging than it seems. We > don't actually set any refresh rate with VRR, we just push frames to the > kernel, and it makes the screen follow the rate of those frames. If we start > constantly pushing frames to keep the screen at full refresh rate, the > kernel will also keep the GPU fully enabled, wasting lots of power. > > Maybe we could start doing it on external displays only, because it > shouldn't be much of a problem on desktop PCs... but we really need actual > driver APIs for doing this stuff properly. This is interesting and I admit I'd never have thought of that, how is it handled in VRR off mode? And is there any way to perhaps use that code/method without actually turning off the VRR to achieve a 'resting' frame rate?
(In reply to AdamKafei from comment #29) > This is interesting and I admit I'd never have thought of that, how is it > handled in VRR off mode? We just tell the driver to turn VRR off entirely, and we do the same with "Automatic" when there's no fullscreen window. If you use the inferior display connection, HDMI, that's not guaranteed to work smoothly, turning VRR on or off may also turn the screen off for a moment - as you noticed yourself.
(In reply to Zamundaaa from comment #30) > We just tell the driver to turn VRR off entirely, and we do the same with > "Automatic" when there's no fullscreen window. Sorry for my ambiguous wording, I meant as regards achieving the static refresh rate. You explained that "We don't actually set any refresh rate with VRR, we just push frames to the kernel, and it makes the screen follow the rate of those frames. If we start constantly pushing frames to keep the screen at full refresh rate, the kernel will also keep the GPU fully enabled, wasting lots of power.", please forgive my ignorance but wouldn't VRR Off just be pushing X frames per second, resulting in the same amount of GPU usage as a VRR on pushing the same X frames per second?
> wouldn't VRR Off just be pushing X frames per second, resulting in the same amount of GPU usage as a VRR on pushing the same X frames per second? On a very basic setup, yes. When the driver knows for certain that the content on the screen doesn't change though, it can optimize a lot - for example on laptops, tech like PSR allow it to just tell the display that it should keep showing the last frame, without needing to keep sending the same image to the display all the time. There is a way to tell the driver which parts of the image changed (and I think you can send an empty rectangle too) but I'll have to experiment with that to figure out how well it works / how much the drivers actually use that. There's also CPU usage; telling the kernel to re-submit the last image takes some amount of CPU power and wakes the CPU up frequently, while the GPU passively sending the last image repeatedly doesn't require the CPU to do anything.
I'm beginning to see how this could get complicated, thank you for your patience and explanations.
Automatic works in sense to enable it for games, and all other full screen apps... But as I have other apps using in fullscreen, but not that many, I have setup KDE Special windows settings for them (for brave so full screen youtube videos dont flicker and thincast, so my dual monitor setup remote into work laptop from pc doesnt flicker, just added Addaptive sync to Force No and it works as a workaround.
(In reply to Zamundaaa from comment #32) >There is a way to tell the driver which > parts of the image changed (and I think you can send an empty rectangle too) > but I'll have to experiment with that to figure out how well it works / how > much the drivers actually use that. Have you had any luck with this?
(In reply to Zamundaaa from comment #28) > Brightness flicker means that the image gets *a tiny bit* brighter or > darker, not that the display turns off for a moment. What you have is almost > certainly that the driver lets the display go out of its supported refresh > rate range, making it turn off instead. Blurbusters have an article about this here https://forums.blurbusters.com/viewtopic.php?t=9249 black screen problem. It seems to happen a lot more with Freesync monitors. Monitors with the Gsync module do not have this issue because the module can handle FPS down to 1. As far as the VRR defaulting to 48hz, this behavior does not make sense to me. 48hz is low and kind of defeats the point of having a monitor that can do much higher refresh. If the GPU can do 240 FPS then the refresh needs to follow the GPU in my opinion. With VRR off, Kwin debug and the FPS counter on, we can see that on my system I getting around 230 FPS per its reporting and is somewhat stable. Turning on VRR causes the FPS to tank and is all over the place. If it is indeed to conserve power, why would it consume more power than when it is off and doing an higher FPS? With these modern GPUs, they can refresh a 2D desktop screen at max and not even break a sweat.
(In reply to AdamKafei from comment #35) > (In reply to Zamundaaa from comment #32) > >There is a way to tell the driver which > > parts of the image changed (and I think you can send an empty rectangle too) > > but I'll have to experiment with that to figure out how well it works / how > > much the drivers actually use that. > > Have you had any luck with this? Unfortunately PSR doesn't seem to be working on my laptop, so I haven't been able to test it properly. (In reply to Tim from comment #36) > As far as the VRR defaulting to 48hz, this behavior does not make sense to > me. 48hz is low and kind of defeats the point of having a monitor that can > do much higher refresh. If the GPU can do 240 FPS then the refresh needs to > follow the GPU in my opinion. With VRR off, Kwin debug and the FPS counter > on, we can see that on my system I getting around 230 FPS per its reporting > and is somewhat stable. Turning on VRR causes the FPS to tank and is all > over the place. If it is indeed to conserve power, why would it consume more > power than when it is off and doing an higher FPS? With these modern GPUs, > they can refresh a 2D desktop screen at max and not even break a sweat. There is no default refresh rate. When nothing changes, fps just goes down, that's how adaptive sync is meant to work. If you don't like it, don't use it. This is also not related to the bug report.
I learned today that there were options to show kwin's frame rate "Paint Duration" and "Paint Amount", also that I can have it show me recently updated parts of the screen. When I enable the latter during rapid refresh cycling it shows seemingly random parts of the image being redrawn even though nothing I can see has changed, what's most interesting though is when I enable the "Show FPS" option in the "Desktop Effects" menu it settles right down and shows me 120 fps. Steam's friend window with it's animated avatars still caused a lot of draws even though the avatars themselves were behind an opaque window but it wasn't causing the refresh rate to go haywire anymore, I did also notice if I move the mouse rapidly and cause names to highlight/dehighlight rapidly too for a couple of seconds at a time the fps would drop down to about 60, I found that a little interesting. The final point of interest for this update is that when I turn off the "Show FPS" effect the refresh cycling returns instantly, I can switch it on and off with the "Show FPS" effect as reliably as with the Adaptive Sync on/off setting.