search

hyprwm / Hyprland

Hyprland is a highly customizable dynamic tiling Wayland compositor that doesn't sacrifice on its looks.
https://hyprland.org
BSD 3-Clause "New" or "Revised" License
18.24k stars 758 forks source link

kitty: wl_surface error 2: Buffer size (958x538) is not divisible by scale (4) #509

Closed 257 closed 2 months ago

257 commented 1 year ago
vaxerski commented 1 year ago

why are you scaling up 4 times, what's wrong with you

257 commented 1 year ago

works in sway though. this is probably bobbling up from wayland.

kovidgoyal commented 1 year ago

https://github.com/kovidgoyal/kitty/issues/4878#issuecomment-1134259604

vaxerski commented 1 year ago

thank you!

lakinwecker commented 1 year ago

I am experiencing the same issue. In my case, I tracked it down to the fact that kitty stores a cached window-size:

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

And this window size does not take into account the scale factor. If I remove that file, kitty launches fine. I'm also going to update the linked issue with this information and then see if I can configure kitty to avoid this behavior.

lakinwecker commented 1 year ago

In the end, I made a new issue and am linking it here so that people who end up on this one can follow the discussion: kovidgoyal/kitty#5467

lakinwecker commented 1 year ago

Based on the information provided in the kitty issue, this may well be an issue with hyprland and not in kitty itself.

Set your kitty config to be a prime number, then launch kitty with the attempt to use that resolution. It tries to resize to that number multiplied by the scale and it fails with this Wayland error:

~ took 6s 
-> cat ~/.cache/kitty/main.json
{"window-size": [701, 419]}⏎                                                                             
~ 
-> kitty --config NONE -o hide_window_decorations=yes -o remember_window_size=yes --debug-rendering
GL version string: '4.6 (Core Profile) Mesa 22.1.7' Detected version: 4.6
top-level configure event: size: 0x0 states: 
XDG decoration configure event received: has_server_side_decorations: 1
Calling wl_pointer_set_cursor in setCursorImage with surface: 0x56093867b4d0
Scale changed to 2 in dispatchChangesAfterConfigure
Resizing framebuffer to: 701x419 at scale: 2
final window content size: 701x419 resized: 1
Setting window geometry in configure event: x=0 y=0 701x419
Calling wl_pointer_set_cursor in setCursorImage with surface: 0x56093867b4d0
Scale changed to 2 in surface enter event
Resizing framebuffer to: 701x419 at scale: 2
top-level configure event: size: 859x517 states: TOPLEVEL_STATE_ACTIVATED TOPLEVEL_STATE_MAXIMIZED 
Calling wl_pointer_set_cursor in setCursorImage with surface: 0x56093867b4d0
Resizing framebuffer to: 859x517 at scale: 2
final window content size: 859x517 resized: 1
Setting window geometry in configure event: x=0 y=0 859x517
[247 00:32:20.255818] [glfw error 65544]: process_desktop_settings: failed with error: [org.freedesktop.DBus.Error.ServiceUnknown] The name org.freedesktop.portal.Desktop was not provided by any .service files
wl_surface@22: error 2: Buffer size (701x419) is not divisible by scale (2)
[247 00:32:20.263018] [glfw error 65544]: Wayland: fatal display error: Protocol error
Calling wl_pointer_set_cursor in setCursorImage with surface: 0x56093867b4d0
grappas commented 1 year ago

It appears that it's not only kitty but also Freecad and wezterm have the very same bug.

grappas commented 1 year ago

https://github.com/wez/wezterm/issues/3234 https://github.com/wez/wezterm/issues/2445

SquirrelModeller commented 1 year ago

I found a potential fix for applications with this error. Changing the cursor theme might resolve it (It fixed my issue with blender)

What programs are affected? As pointed out by kovidgoyal linking to the kitty comment, following the link in that comment it is clear that this bug is with libwayland.

How to temporarily fix an application with this problem Change the cursor theme (for blender I changed the GTK-3 cursor theme). If the cursor default size is divisible by the scaling factor, it works.

I think this issue might be solved now? I'd suggest adding this workaround to the docs of Hyprland to avoid duplicates issues, like the one I submitted.

