Bug 477016 - Brightness flicker with adaptive sync
Summary: Brightness flicker with adaptive sync
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: platform-drm (show other bugs)
Version: 5.27.9
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 485144 487697 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-11-14 20:19 UTC by tux
Modified: 2024-11-18 15:21 UTC (History)
16 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tux 2023-11-14 20:19:16 UTC
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)
Comment 1 Zamundaaa 2023-11-15 21:12:41 UTC
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.
Comment 2 tux 2023-11-16 00:26:42 UTC
(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.
Comment 3 Zamundaaa 2024-04-09 11:50:18 UTC
*** Bug 485144 has been marked as a duplicate of this bug. ***
Comment 4 tux 2024-04-17 16:22:47 UTC
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).
Comment 5 Ataberk Özen 2024-04-18 01:55:23 UTC
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).
Comment 6 Ataberk Özen 2024-04-18 02:02:28 UTC
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.
Comment 7 tux 2024-04-18 02:40:06 UTC
(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.
Comment 8 Bug Janitor Service 2024-04-19 21:18:33 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5626
Comment 9 Zamundaaa 2024-04-21 14:55:16 UTC
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
Comment 10 Bug Janitor Service 2024-04-21 14:55:29 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5629
Comment 11 Zamundaaa 2024-04-21 15:12:18 UTC
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
Comment 12 Zamundaaa 2024-05-28 17:19:55 UTC
*** Bug 487697 has been marked as a duplicate of this bug. ***
Comment 13 Adrian 2024-08-26 17:37:59 UTC
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
Comment 14 Adrian 2024-08-26 17:43:34 UTC
Sorry meant to say flicker not flash*
Comment 15 James Le Cuirot 2024-08-30 21:02:40 UTC
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.
Comment 16 Yosuke Matsumura 2024-11-06 16:11:11 UTC
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
Comment 17 Renner03 2024-11-12 22:51:51 UTC
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%
Comment 18 Alexander Streng 2024-11-13 13:09:22 UTC
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.
Comment 19 Florian Franzen 2024-11-18 15:21:50 UTC
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.