Bug 444962

With KDE 5.23.3 instead of opening up in the corner, wayland only games are completely invisible.

Here is a recording of the problem with the yamagi quake 2 flatpak with wayland socket enabled: https://youtu.be/dwFMap8-r1E

With Xonotic, it trashes my game config so I have to restore from a backup after disabling wayland socket.

I can confirm that Flatpak Xonotic ends up invisible on Wayland. I tried the version in the Arch repos as well for good measure, in that case setting the `SDL_VIDEODRIVER=wayland` environment variable gives the same result. In both cases making Xonotic fall back to X11 makes it work fine. Also, the window thumbnail preview from the taskbar just shows a square with a light blue background for me.

Operating System: Arch Linux
KDE Plasma Version: 5.23.3
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
Kernel Version: 5.15.2-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 530

I'm seeing what I think is the same issue with Plasma 5.23.3 on OpenSUSE Tumbleweed with all SDL2 applications when fullscreen.

What appears to be happening is that the application is receiving a configure request to resize itself to 1×1, which SDL2 accepts. In my case, due to a scale factor of 2.00, this results in the game rendering to a 2px×2px buffer, which is what shows up in the taskbar thumbnail preview.

SDL2 has code to ignore resizes from configure events which try to resize a non-resizable window, but it only takes effect in non-fullscreen modes. 

I haven't found toggling VSync does anything here: the game gets a 1×1 configure event regardless. Nor am I running applications in Flatpack. Equally, I can reproduce this with the latest main branch of SDL2. As noted, setting SDL_VIDEODRIVER=x11 works around the issue by using XWayland.

Excerpts from WAYLAND_DEBUG which illustrate the issue:
[449104.573]  -> xdg_toplevel@29.set_fullscreen(wl_output@16)
[449106.869] wl_display@1.delete_id(27)
[449107.012] xdg_toplevel@29.configure(1600, 900, array)
[449107.061] xdg_surface@28.configure(65673)
[449107.112]  -> wl_surface@23.set_buffer_scale(2)
[…]
[449384.857] xdg_toplevel@29.configure(1, 1, array)
[449384.874] xdg_surface@28.configure(65674)
[449384.887]  -> wl_surface@23.set_buffer_scale(2)
[449384.899]  -> wl_compositor@4.create_region(new id wl_region@32)
[449384.909]  -> wl_region@32.add(0, 0, 1, 1)
[449384.929]  -> wl_surface@23.set_opaque_region(wl_region@32)
[449384.938]  -> wl_region@32.destroy()
[449384.944]  -> xdg_surface@28.set_window_geometry(0, 0, 1, 1)
[449384.963]  -> xdg_surface@28.ack_configure(65674)

I'm guessing the issue in 6.23.3 with the invisible 1×1 windows might be related to bug #445444:
https://bugs.kde.org/show_bug.cgi?id=445444

In which case there might be a fix for that queued in the next release:
https://invent.kde.org/plasma/kwin/-/commit/325208347c40d7311aea83572b5150ba3750cba9

Just updated to Plasma 5.23.4, and this time if I run Xonotic in Wayland mode it crashes, leaving "xdg_surface@29: error -1: invalid window geometry size (0x0)" as the error message in the terminal, so the fix for bug 445444 does affect Xonotic, just differently.

This is now looking like it's an SDL bug: I think the correct thing here is for SDL to detect that a 0×0 window has been requested and interpret that as the compositor not caring about the window size (so SDL shouldn't change it).

It works fine for me with KWin 5.23.4 and this patch to SDL2:
https://github.com/libsdl-org/SDL/pull/5064

There's apparently some debate about what getting a 0×0 configure message actually means when a window is fullscreen.

See the discussion in the SDL github PR:
https://github.com/libsdl-org/SDL/pull/5064

I personally think KWin's older behaviour of sending a valid size in the event is nice, but equally it makes no sense to me that getting a 0×0 configure event should result in SDL resizing the window to 0×0 (and hence crashing, as that's not valid).

Given every SDL application is now crashing on startup, this is definitely a bug, but whether its KWin's bug, SDL's bug, or (possibly) both remains to be seen…

> There's apparently some debate about what getting a 0×0 configure message actually means when a window is fullscreen.

Normally, you should receive window geometry size other than 0x0 when the compositor wants a window to be shown in fullscreen mode. It's a kwin bug, will investigate it.

Created attachment 144295 [details]
WAYLAND_DEBUG log

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1755

Git commit 9cc80d7468c92a2800daf98319e626e022ff1045 by Vlad Zahorodnii.
Committed on 07/12/2021 at 09:50.
Pushed by vladz into branch 'master'.

wayland: Resize the client to last requested client size if decoration is destroyed

If the decoration is destroyed before the window is mapped, kwin can
respond with a configure event that has 0x0 size. New tests check that
problematic case.

M  +48   -0    autotests/integration/xdgshellclient_test.cpp
M  +2    -1    src/abstract_client.cpp

https://invent.kde.org/plasma/kwin/commit/9cc80d7468c92a2800daf98319e626e022ff1045

Git commit 6a84b9454c869a16c2fa5fd49a8fac4a9497f30f by Vlad Zahorodnii.
Committed on 07/12/2021 at 10:21.
Pushed by vladz into branch 'Plasma/5.23'.

wayland: Resize the client to last requested client size if decoration is destroyed

If the decoration is destroyed before the window is mapped, kwin can
respond with a configure event that has 0x0 size. New tests check that
problematic case.
(cherry picked from commit 9cc80d7468c92a2800daf98319e626e022ff1045)

M  +48   -0    autotests/integration/xdgshellclient_test.cpp
M  +2    -1    src/abstract_client.cpp

https://invent.kde.org/plasma/kwin/commit/6a84b9454c869a16c2fa5fd49a8fac4a9497f30f

This is not fixed, however, there is different behavior now.

In Plasma 5.23.4 instead of opening an invisible window, they just crash instantly.

If there's a different behavior or manifestation of the issue, please open a new bug report. Thanks.

https://bugs.kde.org/show_bug.cgi?id=447556