-
-
Notifications
You must be signed in to change notification settings - Fork 946
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
kitty chrashes on GNOME 42 when moving to a HiDPI Display #4878
Comments
That's not an error from kitty, it's coming from libwayland. So kitty cannot |
Its not just HiDPI, the fallout of GNOME42 seems to be disastrous kitty without doing anything:
(note, this is not just a kitty specific issue, I've already seen GNOME apps not launching) |
Another idea, does hiding window decorations prevent the problem? hide_window_decorations yes in kitty.conf |
Hiding window decorations doesn't help.
The original error is still reproducible. The error found by @sp1ritCS also occurs sometimes instantly after starting kitty. |
Well, these both appear to be bugs in GNOME 42, you should report it there. Not sure what kitty can do about it. Can you try running kitty with --debug-rendering and post the output when re-creating these issues. |
I'm not sure what was the cause of my issue, but I assume it to just be a borked update. I rolled back to the pre GNOME 42 snapshot (and opened a bugreport, where I've got told by someone that he cannot reproduce it) and updated again, after which it worked (but it might have been that during that time kitty got auto rebuilt and then it worked). |
But, I've just tested setting my display scale to 200% and I can reproduce your issue (wl_surface@3: error 2: Buffer size (9x16) must be an integer multiple of the buffer_scale (2)) Launching kitty with --debug-rendering results in:
which is a lot more output than with 100% scale:
|
Is 9x16 in that log accurate? I cant think of anything that would create |
Yes, the log is exactly what came out of kitties stdout/err, copied from gnome-terminals buffer (If I had modified it, I'd have removed the unknown config key too 😄 ) I'm using KDEs "Breeze Snow" cursor theme, but unless it does some kind of 200% scale fuckery I don't unterstand, neither the smallest variant of "default" nor "text" fits in a 9x16 box. |
Is that log from just launching kitty? Not moving it between monitors as in the original report? I have added some more debug output about when exactly scale changes occur. Can you reproduce the log running from master? |
I have a problem starting kitty on Ubuntu 22.04 beta using Gnome 4.2. I have 3 monitors (laptop + 2 external), all 4K. If I scale the laptop display (fractional/integral scaling does not matter), kitty will not start, but fails with the error described above. If I set all displays to 100%, and scale the laptop display by selecting a lower resolution, kitty starts with no problem. |
Yes, this is just from launching kitty on 200% scale. From master:
|
Sorry I see nothing untoward in that. Mutter just killed the connection |
Only workaround i've found for now using fedora 36 with fractional scaling enabled at 125% display scale is is to disable wayland for now until issue can be resolved Add and reboot
This can also work if opening kitty from another terminal by adding this to your .bashrc or .zshrc file
|
You dont need an env var for this. Simply set linux_display_backend in |
I spent some more time looking into this and I think I have figured out the root cause. It's a bug/limitation in libwayland-cursor. https://gitlab.freedesktop.org/wayland/wayland/-/issues/194 Basically, libwayland-cursor returns cursor sizes that can be larger than the size requested by the application, and that larger size may not be divisible by the scale. sway works around this bug by not enforcing the divisibility requirement. swaywm/sway#6014 So this needs to be fixed in either libwayland-cursor or in GNOME to not enforce the divisibility requirement. |
The existing wayland cursor shape protocol is an awful mess with a years long unfixed crashing bug: #4878 (comment) If this new protocol is adopted by most compositors it can work around this. Currently wlroots and KDE I think. GNOME as usual will likely refuse to implement anything actually useful.
this is not a kitty issue it's happening with other terminal emulators too. I'm currently using hyprland with arch and have tried other emulators too. need to use a command for waybar. As kovidgoyal said this is something related to wl_cursors_theme. Vaxry have created a hypercusror trying to use it will let you know if it fixes this and if anyone found a solution Please let me know. |
That doesn't seem to be 100% accurate. From my understanding there are two parts to this issue.
More info: wayland spec: https://gitlab.freedesktop.org/wayland/wayland/-/blob/f3026c916ef91d78040913298170d5e538dd6618/protocol/wayland.xml#L1451-1455
wlroots only enforces the error on non-cursor surfaces: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/c63275d75e479bf39a104715423d1d6681c3163c/types/wlr_compositor.c#L215-L217, so the crashes on wlroots do not have anything to do with the cursor firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1795851 |
On Sat, Apr 20, 2024 at 03:20:25PM -0700, thejch wrote:
> I spent some more time looking into this and I think I have figured out the root cause. It's a bug/limitation in libwayland-cursor. https://gitlab.freedesktop.org/wayland/wayland/-/issues/194
>
> Basically, libwayland-cursor returns cursor sizes that can be larger than the size requested by the application, and that larger size may not be divisible by the scale. sway works around this bug by not enforcing the divisibility requirement. [swaywm/sway#6014](swaywm/sway#6014)
>
> So this needs to be fixed in either libwayland-cursor or in GNOME to not enforce the divisibility requirement.
That doesn't seem to be 100% accurate. From my understanding there are two parts to this issue.
1. For a cursor surface. this is not fixable from kitty's side because it's a libwayland-cursor limitation. As a workaround, wlroots does not enforce this requirement on cursor surfaces, and we will have to wait for libwayland to fix it.
2. For a non-cursor surface. There is no libwayland limitation that prevents this from being fixed. This is fixable from kitty's side and similar bugs have been fixed on many applications. Gnome mutter and wlroots do enforce this requirement, and this is still causing kitty to crash even to this day. So @kovidgoyal please do consider fixing this to comply to the wayland spec to prevent this error from crashing kitty.
There is no such bug in kitty. This ridiculous requirement in the
wayland spec was "complied with" a long time ago in kitty, by jumping
through elaborate hoops needed only on Wayland, the worst of all display
systems. Read the commit_window_surface_if_safe() function in kitty.
There is one remaining case where this can happen, which just
illustrates why this requirement is so ridiculous. That is when you move
a window so that it is on two monitors with different scales. The only
way to comply with this requirement then is to actually resize the
window while it is being moved. In other words, simply moving your
window around in wayland will cause it to be resized if the spec were to
be complied with fully. Absurd.
|
I'm getting this error message after upgrading to Fedora 40 because I'm using fractional scaling. A workaround for now is to set the display scale to 100% or 200%, open kitty, then go back to fractional scaling. This is fine for me because I keep my terminal open all day but going forward this really needs to be fixed in the wayland library. |
Make sure you are running kitty >= 0.34.0 which add support for fractional scaling. |
I'm on 0.34.1, unfortunately. Thanks for your work on this project, it looks like I'm stuck waiting for a fix for the time being. |
I tested kitty on GNOME, sway, KDE and hyprland with fractional scaling there were no issues. As I said the only remaining issue is if you move kitty window between two monitors with different scales. You can try running with --debug-rendering that should give a useful log. |
I'm afraid to say that, although I know positively that I've tried rebuilding, but it unfortunately persists:
It's totally possible I've overlooked something, but I can say for sure that if I adjust the two of my three screens that I usually use fractional scaling on such that they no longer do, Shortly after writing the above, when trying to re-enable fractional scaling, I happened to notice that I was able to continue using fractional scaling on my main monitor as long as the Built-in screen (screen 1 in the below screenshot) was not. Maybe that helps narrow down the problem? |
At one point I upgraded to a knew Fedora Silverblue version and the issue went away for me. Multiple monitors with different scales and fractional scaling on the main monitor and it works just fine now. |
Describe the bug
GNOME on Wayland is making trouble again. This time by sending invalid combinations of buffer size and scale factor.
To Reproduce
Steps to reproduce the behavior:
Then kitty crashes with an error like:
What seems to be going on on the GNOME side, is that the scaling factor is changed while half of the the window is still on the 100% scale monitor and the size is still the old one.
So far, I haven't found any other application that crashes this way.
Maybe it makes sense to ignore that protocol violation and just round the buffer size.
Environment details
OS: Fedora 36 with GNOME 42
kitty version 0.24.4
reproducible with
--config NONE
The text was updated successfully, but these errors were encountered: