SUMMARY Playing a game or video in full screen on a monitor can break video output on another monitor, the screen stops refreshing until I un-fullscreen the other app. This happens across browsers and games, but notably doesn't happen if I use 2 Firefox windows on different screens. Firefox should be running native Wayland but I am not sure the others involved are native Wayland. STEPS TO REPRODUCE (Other situations cause, but this is reliable) 1. Play video in firefox on screen 2 (Used youtube) 2. Play video in chrome on screen 3 (Used youtube) 3. Maximize Chrome's video. OBSERVED RESULT Firefox's video freezes (and sometimes becomes unresponsive to input) but the audio continues. EXPECTED RESULT Both videos continue playing. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch/RC1/updated system to be safe. (available in About System) KDE Plasma Version: 5.92.0 KDE Frameworks Version: 5.248.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION This has also been observed with chrome video on screen 3 and a game fullscreen on screen 2, both xWayland I believe
Did you enable adaptive sync?
or does your monitor support it?
Yes, all monitors are identical for me (I have 3) and the main in the middle is set to automatic adaptive sync
Does the problem go away if you disable adaptive sync? If that's the case then I know what's causing this
It seems to go away if I set adaptive sync to never!
Any relation to Bug 479946?
*** Bug 479946 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5038
Git commit bbc833baa64f233fa07c3b4b6e7d1eb69e9ceb29 by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 25/01/2024 at 09:29. Pushed by vladz into branch 'master'. core/renderloop: take the output of the active window into account for vrr scheduling If the active window is on a different output than the one the renderloop is for, the scheduling logic would otherwise never schedule a repaint while adaptive sync is active. M +1 -1 src/backends/drm/drm_abstract_output.cpp M +1 -1 src/backends/virtual/virtual_output.cpp M +1 -1 src/backends/wayland/wayland_output.cpp M +1 -1 src/backends/x11/standalone/x11_standalone_backend.cpp M +1 -1 src/backends/x11/windowed/x11_windowed_output.cpp M +6 -5 src/core/renderloop.cpp M +2 -1 src/core/renderloop.h M +3 -2 src/core/renderloop_p.h M +1 -1 src/placeholderoutput.cpp https://invent.kde.org/plasma/kwin/-/commit/bbc833baa64f233fa07c3b4b6e7d1eb69e9ceb29
Git commit 063d0ab81ae0e1b19f05bb6a4765ac20f9e75bfc by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 25/01/2024 at 09:56. Pushed by vladz into branch 'Plasma/6.0'. core/renderloop: take the output of the active window into account for vrr scheduling If the active window is on a different output than the one the renderloop is for, the scheduling logic would otherwise never schedule a repaint while adaptive sync is active. (cherry picked from commit bbc833baa64f233fa07c3b4b6e7d1eb69e9ceb29) M +1 -1 src/backends/drm/drm_abstract_output.cpp M +1 -1 src/backends/virtual/virtual_output.cpp M +1 -1 src/backends/wayland/wayland_output.cpp M +1 -1 src/backends/x11/standalone/x11_standalone_backend.cpp M +1 -1 src/backends/x11/windowed/x11_windowed_output.cpp M +6 -5 src/core/renderloop.cpp M +2 -1 src/core/renderloop.h M +3 -2 src/core/renderloop_p.h M +1 -1 src/placeholderoutput.cpp https://invent.kde.org/plasma/kwin/-/commit/063d0ab81ae0e1b19f05bb6a4765ac20f9e75bfc
*** Bug 480484 has been marked as a duplicate of this bug. ***