unable to move window under wayland

[mendaxcat]

Describe the bug
after commit ac407d42, the window cannot be moved after launching kitty

To Reproduce
Steps to reproduce the behavior:

1. launch kitty using kitty --config NONE
2. use mouse to drag the window
3. the window simply does not move

Environment details

kitty 0.24.4 (90ed5959de) created by Kovid Goyal
Linux mendaxca 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
Debian GNU/Linux 11 mendaxca /dev/tty

Running under: Wayland
Frozen: False
Paths:
  kitty: /tmp/kitty/linux-package/bin/kitty
  base dir: /tmp/kitty/linux-package/lib/kitty
  extensions dir: /tmp/kitty/linux-package/lib/kitty/kitty
  system shell: /bin/bash

Config options different from defaults:

Important environment variables seen by the kitty process:
	PATH                                /home/mendaxca/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
	LANG                                C.UTF-8
	VISUAL                              nvim
	SHELL                               /bin/bash
	GLFW_IM_MODULE                      ibus
	DISPLAY                             :0
	WAYLAND_DISPLAY                     wayland-0
	USER                                mendaxca
	XDG_MENU_PREFIX                     gnome-
	XDG_SESSION_DESKTOP                 gnome
	XDG_SESSION_TYPE                    wayland
	XDG_CURRENT_DESKTOP                 GNOME
	XDG_SESSION_CLASS                   user
	XDG_RUNTIME_DIR                     /run/user/1000

[kovidgoyal]

@Nefsen402 that's your code. Any comments?

[Nefsen402]

That's odd that surface commits (usually meant to resize) is effecting the moving the window. I guess this must be a problem with client side decorations, correct? According to the bisect we're talking about a commit that just moves the wl_surface_commit to comply more with the wayland protocol which is really unexpected! Maybe we alway want to run this after the surface commit.

inform_compositor_of_window_geometry(window, "configure");
if (live_resize_done) _glfwInputLiveResize(window, false);

[kovidgoyal]

Yeah it's likely to be a CSD issue. I spend as little time on Wayland as I can possibly get away with, so not sure what the appropriate fix is. Does the wayland protocol actually require the surface to be committed even if the configure didnt change anything? Seems rather wasteful.

[Nefsen402]

inform_compositor_of_window_geometry will set the xdg_surafce geometry bounds. This state is double buffered meaning it gets sent in the next wl_surface_commit. In fact this means that the old code was wrong, because it would commit, then send the geometry. However it seems to be breaking things nontheless. live_resize_done should be false when just moving the window so there should be no functional difference for ac407d4. Are we absolutely sure it's this commit? I think we're dealing with a compositor bug here though.

[Nefsen402]

Does this patch fix the problem for you?

diff --git a/glfw/wl_window.c b/glfw/wl_window.c
index 7bcff80d..de95e8af 100644
--- a/glfw/wl_window.c
+++ b/glfw/wl_window.c
@@ -517,10 +517,10 @@ static void xdgSurfaceHandleConfigure(void* data,
             debug("final window content size: %dx%d\n", window->wl.current.width, window->wl.current.height);
             _glfwInputWindowFocus(window, window->wl.current.toplevel_states & TOPLEVEL_STATE_ACTIVATED);
             ensure_csd_resources(window);
-            inform_compositor_of_window_geometry(window, "configure");
             if (live_resize_done) _glfwInputLiveResize(window, false);
         }
     }
+    inform_compositor_of_window_geometry(window, "configure");
     wl_surface_commit(window->wl.surface);
 }

[mendaxcat]

moving the inform_compositor_of_window_geometry() does not fix the problem

some additional info

• the window is positioned on top-left of the screen without title bar after launch
• the window will work as expected after maximizing
  

[Nefsen402]

Hmm, it looks like CSD is not working at all. Only after entering/exiting fullscreen you start seeing decorations that you can interact with and move? This is what it looks like through tinywl which seems to handle the current kitty release correctly.

[Nefsen402]

I stared at the code and I noticed that decorations weren't being handled correctly much like toplevel configures. (https://wayland.app/protocols/xdg-decoration-unstable-v1#zxdg_toplevel_decoration_v1:event:configure). I made a patch that should be more conformant. Does this patch fix things?
patch.txt

@kovidgoyal Any reason you added the set flag for toplevel configures? It shouldn't be necessary. I understand that the toplevel configure might come in the wrong order if you're running on a broken compositor, but if that were the case then the condition checking for width/height/toplevel_states would fail.

[mendaxcat]

yes, window decorations appear after entering and exiting full screen

i tried building tinywl, but the decorations are still missing in it. then i installed another wayland compositor called weston, kitty(v0.24.4 with or without patch) works fine in it. however, the decorations are still not shown under gnome with or without you last patch.

[kovidgoyal]

@kovidgoyal Any reason you added the set flag for toplevel configures? It shouldn't be necessary. I understand that the toplevel configure might come in the wrong order if you're running on a broken compositor, but if that were the case then the condition checking for width/height/toplevel_states would fail.

I like to be explicit about these things. The intended behavior is that commit should occur after a configure, the set flag ensures that is always the case, regardless of other conditions, which might change in the future.

[Nefsen402]

I found numerous problems while investigating this further. CSD has a lot of nuance and some of the problems I fixed definitely will explain this issue.
patch.txt

[kovidgoyal]

I will note that this issue doesn't reproduce for me with current master under GNOME 41. The only issues I can find are the long standing ones of right clicking on the titlebar being rather iffy, sometime th emenu disappears immediately sometimes it appears in the wrong place.

[Nefsen402]

Yeah, I haven't been able to reproduce this exact issue as well. I hate to be passing random patches to people but it would be nice to get this fixed.