Kinetic scrolling buggy on trackpads (vouch request)

[viruslobster]

What do you want to change?

Hey, I'm a big Zig fan and I think I have something small but impactful for Ghostty linux users.

I have an issue with scrolling on my thinkpad trackpad running Fedora 42 where after I release the trackpad scrolling actually accelerates and blows by the logs I wanted to read. You can see some discussion at the end of 7284 about this.

I'm pretty sure the issue is GTK kinetic scrolling, which I was able to disable with this: main...viruslobster:ghostty:disable-trackpad-kinetic-scroll

Opus 4.5 generated that code, I don't know much about GTK. I really tried to get it to edit surface-scrolled-window.blp instead but it looks like you can only disable kinetic scrolling for touchscreens with a blueprint, not trackpads. Its only a handful of lines though.

Why do you want to make this change?

The current scrolling behavior makes the terminal pretty difficult to use. I don't think anyone would want this behavior and I'm guessing most don't see it because they are using ghostty on macos (which doesn't use GTK, right?).

I acknowledge that:

• I have read the Contributing Guide and understand the contribution process.
• I have read and agree to follow the AI Usage Policy.
• I wrote this vouch request myself, in my own voice, without AI generating it.

[rhodes-b]

Im fairly certain I dont have this issue on my laptop but ill have to verify later tonight

[viruslobster]

So I'm 100% sure that setting that kinetic flag to false fixes scrolling for me. @T3sT3ro if it doesn't fix it for you though, then it's back to the drawing board. Have you tried building my branch?

Disabling the controller would technically fix the problem, but that also just breaks your ability to use the scrollbar with a mouse.

[T3sT3ro]

For now I have only launched the terminal with that flag without rebuilding, do you think there will be any difference if I rebuild it vs if I only disable it on live app? I have checked and other flags and properties affect the window as usual, so it looks like it should have effect.

Also regarding the kinetic scrolling making me dubious --- IIRC it is some system level setting, so it would be probably different to disable it only for a single component/app?

[viruslobster]

@T3sT3ro Building the source would just guarantee that we're disabling the flag on the same controller. There are a bunch of different GtkScrolledWindows with event controllers in that debug UI and I only see the improvement if I disable the flag on the right one.

[viruslobster]

Ha! I might have figured out why we're seeing different behavior.

TL;DR There's a scrolling change to the dynamically linked libgtk of which I've got an older version.

❯ pkg-config --modversion gtk4
4.18.6

If I'm right folks who can't repro are on 4.20.1 or newer.

Longer version:
GtkEventControllerScroll emits a decelerate signal on scroll end if the kinetic flag is enabled (1, 2). I can verify this by connecting a callback to the decelerate signal in Ghostty:

+            _ = gtk.EventControllerScroll.signals.decelerate.connect(
+                controller,
+                *Self,
+                onDecelerate,
+                self,
+                .{},
+            );

+    fn onDecelerate(
+        _: *gtk.EventControllerScroll,
+        vel_x: f64,
+        vel_y: f64,
+        self: *Self,
+    ) callconv(.c) void {
+        _ = self;
+        log.debug("decelerate: vel_x={}, vel_y={}", .{ vel_x, vel_y });
+    }
+

And indeed I see these two logs the moment I lift my fingers from the trackpad:

debug(gtk_ghostty_surface_scrolled_window): decelerate: vel_x=0, vel_y=12.772853185602447
debug(gtk_ghostty_surface_scrolled_window): decelerate: vel_x=0, vel_y=0

but emitting this signal alone doesn't actually scroll anything. Something has to connect to the signal and take action. GtkScrolledWindow creates a GtkEventControllerScroll with the kinetic flag enabled and connects a callback for the decelerate signal.

Inside the decelerate callback, notice this early return. If that trips, no extra scrolling happens. Otherwise gtk_scrolled_window_decelerate gets called which ultimately scrolls extra according to the given velocities. This was added in 96c1b3ae4f scrolledwindow: Improve behavior if nested in other scrollables. 4.20.1 is the first versioned release with this commit.

I added logs to the gtk source, built it, and linked Ghostty against my custom version. When I have the early return, I see good scrolling behavior and the logs:

info(glib): MESSAGE: Gtk: scroll_controller_decelerate: received signal vel_x=0.000000 vel_y=-51.369231
info(glib): MESSAGE: Gtk: scroll_controller_decelerate: exiting early
debug(gtk_ghostty_surface_scrolled_window): decelerate: vel_x=0, vel_y=-51.36923076923733
debug(gtk_ghostty_surface_scrolled_window): decelerate: vel_x=0, vel_y=0

When I remove the early return, I see the bad scrolling behavior and the logs:

info(glib): MESSAGE: Gtk: scroll_controller_decelerate: received signal vel_x=0.000000 vel_y=28.302188
info(glib): MESSAGE: Gtk: scroll_controller_decelerate: calling gtk_scrolled_window_decelerate
debug(gtk_ghostty_surface_scrolled_window): decelerate: vel_x=0, vel_y=28.302188054418668
debug(gtk_ghostty_surface_scrolled_window): decelerate: vel_x=0, vel_y=0

So you can fix the bad scrolling behavior either by disabling the decelerate signal or by having the newer libgtk which ignores the decelerate signal under certain conditions. Since Ghostty can't control the version of libgtk that's dynamically linked and since 96c1b3ae4f might have fixed this specific issue on accident (the commit is about improving nested scrolled containers...which is not what Ghostty is doing, right?) I think we should just disable the controller from creating the signal in the first place. Ghostty can control that setting, what do you think?

[pluiedev]

That's iiiinteresting — I'm indeed using 4.20.3. I think we can add a version-gated workaround then (there's already checks all over that set certain flags only on specific GTK versions) — feel free to make a PR :)

[viruslobster]

@pluiedev Thanks! I have a PR ready, but I don't see myself in the vouch list. I have to be in there or I'll be autorejected, right?

[00-kat]

!vouch

[00-kat]

There, you should be able to open a PR now.

[mitchellh]

Moving this to issue triage.