Kitty on wayland will remember a non-scaled size and try to resize its window to this size

[lakinwecker]

In hyprland, with a 4k monitor and a 2x scaling factor, if I launch kitty such that the logical pixel size of the window is not a factor of 2, the initial window launch is fine. Hyprland and wlroots will properly scale everything by a factor of 2. But kitty will store the desired window size without that scaling factor. Resulting in a cached windows size like:

-> cat ~/.cache/kitty/main.json
{"window-size": [859, 517]}

When kitty is launched the next time after this, it will attempt to set this size and wlroots will error, because this is not a factor of the scaling that is set.

The error will look like:

wl_surface@22: error 2:  Buffer size (859x517) is not divisible by scale (2)

Ideally, when operating under wayland, kitty should store the window-size with the appropriate scaling. I realize that the wayland ecosystem is young and may not yet provide the right API for this yet. But I still think it's worth knowing about and knowing the solution. This is related to #4878 but is not quite the same thing, as that one is due to cursor sizes and this one is not.

[lakinwecker]

Setting the following settings seems to workaround it:

remember_window_size  no
initial_window_width  1920
initial_window_height 1080

[kovidgoyal]

Sigh, Wayland really is God's gift to mankind. Good find though. I
should probably just change the code to store the scaled numbers rather
than the unscaled numbers with scale. Which it should really be doing
anyway.

[kovidgoyal]

Actually, I took a look at this, and those numbers are already scaled. I
tried using prime numbers under GNOME, and they worked fine. The Wayland
backend multiplies the numbers by the scale, as can be seen by running

cat ~/.cache/kitty/main.json
{"window-size": [701, 419]}

Those are prime numbers and so cannot be a multiple of the scale unless
it is 1.

kitty --config NONE -o hide_window_decorations=yes -o remember_window_size=yes --debug-rendering

gives the log:

GL version string: '4.6 (Core Profile) Mesa 22.1.7' Detected version: 4.6
 configure event on mutter.
Calling wl_pointer_set_cursor in setCursorImage with surface: 0x560559b74190
top-level configure event: size: 701x419 states: TOPLEVEL_STATE_ACTIVATED 
Calling wl_pointer_set_cursor in setCursorImage with surface: 0x560559b74190
Scale changed to 3 in dispatchChangesAfterConfigure
Resizing framebuffer to: 701x419 at scale: 3
final window content size: 701x419 resized: 1
Setting window geometry in configure event: x=0 y=0 701x419
Scale changed to 3 in surface enter event
Resizing framebuffer to: 701x419 at scale: 3
Calling wl_pointer_set_cursor in setCursorImage with surface: 0x560559b74190
prompt_marking: x=0 y=0 op='A'
Calling wl_pointer_set_cursor in setCursorImage with surface: 0x560559b74190
Calling wl_pointer_set_cursor in setCursorImage with surface: 0x560559b74190

As we can see they work fine at scale 3. So I dont know what's going on
with hyprland, but you need to follow up there.

[lakinwecker]

Thanks for the information. Sorry for sending you on a wild chase for a non-bug. I'll see if I can track down what is going on with Hyprland. But as I understand your comment, it is Hyprland that should be ensuring the size is divisible by the scale? Thanks!

[kovidgoyal]

I am saying that the size that kitty stores in the json file is the
scaled size, and it works as expected with every wayland compositor
other than hyprland. Beyond that, I would have to go read the glfw
wayland backed code to tell you what is going on, that is not worth the
effort at this juncture.

[kovidgoyal]

And I did spend some time looking at the backend code. What happens is that glfw calls wl_egl_create_window() at scale 1 when creating the window, since it does not know what scale it should use until the compositor tells it. Once the compositor tells it the scale via configure event, glfw will resize the window via wl_egl_window_resize() to a proper scaled size. Apparently hyprland is complaining because of the initial window creation size not being a multiple of the scale. This is a bug in hyprland. Imagine if the user has two monitors with different scales. There is no way for the client to know what scale to use. The compositor cant complain when the initial window creation is not a multiple of the scale it wants.

[kovidgoyal]

And I figured out what hyprland didnt like and worked around it, see the closing commit for details.

[lakinwecker]

Wow, nice find! I had fully intended to follow up with a better investigation, but I was way too slow. Thanks!