Bug 426069 - XWayland apps are occasionally not rendered when switching virtual desktops
Summary: XWayland apps are occasionally not rendered when switching virtual desktops
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: git master
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-01 16:31 UTC by Thiago Sueto
Modified: 2021-10-04 18:34 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.23


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thiago Sueto 2020-09-01 16:31:16 UTC
SUMMARY
Not entirely sure whether this is the correct product, please send it to the correct one if it's not kwin.
I've been affected by this bug for a few months at least.
I usually have 4 or 6 virtual desktops (VDs) at any given time. Usually I have several XWayland apps running maximized, be they Electron (Slack) or not (Telegram), normal packages (Kontact) or from Flatpak (WPS Office). On occasion, switching to another VD renders the app invisible.

In such a state, opening any application and moving it on top of the invisible one creates a graphical glitch.

This issue most notably occurs with WPS Office, Kontact and Chromium, and never with wayland telegram or Kate, which leads me to think it's related to XWayland.

It takes a while to reproduce, but it is reproduced consistently. By this I mean that it is not reproducible every single time you switch a VD, but if you test it enough you will inevitably reproduce this issue (just be patient).

It is also not related to the number of cycles, as it may appear after 5 cycles or 20 cycles.

I am not sure whether clicking a task icon reproduces this as it takes much more time to reproduce. Same with Meta+number keyboard shortcuts. I'll test this later.

STEPS TO REPRODUCE
1. Create three virtual desktops in a wayland session, easiest to reproduce with them in line
2. Have one maximized application in each of them, at least one running on XWayland
3. Cycle between them using a keyboard shortcut

OBSERVED RESULT
Application is not rendered

EXPECTED RESULT
Application should appear as normal

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20200823
KDE Plasma Version: 5.19.80
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.0
Comment 1 Thiago Sueto 2020-09-01 16:49:24 UTC
Forgot to mention: despite not seeing anything, I can still manipulate the window by dragging it by its titlebar.

Additionally, I managed to get lucky just now and reproduced it by Meta+number.
Comment 2 Thiago Sueto 2020-09-01 16:50:35 UTC
Similarly to https://bugs.kde.org/show_bug.cgi?id=426071 , any attempts to change its window state (maximize, restore etc) shows the respective visual effects, but does not nulify this issue. Except for one: if I minimize it and restore it, the issue is gone.
Comment 3 Vlad Zahorodnii 2021-10-04 05:56:46 UTC
Git commit 8ac93a59ffb1a09bf6df46c7012bea7910e6b883 by Vlad Zahorodnii.
Committed on 04/10/2021 at 05:56.
Pushed by vladz into branch 'master'.

scene: Handle Xwayland windows changing surfaces

Xwayland can re-create the wl_surface if the window has been previously
unmapped.
Related: bug 442936

M  +23   -19   src/windowitem.cpp

https://invent.kde.org/plasma/kwin/commit/8ac93a59ffb1a09bf6df46c7012bea7910e6b883
Comment 4 Vlad Zahorodnii 2021-10-04 05:56:54 UTC
Git commit 52c9dbb487f4ac98017b83a1deee912546cbff5f by Vlad Zahorodnii.
Committed on 04/10/2021 at 05:56.
Pushed by vladz into branch 'master'.

wayland: Reset Toplevel::surfaceId after surface is created

Xwayland will re-create the wl_surface object if the X11 window is
unmapped and mapped. That, and the fact that the order in which the
WL_SURFACE_ID client message event is received and the wl_surface object
is created is undefined can cause the following bug:

* WL_SURFACE_ID is received
* the old wl_surface object is destroyed, m_surfaceId is reset to 0
* new wl_surface is created but because m_surfaceId is 0, it won't be
  associated with the x11 window

This change ensures that kwin will associate the wl_surface with x11
window by making it not reset cached surface id when the old wl_surface
is destroyed.

However, we cannot leave m_surfaceId as is because wayland aggressively
re-uses object ids so kwin can associate wrong surface with x11 window.

To prevent that, this change also makes Toplevel::setSurface() reset
cached surface id.
Related: bug 442936

M  +2    -3    src/events.cpp
M  +1    -2    src/toplevel.cpp
M  +4    -15   src/toplevel.h
M  +2    -2    src/wayland_server.cpp

https://invent.kde.org/plasma/kwin/commit/52c9dbb487f4ac98017b83a1deee912546cbff5f
Comment 5 Vlad Zahorodnii 2021-10-04 05:57:43 UTC
Git commit a75559c39081c80c7e31e9c7324b17e7a4efb3f1 by Vlad Zahorodnii.
Committed on 04/10/2021 at 05:57.
Pushed by vladz into branch 'Plasma/5.23'.

wayland: Reset Toplevel::surfaceId after surface is created

Xwayland will re-create the wl_surface object if the X11 window is
unmapped and mapped. That, and the fact that the order in which the
WL_SURFACE_ID client message event is received and the wl_surface object
is created is undefined can cause the following bug:

* WL_SURFACE_ID is received
* the old wl_surface object is destroyed, m_surfaceId is reset to 0
* new wl_surface is created but because m_surfaceId is 0, it won't be
  associated with the x11 window

This change ensures that kwin will associate the wl_surface with x11
window by making it not reset cached surface id when the old wl_surface
is destroyed.

However, we cannot leave m_surfaceId as is because wayland aggressively
re-uses object ids so kwin can associate wrong surface with x11 window.

To prevent that, this change also makes Toplevel::setSurface() reset
cached surface id.
Related: bug 442936


(cherry picked from commit 52c9dbb487f4ac98017b83a1deee912546cbff5f)

M  +2    -3    src/events.cpp
M  +1    -2    src/toplevel.cpp
M  +4    -15   src/toplevel.h
M  +2    -2    src/wayland_server.cpp

https://invent.kde.org/plasma/kwin/commit/a75559c39081c80c7e31e9c7324b17e7a4efb3f1
Comment 6 Vlad Zahorodnii 2021-10-04 05:58:20 UTC
Git commit 626b5b4c0d30b0bd040f8fc1da582a6c782cf5a9 by Vlad Zahorodnii.
Committed on 04/10/2021 at 05:58.
Pushed by vladz into branch 'Plasma/5.23'.

scene: Handle Xwayland windows changing surfaces

Xwayland can re-create the wl_surface if the window has been previously
unmapped.
Related: bug 442936


(cherry picked from commit 8ac93a59ffb1a09bf6df46c7012bea7910e6b883)

M  +23   -19   src/windowitem.cpp

https://invent.kde.org/plasma/kwin/commit/626b5b4c0d30b0bd040f8fc1da582a6c782cf5a9