Bug 500685

Summary:	Adaptive Sync randomly causes refresh rate to get stuck at 48Hz
Product:	[Plasma] kwin	Reporter:	madness742
Component:	wayland-generic	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED UPSTREAM
Severity:	normal	CC:	nate, xaver.hugl
Priority:	NOR
Version First Reported In:	6.3.1
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=498573
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	3840x2160 monitor set to 2880x1620.

Description madness742 2025-02-24 18:40:17 UTC

SUMMARY
KWin will randomly drop my refresh rate to 48Hz on the desktop, plasma applications and chromium browser. Oddly enough when maximizing firefox, the monitor jumps back to 144Hz. Hovering Konsole over a maximized firefox window will cause the refresh rate to drop back to 48Hz.

I haven't been able to find a consistent way of reproducing this. Changing the Adaptive Sync option from 'Automatic' to 'Never' in these situations does not resolve the issue. The monitor will continue using 48Hz until I unplug and re-plug the monitor.

With the default logging rules I can't see anything useful in `journalctl`. 

I've plugged both monitors into the same GPU (7900 XTX), and I haven't tested if a single monitor setup also suffers from this issue. 

Oddly enough this problem also occurs on Gnome 47 with the experimental VRR setting, indicating it's an AMDGPU problem. 

STEPS TO REPRODUCE
1. Set Adaptive Sync to 'Automatic' [Default setting on VRR-capable displays].
2. ..Wait until the bug appears.

OBSERVED RESULT
The desktop, and many of the applications, will use the lowest refresh rate of the monitor. Which is 48Hz in my case.

EXPECTED RESULT
The refresh rate should stay at 144Hz. Like it does, vast majority of the time.

SOFTWARE/OS VERSIONS
Linux: Fedora 41
KDE Plasma Version: 6.3.1 
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2

ADDITIONAL INFORMATION
GPU: AMD 7900 XTX (Nitro+)
Mesa: 24.3.4
Kernel: 6.12.15 (also occurs on 6.13.2)

Comment 1 madness742 2025-02-24 18:46:58 UTC

Created attachment 178834 [details]
3840x2160 monitor set to 2880x1620.

I'm not sure if this is related, but setting my secondary 4K monitor to 2880x1620 breaks half the screen and causes massive tearing/warping with moving windows and cursor. I've tried disabling/enabling Adaptive Sync on both monitors, but no changes.

Changing from DisplayPort to HDMI on this monitor will only cause a small portion of the center screen to be glitched.

I could not replicate this on Gnome 47 using the same setup, unlike the VRR bug in the first post.

Comment 2 Zamundaaa 2025-02-25 15:26:04 UTC

(In reply to madness742 from comment #0)
> I haven't been able to find a consistent way of reproducing this. Changing
> the Adaptive Sync option from 'Automatic' to 'Never' in these situations
> does not resolve the issue. The monitor will continue using 48Hz until I
> unplug and re-plug the monitor.
Then this is a driver bug, please report it at https://gitlab.freedesktop.org/drm/amd/-/issues

(In reply to madness742 from comment #1)
> I'm not sure if this is related, but setting my secondary 4K monitor to
> 2880x1620 breaks half the screen and causes massive tearing/warping with
> moving windows and cursor. I've tried disabling/enabling Adaptive Sync on
> both monitors, but no changes.
> 
> Changing from DisplayPort to HDMI on this monitor will only cause a small
> portion of the center screen to be glitched.
Also a driver bug, we don't do more than just tell it the mode and hope it does things correctly :/

> I could not replicate this on Gnome 47 using the same setup, unlike the VRR
> bug in the first post.
That doesn't mean a lot, Gnome doesn't use half the driver features we do. For example, afaik that Gnome release is still limited to 8 bits per color, which could cause the difference.

Comment 3 madness742 2025-02-26 04:08:34 UTC

(In reply to Zamundaaa from comment #2)
> (In reply to madness742 from comment #0)
> Then this is a driver bug, please report it at
> https://gitlab.freedesktop.org/drm/amd/-/issues
Thanks for pointing me to the right direction. I found a similar issue on their issue tracker which I'll keep my eyes on.

I also found that the following kernel parameter helps greatly with the VRR bug: `amdgpu.ppfeaturemask=0xfff07fff`. 

> (In reply to madness742 from comment #1)
> That doesn't mean a lot, Gnome doesn't use half the driver features we do.
> For example, afaik that Gnome release is still limited to 8 bits per color,
> which could cause the difference.
Ah, that explains the visual difference between DisplayPort and HDMI on KDE Plasma. That monitor only supports 10 bit with DisplayPort, and defaults to 8 bit when connected with HDMI.