SUMMARY Connecting or disconnecting an external monitor very often disables compositing. It doesn't seem to happen 100% of the time, so it seems like some kind of a race condition. When it happens KWin displays a message: "Desktop effects have been suspended by another application. You can resume using the 'Alt+Shift+F12' shortcut.'". I thought that maybe it's Firefox, but no, it happens even when there are no applications open at all, just an empty desktop. STEPS TO REPRODUCE 1. Run KWin with compositing enabled. 2. Connect an external monitor. OBSERVED RESULT Compositing is disabled and KWin shows a notification as described above. EXPECTED RESULT Compositing continues to work. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.17.90 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.1 Kernel Version: 5.5.1-arch1-1 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz Memory: 7.6 GiB of RAM ADDITIONAL INFORMATION This bug is not new to 5.17.90, it's the same in earlier versions, at least in 5.17. My external monitor is connected to HDMI port in my laptop via HDMI to VGA adapter if that matters.
So I got curious and started debugging this. Adding those 2 lines: qCDebug(KWIN_OPENGL) << "viewport-limit-width:" << limit[0] << "\tviewport-limit-height:" << limit[1]; qCDebug(KWIN_OPENGL) << "size-width:" << size.width() << "\tsize-height:" << size.height(); in function SceneOpenGL::viewportLimitsMatched right after this call: glGetIntegerv(GL_MAX_VIEWPORT_DIMS, limit); somehow eliminated the race condition and I could no longer reproduce the issue. However the debug output sometimes showed expected values: kwin_scene_opengl: viewport-limit-width: 32768 viewport-limit-height: 32768 and other times something odd: kwin_scene_opengl: viewport-limit-width: 1023711040 viewport-limit-height: 21890 Anyway, it stopped triggering the if condition: if (limit[0] < size.width() || limit[1] < size.height()) When I moved those debug statements inside the if block, the problem returned. Here is the output of the debug statements: kwin_scene_opengl: viewport-limit-width: -40918160 viewport-limit-height: 22066 kwin_scene_opengl: size-width: 3840 size-height: 1080 So it seems that glGetIntegerv(GL_MAX_VIEWPORT_DIMS, limit) sometimes fails for some reason, leaving garbage values. I'm not an OpenGL expert so I have no idea why it would fail. Given that this viewport limit check is not executed at all in Wayland, is it really needed?
Created attachment 126330 [details] backtrace when glGetIntegerv(GL_MAX_VIEWPORT_DIMS, limit) fails
Created attachment 126331 [details] backtrace when glGetIntegerv(GL_MAX_VIEWPORT_DIMS, limit) succeeds
still have this problem
I can't reproduce this bug using kwinft/disman/kdisplay.
It happens here too.
I was hoping that reworked compositing in the upcoming kwin will fix this issue, so I gave kwin 5.20.90 a try - still the same, unfortunately.
(In reply to Mariusz Libera from comment #5) > I can't reproduce this bug using kwinft/disman/kdisplay. I don't see any significant changes in the relevant codepaths in kwinft (other than the renames of stuff), how consistent is it with "normal" kwin? But if its a race condition it might be because of the slowdowns with kwinft, I guess?
Created attachment 135193 [details] Just testing Gave up trying to diff with kwinft, it's missing too many changes. But could you test this patch? It should show what the issue is at least. But looking at the stack traces it seems to fail when it is called directly, and succeeds when going via a timer. So I assume there's some bug in some driver that makes it necessary to delay the query for some arbitrary amount of time (to fix it "properly").
Created attachment 135194 [details] patch ish Can't get kwin to build (it apparently depends on -git versions of pretty much everything), so I can't test this patch myself, but just to show what I'm thinking
(In reply to Martin Sandsmark from comment #9) > Created attachment 135193 [details] > Just testing > > Gave up trying to diff with kwinft, it's missing too many changes. > > But could you test this patch? It should show what the issue is at least. > > But looking at the stack traces it seems to fail when it is called directly, > and succeeds when going via a timer. So I assume there's some bug in some > driver that makes it necessary to delay the query for some arbitrary amount > of time (to fix it "properly"). I've tested this patch and at first it seemed to work - I couldn't reproduce the issue, but when I gave it another run with with QT_LOGGING_RULES="kwin_*.debug=true" - strangely, the issue returned.
(In reply to Martin Sandsmark from comment #10) > Created attachment 135194 [details] > patch ish > > Can't get kwin to build (it apparently depends on -git versions of pretty > much everything), so I can't test this patch myself, but just to show what > I'm thinking This one works - can't reproduce the issue anymore. However it produces a small visual glitch - windows textures get stretched and then shrunk back when disconnecting the monitor.
5.21 kwin changes exacerbated this issue. Getting the same issue since 5.21 dropped on Arch with an AMD Ryzen RX580 desktop system, but with my primary monitor and not an external secondary monitor. This happens when I turn my only desktop monitor off and on, which I do to save power when I leave long running tasks unattended, which multiple times daily. Kwin_X11 --replace& only way to restore compositing, ALT+SHIFT+F12 doesn't work. Issue with primary monitor didn't occur for me with 5.20, so the wider breadth of this issue is a 5.21 regression too. A few observations : If I disable the Blur Desktop Effect the issue goes away. If I enable the Blur Desktop Effect the issue returns. If I enable the Background Contrast Desktop effect the issue goes away, even if Blur is enabled. Some internet search results recommended enabling Background Contrast Desktop Effect as a temp fix to this issue. Ideally Blur should work in the situation without Background Contrast, but currently it doesn't.
Created attachment 136147 [details] potential fix I wonder if it's related to opengl context. Does the attached patch fix the issue?
Created attachment 136150 [details] patch Also, it will be great if somebody could apply this patch and check if kwin successfully queries GL_MAX_VIEWPORT_DIMS.
(In reply to Vlad Zahorodnii from comment #14) > Created attachment 136147 [details] > potential fix > > I wonder if it's related to opengl context. Does the attached patch fix the > issue? No, it doesn't.
(In reply to Vlad Zahorodnii from comment #15) > Created attachment 136150 [details] > patch > > Also, it will be great if somebody could apply this patch and check if kwin > successfully queries GL_MAX_VIEWPORT_DIMS. "Failed to query GL_MAX_VIEWPORT_DIMS" is not printed out, only "Suspending compositing because viewport limits are not met".
I can't reproduce it with 5.22.90, seems to be fixed.
Kwin in plasma 5.23 definitely fixed this.