SUMMARY When a Wayland window starts in fullscreen, then transitions to windowed mode, there is a risk that the window will be anchored to (0,0). For the default Plasma layout this is normally fine, but if for whatever reason the user has the taskbar at the top rather than the bottom, the decorations will be hidden behind the taskbar and therefore be inaccessible. We believe this is caused by the fact that it _starts_ in fullscreen mode, and so it technically makes sense that the first and only known position is at the very top left corner. If the application starts in windowed mode this does not occur. STEPS TO REPRODUCE This can be reproduced with SDL and a small test program, found here. From a Fedora installation with the taskbar at the top of the display... 1. dnf install SDL2-devel (or build/install SDL from source, latest Git does have some fixes for libdecor!) 2. Download/Build titlebar.c, linked above (see instructions at the top of the file) 3. SDL_VIDEODRIVER=wayland ./titlebar 4. Press the space bar OBSERVED RESULT The window is at the top left of the screen, making the title bar inaccessible EXPECTED RESULT The window is either at the top left of the usable desktop space, or somewhere else that's accessible (i.e. the center of the display). SOFTWARE/OS VERSIONS * plasma-desktop 5.23.4-1.fc35.x86_64 * Kernel 5.15.14-200.fc35.x86_64 * Both Mesa 21.3.4 and NVIDIA 495.46
Forgot to link to the original SDL report: https://github.com/libsdl-org/SDL/issues/4571
Created attachment 145686 [details] SDL test program, including build/run instructions Test program attached, since I foolishly copied plaintext from another report which included a URL to the test.
Cannot reproduce the issue but the example app is placed oddly when it's started.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1935
@Ethan not sure if you're the right person to speak or should I go downstream, but SDL's initialization sequence of initially fullscreen windows is not optimal with kwin. with kwin_wayland, the ideal startup sequence looks as follows: -> create xdg_toplevel -> set app_id, min/max size -> call set_maximized or set_fullscreen if the window has to be displayed maximize or fullscreen, respectively -> create xdg_toplevel_decoration if needed and set the preferred mode -> wl_surface_commit() <- kwin responds with a configure event -> start painting \o/ In other words, kwin_wayland really wants to have as much as possible initialization happen before the first surface commit. See also https://bugs.chromium.org/p/chromium/issues/detail?id=1268308 But it seems like SDL can issue several set_fullscreen requests and commit the surface multiple times with no buffer attached until the window is finally mapped.
Git commit b9b735708653ff6bf57278a1999679df31ee5775 by Vlad Zahorodnii. Committed on 24/01/2022 at 18:55. Pushed by vladz into branch 'master'. wayland: Fix getting the last configure event If there's only one configure event that changes the position of the window and it gets acknowledged but no buffer is attached yet, and a new configure is sent, then the ConfigurePosition flag won't be inherited by the new configure event and the window will be misplaced. In order to fix that, this change makes XdgSurfaceClient pop the last acknowledged configure event from the m_configureEvents list only when it's about to be applied for sure. M +34 -0 autotests/integration/xdgshellclient_test.cpp M +12 -6 src/xdgshellclient.cpp M +3 -0 src/xdgshellclient.h https://invent.kde.org/plasma/kwin/commit/b9b735708653ff6bf57278a1999679df31ee5775
Git commit 5ee29ce8f890ee7006fdde614a62853d76f21941 by Vlad Zahorodnii. Committed on 24/01/2022 at 19:38. Pushed by vladz into branch 'Plasma/5.24'. wayland: Fix getting the last configure event If there's only one configure event that changes the position of the window and it gets acknowledged but no buffer is attached yet, and a new configure is sent, then the ConfigurePosition flag won't be inherited by the new configure event and the window will be misplaced. In order to fix that, this change makes XdgSurfaceClient pop the last acknowledged configure event from the m_configureEvents list only when it's about to be applied for sure. (cherry picked from commit b9b735708653ff6bf57278a1999679df31ee5775) M +34 -0 autotests/integration/xdgshellclient_test.cpp M +12 -6 src/xdgshellclient.cpp M +3 -0 src/xdgshellclient.h https://invent.kde.org/plasma/kwin/commit/5ee29ce8f890ee7006fdde614a62853d76f21941
@Vlad Thanks for the info (and the fix that came in while I was checking this out)! Commits in SDL tend to be a bit fussy, mostly because the window calls from the application can be so arbitrary... but, I gave it a shot anyway, this cleans the commits up and now looks like what you listed: https://github.com/libsdl-org/SDL/pull/5257 Note the FIXME in this patch... I would love to know how to get around that!
Amazing, thanks! As for the FIXME comment, it looks like you've already addressed it while I was typing a review comment in the github pr. :)