Bug 448856 - [Wayland] Window is positioned at 0,0 when Fullscreen->Windowed transition occurs
Summary: [Wayland] Window is positioned at 0,0 when Fullscreen->Windowed transition oc...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: wayland-generic (show other bugs)
Version: 5.23.4
Platform: Fedora RPMs Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-20 22:34 UTC by Ethan Lee
Modified: 2022-01-24 19:58 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.24


Attachments
SDL test program, including build/run instructions (836 bytes, text/plain)
2022-01-20 23:04 UTC, Ethan Lee
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ethan Lee 2022-01-20 22:34:04 UTC
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
Comment 1 Ethan Lee 2022-01-20 22:34:50 UTC
Forgot to link to the original SDL report: https://github.com/libsdl-org/SDL/issues/4571
Comment 2 Ethan Lee 2022-01-20 23:04:45 UTC
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.
Comment 3 Vlad Zahorodnii 2022-01-24 13:22:35 UTC
Cannot reproduce the issue but the example app is placed oddly when it's started.
Comment 4 Bug Janitor Service 2022-01-24 13:37:15 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1935
Comment 5 Vlad Zahorodnii 2022-01-24 18:46:09 UTC
@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.
Comment 6 Vlad Zahorodnii 2022-01-24 19:35:02 UTC
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
Comment 7 Vlad Zahorodnii 2022-01-24 19:38:46 UTC
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
Comment 8 Ethan Lee 2022-01-24 19:39:01 UTC
@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!
Comment 9 Vlad Zahorodnii 2022-01-24 19:58:05 UTC
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. :)