SUMMARY Automatic VRR and Tearing stop working once a WINE window is displayed. STEPS TO REPRODUCE 1. Enable Automatic VRR or Tearing in systemsettings6 2. Open a Steam game (Proton) or WINE application 3. Observe immediate effects of auto VRR and Tearing failing. OBSERVED RESULT The refresh rate of both VRR compatible monitors locks to the highest possible value (70 Hz, 165 Hz) even though VRR is still enabled in systemsettings6. Non-automatic VRR is not affected by this. Tearing stops working immediately on all monitors even though Tearing is still enabled in systemsettings6. This only fixes itself once the session is reloaded. EXPECTED RESULT Both automatic VRR and Tearing continue to work as expected. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20231215 / (openSuSE Tumbleweed + Krypton repos) KDE Plasma Version: 5.90.90 KDE Frameworks Version: 5.247.0 Qt Version: 6.6.1 Kernel Version: 6.6.6-1-default (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 15,5 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Mesa version is 23.2.1-1699.364.pm.3 XWayland version is 23.2.2-3.1 ADDITIONAL INFORMATION KWIN_DRM_NO_AMS=1 was set in /etc/environment MESA_VK_WSI_PRESENT_MODE=immediate was set in local shell
Please check if there's any weird X11 windows from Wine on your system. You can do that in the kwin debug console, which you can open with krunner.
(In reply to Zamundaaa from comment #1) > Please check if there's any weird X11 windows from Wine on your system. You > can do that in the kwin debug console, which you can open with krunner. Nope, nothing. The issue also persists after all WINE processes have closed. I should probably mention that this wasn't the case on the same system with Plasma 5. On Plasma 5 both automatic VRR and Tearing have worked flawlessly both with WINE and native software.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
(In reply to Connor Jenzsch from comment #2) > (In reply to Zamundaaa from comment #1) > > Please check if there's any weird X11 windows from Wine on your system. You > > can do that in the kwin debug console, which you can open with krunner. > > Nope, nothing. > > The issue also persists after all WINE processes have closed. > > I should probably mention that this wasn't the case on the same system with > Plasma 5. On Plasma 5 both automatic VRR and Tearing have worked flawlessly > both with WINE and native software. Status updated to REPORTED. Forgot to do it earlier, sorry!
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4860
Git commit 7f9cbbaa98c4cd633319e45e9a1100ea58f12840 by Xaver Hugl. Committed on 09/01/2024 at 18:06. Pushed by zamundaaa into branch 'master'. core/renderloop: improve frame scheduling heuristics with VRR Instead of checking for fullscreen windows and deciding whether or not to schedule repaints based on that, check if the active window is refreshing fast enough to be reasonable for vrr. For automatic mode, vrr is also enabled with the active window instead of the direct scanout candidate. Related: bug 477199 M +9 -6 src/compositor.cpp M +1 -0 src/core/output.h M +10 -6 src/core/renderloop.cpp M +1 -6 src/core/renderloop.h M +2 -1 src/core/renderloop_p.h M +21 -0 src/scene/surfaceitem.cpp M +7 -0 src/scene/surfaceitem.h https://invent.kde.org/plasma/kwin/-/commit/7f9cbbaa98c4cd633319e45e9a1100ea58f12840
(In reply to Zamundaaa from comment #6) > Git commit 7f9cbbaa98c4cd633319e45e9a1100ea58f12840 by Xaver Hugl. > Committed on 09/01/2024 at 18:06. > Pushed by zamundaaa into branch 'master'. > > core/renderloop: improve frame scheduling heuristics with VRR > > Instead of checking for fullscreen windows and deciding whether or not to > schedule repaints > based on that, check if the active window is refreshing fast enough to be > reasonable for vrr. > For automatic mode, vrr is also enabled with the active window instead of > the direct scanout > candidate. > Related: bug 477199 > > M +9 -6 src/compositor.cpp > M +1 -0 src/core/output.h > M +10 -6 src/core/renderloop.cpp > M +1 -6 src/core/renderloop.h > M +2 -1 src/core/renderloop_p.h > M +21 -0 src/scene/surfaceitem.cpp > M +7 -0 src/scene/surfaceitem.h > > https://invent.kde.org/plasma/kwin/-/commit/ > 7f9cbbaa98c4cd633319e45e9a1100ea58f12840 Awesome! Will definitely check that out shortly.
(In reply to Zamundaaa from comment #6) > Git commit 7f9cbbaa98c4cd633319e45e9a1100ea58f12840 by Xaver Hugl. > Committed on 09/01/2024 at 18:06. > Pushed by zamundaaa into branch 'master'. > > core/renderloop: improve frame scheduling heuristics with VRR > > Instead of checking for fullscreen windows and deciding whether or not to > schedule repaints > based on that, check if the active window is refreshing fast enough to be > reasonable for vrr. > For automatic mode, vrr is also enabled with the active window instead of > the direct scanout > candidate. > Related: bug 477199 > > M +9 -6 src/compositor.cpp > M +1 -0 src/core/output.h > M +10 -6 src/core/renderloop.cpp > M +1 -6 src/core/renderloop.h > M +2 -1 src/core/renderloop_p.h > M +21 -0 src/scene/surfaceitem.cpp > M +7 -0 src/scene/surfaceitem.h > > https://invent.kde.org/plasma/kwin/-/commit/ > 7f9cbbaa98c4cd633319e45e9a1100ea58f12840 Can confirm, this fixes the issue.