Erothas commented 1 year ago

I came here to say that I was about start a new issue about this, as I have the same problem, and can not launch OBS whatsoever. Unless of course I disable my fractional scaling of my second monitor.

wl_surface@31: error 2: Buffer size (1234x1067) is not divisible by scale (2) Same error. For context, my second monitor is using 1.5 as the scale value.

TheSunCat commented 1 year ago

I have also run into this with launching OBS on my 1440p secondary display (scale of 1.0):

Buffer size (1259x334) is not divisible by scale (2)

OBS works fine if I launch it on my laptop's display (2560x1600, scale 1.4) then move it to the problematic monitor.

TheSunCat commented 1 year ago

Turns out this only happens with the OBS flatpak. The obs-studio Arch package does not exhibit this issue in my testing (but has other issues on my system, hence I need to use the flatpak).

TheSunCat commented 1 year ago

This crash happens often but not consistently with:

As of recently I have noticed it happening more often. Is there anything I can do to help get this fixed or at least work around it for now? It is difficult to use Hyprland knowing many programs can and will instantly crash and lose unsaved work. This does not happen in Sway with the same scaling options.

hftsai256 commented 1 year ago

I can second this. I have two monitors: the 2k monitor (at 1.0 scaling) doesn't suffer from this problem, but when I put any work on the native laptop screen (at 1.2 scaling), lots of applications would crash, including pop-up dialogs from dolphin.

Monitor eDP-1 (ID 0):
    1920x1200@59.950001 at 480x1440
    description: Sharp Corporation 0x1548 (eDP-1)
    make: Sharp Corporation
    model: 0x1548
    serial:
    active workspace: 1 (1)
    reserved: 0 29 0 0
    scale: 1.20
    transform: 0
    focused: no
    dpmsStatus: 1
    vrr: 0

Monitor DP-2 (ID 1):
    2560x1440@74.971001 at 0x0
    description: HP Inc. HP Z27n G2 6CM0150NZB (DP-2 via DP)
    make: HP Inc.
    model: HP Z27n G2
    serial: 6CM0150NZB
    active workspace: 2 (2)
    reserved: 0 29 0 0
    scale: 1.00
    transform: 0
    focused: yes
    dpmsStatus: 1
    vrr: 0
TheSunCat commented 1 year ago

