I've also observed much higher CPU usage with KWin while idle.

I can see VRR "breaking" when Steam is open, because it's almost constantly updating its window at the full refresh rate, but it works again once I close it or focus a different window that updates with at least 30Hz

Do you exhibit the CPU usage issue though? On my system, kwin_wayland's CPU usage increases by around 8% even after Steam is terminated. Restarting KWin helps.

I've just checked it with the Show Paint effect: before Steam has ever been opened during a session on an empty desktop everything is fine. After Steam has run at least once, the effect constantly triggers, even on the secondary screen.

Running Steam in gamescope seems to mitigate this problem.

Oh, alright, suspecting that it might be relevant, I unloaded the nvidia driver and removed the card from the PCI tree on my PC, everything is 100% fine now.

I do wonder what Steam is doing with nvidia that is causing this though. Regular PRIME offloading does not trigger this, only Steam seems to do so.

Sorry for the trouble!

One final note though, to whom it may concern: on AMD/NVIDIA systems launching Steam has to be done like so:

VK_DRIVER_FILES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json steam

This also works.

Ah, unfortunately not - I still had the nvidia driver unloaded. The Vulkan driver choice doesn't seem to matter.

I reported the issue to the Steam issue tracker too: https://github.com/ValveSoftware/steam-for-linux/issues/10847

After further testing, this can also happen when any "custom-border"/"custom-window" Xwayland app (such as FL Studio via Wine, Steam, game/mod launchers via Wine, etc.) is launched.

This in turn forces full refresh rate whole-screen on all screens (unless VRR requirements are met, see below). These full repaints are easy to visualize with the Show Paint desktop effect in KWin.

I've also tried removing the nvidia driver again, this time to no avail - FL Studio manages to trigger this behavior even on a single GPU (AMD) setup, so thankfully it seems like it's not an NVIDIA bug after all. (The Steam window itself for some reason manages to work fine on just AMD, but everything falls apart if I launch a game with "custom" windows, like OMSI 2.)

However, this is probably intended behavior anyway (the minimum refresh rate requirement for VRR is not enforced prior to launching these apps, see https://bugs.kde.org/show_bug.cgi?id=483240, starting one of them "makes it work"). I'll just stick to nested compositing, the Wine Wayland driver and gamescope wherever I can - I'd like to retain full kernel LFC if possible.

The only real issue with these repaints is the relatively "high" CPU usage they cause (compared to when they aren't present).

I've found a reliable reproducer: Yume Nikki on Steam (free). After running the game, the fullscreen repaints are forced on all screens.

This bug can be also triggered via launching "Yume Nikki" (free game) from Steam.

I am experiencing the same issues without running , just running apps that are not wayland native. The apps i have identified so far are :

* All IntelliJ related products (unless i chose JDK-23 and enable experimental wayland support - the app is no longer listed in xlsclients then, and the problem is not present)
* Smath (a mathcad-like application using mono)

I suspect that probably every app that is listed when i run the "xlsclients" command causes this problem

Like i mentioned before running these apps causes sudden slowdown of the entire desktop after some time (like a minute or two). Closing these apps does not resolve the issue. The kwin_wayland process takes around 15% of CPU time, even when showing only wallpaper, but the UI slows down considerably more than these 15% in my opinion.

When i enable the "Show FPS" desktop effect (i do not know why "show paint" effect does not work for me) the "Paint amount" rises to constant 100% and does not go down even if i close every window. 

Issuing "kwin_wayland --replace" solves the issue but also restarts every other application.

I fotgot to add that i am working on hybrid intel/nvidia graphics card but i have the nvidia device removed in udev rules (it was causing suspend/resume problems for me) so it is behaving like only the intel card is present (core i7 11gen)

Changing the window open/close animation to another mode/disabling and re-enabling it (or, to be safe, disabling and re-enabling all desktop effects one by one) seems to fix this issue entirely.

I can confirm that when the issue is present and i changed the window open/close animaton to "Fade" the problem immiediately went away (i could also confirm this on the paint amount graph via the "show fps" desktop effect). So there is a way to get rid of it other than restartin kwin_wayland.
What is more - since i changed the window open/close animation i havent been able to reintroduce the problem in the same kwin session so far...

Does switching back to the Glide effect bring the issue back for you? For me it does; I have to use Scale.

As for me, changing the desktop effect back to glide does not re-enable the problem, at least not immiediately. But for now i have not been able to experience the issue when the window open/close animation is set to "Fade" - this does not mean it will not happen, it may be a pure quicidence.
But i can confirm that changing the animation does fix the issue, it have used this method multiple time s when testing.
I will post my findings here if the effect also occurs when using other animations.