Occasionally, I can see compositing being restarted at random actions, like opening or closing application windows. This can be seen as flickering semi-transparent panels on the desktop, as if the "Background contrast" effect has been disabled and re-enabled. One time kwin hung while doing this and stuck in an infinite loop, desktop unresponsive. I saved a few backtraces while it was hanging. They were the same, so I attached only one. strace only shows "clock_gettime(CLOCK_MONOTONIC, {90155, 71576276}) = 0" call in a loop (the numbers change). Reproducible: Sometimes Steps to Reproduce: I don't know a reliable way to reproduce this. Kubuntu 16.04, x86_64. Nvidia driver 367.18. The restarts also happened with 364.19. OpenGL interface: GLX, rendering backend: OpenGL 3.1. Desktop theme: Breeze, window decorations: org.kde.oxygen.
Created attachment 99173 [details] A backtrace of the looping kwin
> #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 > #1 0x00007fee99f20e85 in ?? () from /usr/lib/nvidia-367/libGLX_nvidia.so.0 > #2 0x00007fee99f20b83 in ?? () from /usr/lib/nvidia-367/libGLX_nvidia.so.0 > #3 0x00007fee933dd72b in ?? () from /usr/lib/nvidia-367/libnvidia-glcore.so.367.18 > #4 0x00007fee932da5f1 in ?? () from /usr/lib/nvidia-367/libnvidia-glcore.so.367.18 > #5 0x00007fee92f71b54 in ?? () from /usr/lib/nvidia-367/libnvidia-glcore.so.367.18 > #6 0x00007feeb35ddca3 in KWin::checkGLError (txt=txt@entry=0x7feeb972d35f "Init") at /build/kwin-2AFxJo/kwin-5.5.5/libkwineffects/kwinglutils.cpp:205 > #7 0x00007feeb966ee9d in KWin::SceneOpenGL2::SceneOpenGL2 (this=0x2ee3f40, backend=<optimized out>, parent=<optimized out>) at /build/kwin-2AFxJo/kwin-5.5.5/scene_opengl.cpp:1031 > #8 0x00007feeb966f32a in KWin::SceneOpenGL::createScene (parent=parent@entry=0x11a3fb0) at /build/kwin-2AFxJo/kwin-5.5.5/scene_opengl.cpp:588 It's hanging in the nvidia driver on obtaining GL errors. I'd suggest trying a stable driver (367.18 is a beta version) to see whether the same issues occur there as well. Oc, it would be good to see the initial error which caused the restart (start "kwin_x11 --replace &" from konsole and trigger it), maybe dmesg holds valuable information (cc., ensure there's no NVRM warning about using unsupported framebuffer consoles) If kwin restarts *completely* (to recover from a crash), please ensure to have drkonqi installed and provide the segfault/abort backtrace ("developer information" tab)
> I'd suggest trying a stable driver (367.18 is a beta version) to see whether the same issues occur there as well. 364.19 is the stable one, it happened with it too. I updated trying if the new version fixed anything. > maybe dmesg holds valuable information (cc., ensure there's no NVRM warning about using unsupported framebuffer consoles) dmesg has this warning: [ 4.137728] NVRM: Your system is not currently configured to drive a VGA console [ 4.137730] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver [ 4.137731] NVRM: requires the use of a text-mode VGA console. Use of other console [ 4.137732] NVRM: drivers including, but not limited to, vesafb, may result in [ 4.137732] NVRM: corruption and stability problems, and is not supported. I'm not sure how to fix this. I didn't configure any console drivers. > If kwin restarts *completely* (to recover from a crash), please ensure to have drkonqi installed and provide the segfault/abort backtrace ("developer information" tab) The KDE crash handler doesn't start when this happens; I don't think kwin process crashes. > it would be good to see the initial error which caused the restart (start "kwin_x11 --replace &" from konsole and trigger it) Ok, I will try this. But since I don't have a repro, this may take a while.
https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Disable_framebuffer Ubuntu should be using /etc/default/grub as well ( just they've no useful documentations ;-P )
(In reply to Thomas Lübking from comment #4) > https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Disable_framebuffer > > Ubuntu should be using /etc/default/grub as well ( just they've no useful > documentations ;-P ) Thanks. I got rid of the warning now.
The issue may remain, just nvidia won't fix anything that occurs on unsupported setups (and it's indeed trouble prone) Did you have those restarts on the stable driver as well?
> Did you have those restarts on the stable driver as well? Yes, the panels did reset* on 364.19 too, but kwin did not hang. The hang only happened once, on 367.18, but I haven't been using it for long (I updated the driver yesterday and reverted back to 364.19 now). * By 'reset' I mean I can see their opacity change suddenly. Either they temporarily become opaque or very transparent, as if the Contrast effect is disabled. Shortly after they restore their normal display.
(In reply to Lastique from comment #7) > * By 'reset' I mean I can see their opacity change suddenly. Either they > temporarily become opaque or very transparent, as if the Contrast effect is > disabled. Shortly after they restore their normal display. At least for "very transparent" the compositor isn't "reset" (in terms of temporarily disabled) for sure. If only the panels are affects, it's *very* likely indeed the contrast effect (protocol) which probably is just a pointless, clumsy and wonky way to waste resources anyway https://bugs.kde.org/show_bug.cgi?id=337355#c8 and apparently nobody knows why it's done this way https://bugs.kde.org/show_bug.cgi?id=337355#c12 and https://bugs.kde.org/show_bug.cgi?id=337355#c14 I'd suggest to simply disable it. *shrug*
(In reply to Thomas Lübking from comment #8) > > I'd suggest to simply disable it. *shrug* I would but without it the panels are nearly unusable with a dark desktop background. Fonts are barely readable because the panel is too dark.
(In reply to Lastique from comment #9) > I would but without it the panels are nearly unusable with a dark desktop > background. Fonts are barely readable because the panel is too dark. Let me guess: disabling the blur effect will "fix" this (by selecting the more opaque plasma panel theme)?
Created attachment 99182 [details] An example of a panel without contrast effect I've attached a screenshot without the contrast effect. Curiously, I got used to this effect fixing the panels so much that I didn't disable it for years. Now, when I tried to disable it and surprisingly, after a few seconds the panels "fixed" themselves, as if the effect have been re-enabled. The effect is clearly disabled in the settings but the panels look as if it's on. This happens every time when I disable the effect - the panels go dark for a second or two and then back to light again. Is it possible that the effect is somehow force-enabled somewhere?
(In reply to Thomas Lübking from comment #10) > > Let me guess: disabling the blur effect will "fix" this (by selecting the > more opaque plasma panel theme)? Nope, the behavior is the same as I described in the #11. Except, well, the desktop background is not blurred behind panels.
(In reply to Lastique from comment #11) > Is it possible that the effect is somehow force-enabled somewhere? No. Explanation: There *was* a bug in that the übertransparent plasma theme was bound to the blur effect instead of the contrast effect (and I thought they might have re-introduced it) What you see (now) is what is expected, the contrast effect is unregistered and plasma loads the "more solid" theme in return. That you mistake it for the contrast effect bein re-enabled is because of https://bugs.kde.org/show_bug.cgi?id=337355#c8 - thanks for confirmation from an innocent user ;-) Does the panel opacity change still happen? (The hanging GL call might be a rather unrelated issue - notably if not reproducible.)
(In reply to Thomas Lübking from comment #13) > No. Explanation: Thanks for the explanation, makes sense. I thought I was going crazy. :) > Does the panel opacity change still happen? I didn't manage to reproduce the "very transparent panels" case since I started to collect the log. But I can still see the panels becoming more opaque at times. This is typically easier to reproduce right after a reboot. For example, on a freshly booted system I start QtCreator 4.0.0 and can see the lower panel blinking to more opaque and back twice as QtCreator starts. Another case is clicking on the Networks icon in the system tray (the panel blinks once). Another case is opening System Settings -> Desktop Behavior -> Desktop Effects (the panel blinks once). Performing the same actions the second time does not cause panel blinks, at least not if done soon after the first time. I saved the kwin output while I was experimenting (attached). I did not notice any particular messages appearing when the panel blinks. I can add that the glowing effect/shadow around the window decorations are not affected when the above blinks happen. These effects are not shown when compositing is disabled, so the problem is indeed not caused by compositing restart. > (The hanging GL call might be a rather unrelated issue - notably if not > reproducible.) No hangs on 364.19 so far. Although I haven't reproduced the "very transparent panels" either, which is when kwin hung.
Created attachment 99191 [details] KWin log
"kcmshell5 kwineffects", filter for "blur", configure the effect and disable the blur cache (only checkbox) Still reproducible?
(In reply to Thomas Lübking from comment #16) > "kcmshell5 kwineffects", filter for "blur", configure the effect and disable > the blur cache (only checkbox) > Still reproducible? That option is already disabled.
Meh - blur (next to contrast) is by it's nature still a major contender to be the culprit. => If you can reproduce it with disabled blur, it might be helpful to see a video of what's actually going one.
(In reply to Thomas Lübking from comment #18) > Meh - blur (next to contrast) is by it's nature still a major contender to > be the culprit. > => If you can reproduce it with disabled blur, it might be helpful to see a > video of what's actually going one. I tried disabling blur and indeed opacity changes have disappeared.
(In reply to Lastique from comment #19) > > I tried disabling blur and indeed opacity changes have disappeared. And there you go. A few minutes later after I wrote the message I re-enabled the Blur effect and got un-drawn window decorations. No flickering though. Also I noticed that the decorations are affected by the nearby windows. See the screencast.
Created attachment 99313 [details] Screencast showing undrawn decorations
Created attachment 99316 [details] Screencast showing opacity changes when opening windows Sorry, I mixed up two of by bugs. Here's a screencast of opacity changes when blur is enabled. Pay attention to the panels.
*** This bug has been marked as a duplicate of bug 432570 ***