Bug 444962

Summary: Some wayland native games in KDE 5.23 open in corner of screen unless I force them to run in xwayland (and in 5.23.3 they open as an invisible window)
Product: kwin Reporter: p d <pizzadude>
Component: wayland-genericAssignee: KWin default assignee <kwin-bugs-null>
Severity: normal CC: david, nate, putr4.s
Priority: NOR Keywords: regression
Version: 5.23.2   
Target Milestone: ---   
Platform: Other   
OS: Other   
Latest Commit: Version Fixed In: 5.23.5
Attachments: WAYLAND_DEBUG log

Description p d 2021-11-04 17:11:56 UTC
This didn't happen until KDE 5.23. On Intel HD Graphics 620, in Fedora 35 KDE wayland session, when running some games (like Xonotic flatpak from flathub), the games are stuck at the bottom right of the screen like in this pic:  https://i.imgur.com/hauYCm8.jpg

Disabling the wayland socket via flatseal solves the issue. Disabling vsync in-game also solves the issue, but that makes the game choppy for some weird reason. In the picture I linked above, I ran the flatpak with --socket=wayland to reproduce the issue, because I already disabled the wayland socket to workaround the issue. The xonotic flatpak ships with wayland enabled.

1. Be on Intel HD Graphics and use KDE 5.23 wayland session
2. Install Xonotic from flathub and make sure vsync in xonotic is enabled
3. The game will launch in the corner of screen

Wayland native games launch in the corner of the screen

Games to launch properly.

Operating System: Fedora Linux 35
KDE Plasma Version: 5.23.2
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.15-300.fc35.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-7300U CPU @ 2.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 620

Comment 1 p d 2021-11-19 06:08:06 UTC
With KDE 5.23.3 instead of opening up in the corner, wayland only games are completely invisible.
Comment 2 p d 2021-11-20 06:50:49 UTC
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.
Comment 3 Prajna Sariputra 2021-11-20 08:50:43 UTC
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
Comment 4 David Gow 2021-11-23 07:22:09 UTC
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)
Comment 5 David Gow 2021-11-26 04:18:31 UTC
I'm guessing the issue in 6.23.3 with the invisible 1×1 windows might be related to bug #445444:

In which case there might be a fix for that queued in the next release:
Comment 6 Prajna Sariputra 2021-11-30 23:17:54 UTC
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.
Comment 7 David Gow 2021-12-04 06:27:38 UTC
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:
Comment 8 David Gow 2021-12-05 03:24:43 UTC
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:

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…
Comment 9 Vlad Zahorodnii 2021-12-07 06:51:32 UTC
> 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.
Comment 10 Vlad Zahorodnii 2021-12-07 07:06:08 UTC
Created attachment 144295 [details]
Comment 11 Bug Janitor Service 2021-12-07 07:36:32 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1755
Comment 12 Vlad Zahorodnii 2021-12-07 10:11:58 UTC
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

Comment 13 Vlad Zahorodnii 2021-12-07 10:38:26 UTC
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

Comment 14 p d 2021-12-26 21:57:39 UTC
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.
Comment 15 Nate Graham 2021-12-26 22:06:02 UTC
If there's a different behavior or manifestation of the issue, please open a new bug report. Thanks.