I am now using a patched wlroots subproject with commit 18595000f3a21502fd60bf213122859cc348f9af reverted. This changes the crash into a warning (it's still a protocol violation, so not a fix!), but at least I can go back to using Hyprland. Hope it helps anyone else who runs into this issue.

hftsai256 commented 1 year ago

Many thanks. I traced this commit and reached this issue on sway. It seems like this is up to each application to handle this bug.

bharathanr commented 11 months ago

I also have the same issue on my monitor with scale 1.5. @kovidgoyal could you please check one more time if kitty needs to handle this specifically, I only ask since the issue @hftsai256 links suggests that each application needs to handle it.

I've already read Kitty Issue 4878 and Kitty Issue 5467 and I've also looked at the commit where you've worked around the problem with hyprland Kitty Workaround for Hyprland, but I still do not understand exactly where this needs to be fixed. I would really appreciate your insights.

EDIT: I'm on kitty 0.29.2 - I'm pretty sure that commit is present in this version, but I'm listing it just in case I am wrong.

kovidgoyal commented 11 months ago

This needs to be fixed in the compositor and more generally in the wayland cursor library. applications can do nothing about it. The commit you linked to has nothing to do with this.

vaxerski commented 11 months ago

in the case of wlroots, in wlroots. Well, unless a compositor ditches the wlroots' cursor impl

bharathanr commented 11 months ago

This needs to be fixed in the compositor and more generally in the wayland cursor library. applications can do nothing about it. The commit you linked to has nothing to do with this.

Thank you so much for your prompt response @kovidgoyal. I'll try to work around it by setting a cursor size

@vaxerski Thank you for your prompt response as well. I'll try looking in the wlroots repo for an issue related to this.

Smuglix commented 6 months ago

As @lakinwecker have suggested in kovidgoyal/kitty#5467 that putting remember_window_size no inside kitty config, prevents kitty from crashing when launching it on scaled monitor. However, it still crashes if you move it from unscaled monitor to scaled with mouse.

I've noticed that it doesn't crash if you move it in floating mode between monitors, so there is my workaround in addition to remember_window_size no:

# -- Mouse --
bind = SUPER, mouse:272, togglefloating
bindm=SUPER,mouse:272,movewindow
bindr = SUPER, mouse:272, togglefloating
bindm=SUPER,mouse:273,resizewindow

putting this inside hyprland config, toggles floating on window before you move it with mouse. The "r" flag on second togglefloating bind brings window to normal mode after you release LMB.

TheSunCat commented 4 months ago

This error now happens nearly every time imv is opened. Something like this:

apm@apg ~> imv
Reading paths from stdin...
wl_surface@10: error 2: Buffer size (512x621) is not divisible by scale (2)

Since it's not a cursor surface, this still triggers the bug despite the existing workaround in wlr_compositor.c. One could add a wlroots patch that just avoids that if entirely, but obviously it'd be better to get this fixed in wlroots itself.

I'm not sure if other apps are affected.

NagiNikaido commented 3 months ago

This error now happens nearly every time imv is opened. Something like this:

apm@apg ~> imv
Reading paths from stdin...
wl_surface@10: error 2: Buffer size (512x621) is not divisible by scale (2)

Since it's not a cursor surface, this still triggers the bug despite the existing workaround in wlr_compositor.c. One could add a wlroots patch that just avoids that if entirely, but obviously it'd be better to get this fixed in wlroots itself.

I'm not sure if other apps are affected.

Same issue appears right after upgrading Hyprland from 0.35.0-2 to 0.37.0-1. 0.36.0 is not tested because it was not packaged in Archlinux official repos. Maybe will test it later.

Upd 24.04.04: Git bisect'ed from v0.35.0 to v0.37.0, the following commit seems to be the first bad commit that produced imv's crash.

f4f3aa2e505ca1b22688fb4a32f31c4bfb851dd0 is the first bad commit
commit f4f3aa2e505ca1b22688fb4a32f31c4bfb851dd0
Author: vaxerski <vaxry@vaxry.net>
Date:   Wed Feb 28 11:45:43 2024 +0000

    layout: add size prediction for initial xdg commits

    fixes #4022

 src/events/Windows.cpp       |  4 ++-
 src/layout/DwindleLayout.cpp | 66 ++++++++++++++++++++++++++++++++++++++------
 src/layout/DwindleLayout.hpp |  1 +
 src/layout/IHyprLayout.cpp   |  4 +++
 src/layout/IHyprLayout.hpp   |  6 ++++
 src/layout/MasterLayout.cpp  | 27 ++++++++++++++++++
 src/layout/MasterLayout.hpp  |  1 +
 7 files changed, 100 insertions(+), 9 deletions(-)
thejch commented 2 months ago

This error now happens nearly every time imv is opened. Something like this:

apm@apg ~> imv
Reading paths from stdin...
wl_surface@10: error 2: Buffer size (512x621) is not divisible by scale (2)

Since it's not a cursor surface, this still triggers the bug despite the existing workaround in wlr_compositor.c. One could add a wlroots patch that just avoids that if entirely, but obviously it'd be better to get this fixed in wlroots itself.

I'm not sure if other apps are affected.

since hyprland has now forked wlroots, can we apply the patch that @TheSunCat mentioned downstream? @vaxerski i don't think it will be fixed upstream at wlroots since wlroots would rather report this as an error, because it is indeed a violation of protocols from the app's part as i understand it see discussions at https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/733#note_1738935 and https://gitlab.freedesktop.org/wayland/wayland/-/issues/194 however, since many apps are having this problem (kitty, imv, wezterm to name a few), it may be worth it to patch a workaround here for hyprland, provided that this patch doesn't break other things, until these apps have fixed it. the patch would simply be reverting this commit: https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/18595000f3a21502fd60bf213122859cc348f9af

vaxerski commented 2 months ago

I am fine with this once we get https://github.com/hyprwm/wlroots-hyprland/pull/7 down

vaxerski commented 2 months ago

closing per https://github.com/hyprwm/wlroots-hyprland/pull/9