-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug][Commit bisected] Commit breaks fullscreen SDL2 programs behaviour #1812
Comments
I did some debugging with OpenTyrian and found that the geometry of Here's the debug log with some diff --git a/src/xdg.c b/src/xdg.c
index 488f67fd..35dcff47 100644
--- a/src/xdg.c
+++ b/src/xdg.c
@@ -152,6 +152,14 @@ handle_commit(struct wl_listener *listener, void *data)
if (update_required) {
view_impl_apply_geometry(view, size.width, size.height);
+ wlr_log(WLR_ERROR, "applied geometry: %dx%d", size.width, size.height);
+ wlr_log(WLR_ERROR, "wl_surface geometry: %dx%d",
+ xdg_surface->surface->current.width, xdg_surface->surface->current.width);
+ wlr_log(WLR_ERROR, "xdg_surface geometry: %dx%d",
+ xdg_surface->current.geometry.width, xdg_surface->current.geometry.height);
+ struct wlr_box box;
+ wlr_xdg_surface_get_geometry(xdg_surface, &box);
+ wlr_log(WLR_ERROR, "computed xdg_surface geometry: %dx%d", box.width, box.height);
/*
* Some views (e.g., terminals that scale as multiples of rows
As a side note, the xdg-shell protocol says:
So using the intersection of geometries of |
After the call to wlr_xdg_surface_get_geometry, sway adds a couple more checks than what labwc does where labwc only checks for width/height not sure if that makes a difference in this case. Sway - sway/desktop/xdg_shell.c ~ line 300 |
@ahesford, thoughts? |
I don't fully understand the problem, but it seems like the client lies about its size in the commit. If the value of This would override what wlroots thinks of the window dimensions only if it thinks something about the dimensions, in which case it would be forcing the geometry in the next configure request anyway. |
The values of The problem happens like this:
How about syncing diff --git a/src/xdg.c b/src/xdg.c
index 2b8bf96e..46bb8fa4 100644
--- a/src/xdg.c
+++ b/src/xdg.c
@@ -156,8 +156,8 @@ handle_commit(struct wl_listener *listener, void *data)
*/
struct wlr_xdg_toplevel *toplevel =
xdg_toplevel_from_view(view);
- toplevel->scheduled.width = view->current.width;
- toplevel->scheduled.height = view->current.height;
+ toplevel->scheduled.width = toplevel->current.width;
+ toplevel->scheduled.height = toplevel->current.height;
}
}
} |
That change breaks the behavior that bd5dcb3 was intended to fix:
With bd5dcb3 in place, nothing unexpected will happen. Reverting bd5dcb3 or replacing I see no reason why the client should be committing a buffer with the windowed geometry, but if we want to work around seemingly broken clients, we'll have to get clever. |
I don't understand the log above, where does that size come from? Maybe the issue here is actually the Qt-workaround above and |
If these clients behave as expected in Sway, I wonder if Sway handle the foot resize issue properly if foot is floating rather than tiled (is this even possible?). If not, it may be the case that we are correct, the client and Sway are both wrong, and two wrongs make a right here. |
changing font size in latest foot on latest sway has foot resize correctly, then picking another window doesn't make it change size (stays the same). seems to behave correctly |
Thanks for testing. Was the font change done after a manual resize of the window, or was foot still in its initially configured size? In labwc without the fix, foot will behave even after font resizing until a manual resize triggers |
any order of operations i test seems to work ok and not have it resize itself to some older size inadvertantly |
For foot, sway works properly because it sends a second configure in the commit handler when it detects a size change. We explicitly avoid doing so because I was worried about infinite loops. Maybe this concern is unwarranted if we always send back the exact same size that the client just committed. In any case, I don't think that difference explains the SDL anomaly here. |
Hi there,
This commit:
bd5dcb3
breaks certain SDL2 games fullscreen startup: when they are started in fullscreen mode, they fail to run in fullscreen mode, being displayed on a window instead.
Before this commit, they started nicely in fullscreen mode when told to do so.
I have found these games are affected by this commit (probably most of the programs and games are affected):
-OpenTyrian (https://github.com/opentyrian/opentyrian), configure it to start in fullscreen mode inside the game menu, then re-run the game.
-Schismtracker (https://github.com/schismtracker/schismtracker), start with
schismtracker -f
-sm64ex-alo (https://github.com/AloUltraExt/sm64ex-alo), configure it to start in fullscreen mode inside the game menu, then re-run the game.
Before this commit, the games started nicely in fullscreen mode when configured or told to do so.
NOTES:
-Other WLRoots-based compositors are not affected. Current Sway for example runs the fullscreen SDL2 programs nicely.
-Weston compositor is not affected.
The text was updated successfully, but these errors were encountered: