Bugzilla – Bug 1169304
kwin_wayland: Windows are often invisible and unusable, triggers session crash
Last modified: 2020-04-14 14:29:39 UTC
When opening any new window (application, dialog, menu, etc) the window will often never appear and remains in an invisible state. Its process does however exist and is fully responsive. KWin seems to think it's there too, however Plasma doesn't show it in the task manager and alt-tab switching selects something non-existent... for example the drawing and selection order of windows completely breaks when an unrendered dialog is present. If attempting to switch desktops during this time, the session will crash and you're taken back to the login screen: Only way to "disarm" such crashes is to kill the process behind such a window (eg: from KSysGuard)... attempting to open the application again will usually work, though it may take several tries before the window will spawn properly. This issue renders the Plasma Wayland session next to unusable and requires constant user attention to work around hidden windows.
I tried several things which don't seem to prevent the problem: First was a suggestion to boot with the amdgpu.dc=0 parameter which did not affect the issue. I attempted different combinations under System Settings - Hardware - Display and Monitor - Compositor, the scale method / render backend (OpenGL 2.0 or 3.1) / vsync didn't affect it either. I also played with some parameters under the Compositing section of ~/.config/kwinrc but couldn't find proper documentation on what each one does and what in there might help.
Linux openSUSE Tumbleweed x64. Plasma 5.18.4. Mesa 20.0.4. Wayland 1.18 / 1.20. KWayland 5.68. AMD Radeon (TM) R9 390 Series (HAWAII, DRM 3.36.0, 5.6.2-1-default, LLVM 10.0.0). KWin theme is Aurorae, themes in use include:
Created attachment 835533 [details]
Does it also happen if you use Breeze as window decoration instead of Aurorae?
If yes, please run "LIBGL_ALWAYS_SOFTWARE=1 dbus-launch-session startplasmacompositor" in a tty and try to reproduce the issue there.
(In reply to Fabian Vogt from comment #2)
I switched to the default Breeze KWin theme followed by logging out and back in. No change, issue still occurred.
Attempting to start a test session with "LIBGL_ALWAYS_SOFTWARE=1 dbus-launch-session startplasmacompositor" wasn't possible as dbus-launch-session was reported as an unrecognized command when I looked at it. However I could solve this by adding "export LIBGL_ALWAYS_SOFTWARE=1" to ~/.profile then starting a new session normally: I can tell it worked since all desktop effects were disabled and the mouse cursor was extremely laggy (everything felt like it ran at 5 FPS). To my surprise even this didn't affect the issue, both the missing windows and session crash could still be reproduced after a number of attempts.
(In reply to Mircea Kitsune from comment #3)
> (In reply to Fabian Vogt from comment #2)
> I switched to the default Breeze KWin theme followed by logging out and back
> in. No change, issue still occurred.
Ok, so not that simple.
> Attempting to start a test session with "LIBGL_ALWAYS_SOFTWARE=1
> dbus-launch-session startplasmacompositor" wasn't possible as
> dbus-launch-session was reported as an unrecognized command when I looked at
Yeah, it's actually "dbus-run-session startplasma-wayland" now...
> However I could solve this by adding "export LIBGL_ALWAYS_SOFTWARE=1" to
> ~/.profile then starting a new session normally: I can tell it worked since
> all desktop effects were disabled and the mouse cursor was extremely laggy
> (everything felt like it ran at 5 FPS). To my surprise even this didn't
> affect the issue, both the missing windows and session crash could still be
> reproduced after a number of attempts.
Ok, so not an OpenGL HW issue.
Does this issue affect Wayland clients, X11 clients or both?
If it's the former, can you please run such an affected application with WAYLAND_DEBUG=1?
Does the journal include any helpful information at the time of the issues?
If you run "dbus-run-session startplasma-wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession" in a graphical session, can you reproduce the issue in that window? Note that this might mess up some plasmoid placement, so you might want to run this as a different user.
Created attachment 835729 [details]
dbus-run-session startplasma-wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession
(In reply to Fabian Vogt from comment #4)
Regarding whether this affects just Wayland or X11 clients: I don't know how to check which is which. However the issue does affect both Qt and GTK applications, KDE components or otherwise; So far I've seen it happen to KWrite, Konsole, KSysGuard, Firefox, Thunderbird, Audacious, etc. Since the first are default KDE components I'm assuming they're ran as native WL clients?
In a console I set "export WAYLAND_DEBUG=1" followed by repeatedly launching and closing "kwrite". When eventually it opened with a hidden window, nothing was printed to this console. I killed the process and it only said "Terminated".
I took a backup of ~/.config/plasma-org.kde.plasma.desktop-appletsrc to save my widget config, then successfully managed to use "dbus-run-session startplasma-wayland --xwayland --x11-display $DISPLAY --exit-with-session=/usr/lib64/libexec/startplasma-waylandsession" and start another session in a smaller window from within my normal session... I also set "export WAYLAND_DEBUG=1" in the console that spawned this debug session. I could reproduce the crash in this controlled environment too! Here's the output that was produced in the console running the nested session as that session collapsed.
Let's move this bug to the upstream bug tracker only - no need to duplicate everything.