SUMMARY I experience severe screen flickering (grey flashes) on a Framework 13 with AMD Ryzen AI 7 350 (Krackan Point) running Fedora 43 (KDE Plasma). The issue appears to be related to hardware overlays (MPO) failing during updates. STEPS TO REPRODUCE 1. Open Firefox. 2. Visit https://www.pdf24.org/en/ and hover over the "sheep" animation (or use any content triggering MPO/overlays). 3. Observe severe white/grey flickering of the screen. OBSERVED RESULT The screen flickers. The flickering STOPS immediately if another window (e.g., Konsole) is placed *on top* of the browser window (forcing composition instead of direct scanout). Attempts to set `widget.wayland.opaque-region.enabled` to `false` in Firefox resulted in a complete system freeze/hard lockup. EXPECTED RESULT No flickering during animations. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 43 KDE Plasma Version: 6.5.5 KDE Frameworks Version: (Standard for Fedora 43) Qt Version: (Standard for Fedora 43) HARDWARE Model: Framework Laptop 13 CPU/GPU: AMD Ryzen AI 300 Series (Radeon 860M / RDNA 3.5) Driver: amdgpu ADDITIONAL INFORMATION I found a workaround that completely fixes the issue: Exporting `KWIN_DRM_NO_AMS=1` fixes the flickering entirely. Kernel parameters like `amdgpu.dcdebugmask=0x10` (disabling PSR) did NOT solve the issue, suggesting the problem lies specifically in the Atomic Mode Setting / Overlay handling for this new GPU architecture.
Atomic modesetting and overlays are not the same feature; overlays are still off by default in release versions for all hardware. Please attach the output of - kscreen-doctor -o - drm_info - env | grep KWIN - sudo dmesg after reproducing the issue. Also, do you have the Firefox window in fullscreen, or windowed mode?
Created attachment 188738 [details] output of kscreen-doctor -o kscreen-doctor -o didn't output anything
Created attachment 188739 [details] output of sudo dmesg
Created attachment 188740 [details] output of drm_info
Thanks for the quick reply! I have reverted the workaround (unset KWIN_DRM_NO_AMS), reproduced the flickering with the animation on pdf24.org and collected the requested logs. Please find the 3 attached files. Env | grep KWIN returned nothing (empty output). Regarding your question: The issue happens in maximized window mode and in full-screen mode. It does not happened when the Firefox window is restored down. Also, I noticed that activating night light solves the issue too. Let me know if you need anything else.
(In reply to Mantas Vaitkus from comment #2) > Created attachment 188738 [details] > output of kscreen-doctor -o > > kscreen-doctor -o didn't output anything I'm sorry, the comment is wrong. kscreen-doctor -o did output something, it's one of the three attached files. What I wanted to say was that env | grep KWIN didn't output anything.
Okay, definitely direct scanout then. I can't reproduce any glitches on my (Ryzen 7840U) Framework 13, so I wonder what the difference is. I also wonder what the animation does to cause issues... Can you get the drm_info output while the glitches are happening? You can either run it delayed with "sleep 10; drm_info" or from another PC through ssh. Also, have you seen the glitches on any other websites or apps? If you make some simple test app like glxgears fullscreen, does that also trigger them?
Created attachment 188791 [details] drm_info output while screen is glitching
Hi, I'm not an expert so I use AI a lot to get the correct info for you. I'm sorry if something doesn't make sense at all, please let me know. I dug deeper into this and I believe I have identified the cause. It appears to be a hardware/driver issue related to aggressive VRAM Clock Switching, which is triggered when Direct Scanout is active (because the load drops effectively?). I monitored the VRAM frequency via hwmon while the flickering occurred. The logs show the memory clock oscillating rapidly and unstably (about 10 times per second) between low and medium states. It seems the GPU cannot decide on a power state for this specific workload. If I force the GPU power level to high, the flickering stops immediately and completely, even with Direct Scanout active. Command used: echo high | sudo tee /sys/class/drm/card1/device/power_dpm_force_performance_level Setting it back to auto brings the flickering back immediately. Why previous workarounds may have helped: KWIN_DRM_NO_AMS=1, Night Light, or obstructing the window likely disable Direct Scanout. This forces the GPU to do compositing, which seemingly adds enough consistent load to keep the memory clock stable (or prevents the specific power-saving state entry). Here is a snippet of the VRAM clock behavior during the flickering: 1:48:48.153 | VRAM Takt: 783 MHz 21:48:48.257 | VRAM Takt: 774 MHz 21:48:48.361 | VRAM Takt: 768 MHz 21:48:48.465 | VRAM Takt: 763 MHz 21:48:48.568 | VRAM Takt: 758 MHz 21:48:48.671 | VRAM Takt: 770 MHz 21:48:48.775 | VRAM Takt: 812 MHz 21:48:48.879 | VRAM Takt: 843 MHz 21:48:48.983 | VRAM Takt: 853 MHz 21:48:49.087 | VRAM Takt: 840 MHz 21:48:49.191 | VRAM Takt: 849 MHz 21:48:49.294 | VRAM Takt: 886 MHz 21:48:49.397 | VRAM Takt: 914 MHz 21:48:49.500 | VRAM Takt: 924 MHz 21:48:49.604 | VRAM Takt: 910 MHz 21:48:49.708 | VRAM Takt: 930 MHz 21:48:49.812 | VRAM Takt: 929 MHz 21:48:49.916 | VRAM Takt: 916 MHz 21:48:50.020 | VRAM Takt: 896 MHz 21:48:50.125 | VRAM Takt: 878 MHz 21:48:50.229 | VRAM Takt: 913 MHz 21:48:50.332 | VRAM Takt: 965 MHz 21:48:50.438 | VRAM Takt: 1010 MHz 21:48:50.541 | VRAM Takt: 1025 MHz 21:48:50.644 | VRAM Takt: 1017 MHz 21:48:50.748 | VRAM Takt: 1015 MHz 21:48:50.852 | VRAM Takt: 1005 MHz 21:48:50.957 | VRAM Takt: 986 MHz 21:48:51.062 | VRAM Takt: 982 MHz 21:48:51.168 | VRAM Takt: 955 MHz 21:48:51.272 | VRAM Takt: 953 MHz 21:48:51.377 | VRAM Takt: 924 MHz 21:48:51.483 | VRAM Takt: 904 MHz 21:48:51.588 | VRAM Takt: 883 MHz 21:48:51.693 | VRAM Takt: 860 MHz 21:48:51.798 | VRAM Takt: 854 MHz 21:48:51.902 | VRAM Takt: 841 MHz 21:48:52.008 | VRAM Takt: 824 MHz 21:48:52.114 | VRAM Takt: 810 MHz 21:48:52.219 | VRAM Takt: 797 MHz 21:48:52.324 | VRAM Takt: 785 MHz Since this seems to be a kernel/firmware behavior, do you think this should be forwarded to the amdgpu kernel tracker, or is there anything KWin can do to mitigate this "jittery" load?
(In reply to Zamundaaa from comment #7) > Okay, definitely direct scanout then. > > I can't reproduce any glitches on my (Ryzen 7840U) Framework 13, so I wonder > what the difference is. I also wonder what the animation does to cause > issues... > Can you get the drm_info output while the glitches are happening? You can > either run it delayed with "sleep 10; drm_info" or from another PC through > ssh. > > Also, have you seen the glitches on any other websites or apps? If you make > some simple test app like glxgears fullscreen, does that also trigger them? I forgot to answer your last questions. I've got those glitches on multiple sites, but way less pronounced. The youtube website does sometimes lead to a little grey flashing when hovering over a thumbnail and the preview starts playing. The pdf24 website is just perfect for reproducing the issue. It's so extreme, that my screen sometimes turns completely gray for over a second if I just leave the cursor on the image with the sheep. I tried running glxgears in fullscreen. It worked flawlessly, no glitching at all.
(In reply to Mantas Vaitkus from comment #9) > If I force the GPU power level to high, the flickering stops immediately and > completely, even with Direct Scanout active. > Command used: > echo high | sudo tee > /sys/class/drm/card1/device/power_dpm_force_performance_level > > Setting it back to auto brings the flickering back immediately. Yeah, definitely a driver bug then. You can report it at https://gitlab.freedesktop.org/drm/amd/-/issues