Scrolling too fast in Wayland

[hgaiser]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

Gnome

WezTerm version

20230217-120342-3b39aa55

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Scrolling under Wayland is significantly faster than scrolling on X11. Presumably this is because of differences between libinput and xf86-input-libinput. A full scroll from top to bottom on my laptops touchpad results in roughly 300 lines scrolling on Wayland, while it scrolls 70 lines on X11.

To Reproduce

Scroll in Wayland and compare it to X11.

Configuration

no config

Expected Behavior

No response

Logs

No response

Anything else?

No response

[snaggen]

Just did a comparison with VTE based Tilix and my mouse scroll wheel which have discrete scroll ticks. Under tilix one tick scroll 3 lines. Under Wezterm one tick scroll 10 lines. This is under Fedora Gnome using Wayland. I have not tested this under X11.

I actually like the more aggressive scroll. However, it might be a trackpad under Wayland thing, so my comparison is irrelevant. Just thought I point out this for information.

[hgaiser]

10 lines per tick seems like quite a lot, I'll test today what I'm getting with a scroll wheel. I've used tilix before as well, I thought it didn't scroll discrete lines?

I should've mentioned that the lines scrolled per tick on my touchpad seem the same in Wayland vs X11, but the distance traveled on my touchpad between ticks feels different. On Wayland I need to move my fingers significantly less before a scroll event is triggered.

Maybe I'll see if I can measure how many ticks are generated when moving from top to bottom in both Wayland and X11.

[hgaiser]

I added a log statement here to test a few things, these are my results:

1. On X11, every scroll event scrolls for exactly 5 lines, whether it's a scroll wheel or touchpad event doesn't matter. Scrolling over the entire vertical space of my touchpad generated 25 ticks, so 125 lines were scrolled.
2. On Wayland:
   1. Scroll wheel ticks scroll for exactly 10 lines.
   2. Touchpad works a bit differently, it depends on how much space has been traveled since the last event. I scrolled slowly during my tests so that most events triggered 1 line scrolling. In total there were 378 events triggered over the entire vertical space of my touchpad, so roughly 378 lines were scrolled. This lines up (pun intended) with what I've been experiencing, which is that I scroll roughly 3x as fast in Wayland compared to X11.

[nbenitez]

It seems font-size dependent. My current font-size is 10.0 and one tick is 20 lines

For testing I changed to 14.0 size and one tick was one full page.

I'm using default font in wezterm, my system is Fedora 36 - GNOME - Wayland session.

The 3 lines for a tick in gnome-terminal it's easier in the eyes to follow. I changed to a bigger font-size in gnome-terminal and it kept scrolling by 3 lines, which seems right.

[nbenitez]

I could recreate gnome-terminal scrolling i.e. scrolling 3 lines per wheel tick (both up and down) with the following config code in my .wezterm.lua file:

local act = wezterm.action
config.mouse_bindings = {
  {
    event = { Down = { streak = 1, button = { WheelUp = 1 } } },
    mods = 'NONE',
    action = act.ScrollByLine(-3),
  },
  {
    event = { Down = { streak = 1, button = { WheelDown = 1 } } },
    mods = 'NONE',
    action = act.ScrollByLine(3),
  },
}

So this is no longer a problem for me as I could change it in config, but in my opinion the above should be the default in wezterm.

Thanks to Wez for such an awesome terminal app and for providing so much configurability. 👌🏻

[duament]

Same issue on hyprland. While @nbenitez 's workaround works for my mouse, it doesn't help my touchpad.

Found some related code below. It multiplies the value of an axis event by the screen scale factor.

https://github.com/wez/wezterm/blob/69ae847273aa2b0a64bdb07cf19d3f6fbaaa6b71/window/src/os/wayland/pointer.rs#L193-L202 https://github.com/wez/wezterm/blob/69ae847273aa2b0a64bdb07cf19d3f6fbaaa6b71/window/src/os/wayland/window.rs#L545-L565

In my case, wev reports one axis event with value 15.000000 per wheel tick. And my scale factor is 2. These results in scrolling 30 lines per tick. It's insane.

I didn't figure out what the value of an axis event stands for. Should wezterm divide that value by some factor?

[colemickens]

I haven't had a chance to investigate much, but it seems like throwing a mulitplexer like zellij into the mix changes things as well.

[hexchain]

The workaround from @nbenitez works well, except that it breaks scrolling in alt screens (e.g. vim, less, etc.).

The fix is fortunately easy: just add alt_screen = false to both bindings (docs).

[ZerdoX-x]

Wait.. There is no way to configure scrolling sensitivity? I am also using touchpad and I cannot see any way to configure scrolling multiplier.

[PeterPasdzierny]

Wait.. There is no way to configure scrolling sensitivity? I am also using touchpad and I cannot see any way to configure scrolling multiplier.

I second that question!

[brainlessbitch]

Wait.. There is no way to configure scrolling sensitivity? I am also using touchpad and I cannot see any way to configure scrolling multiplier.

I second that question!

I third this!!!

[ZerdoX-x]

@PeterPasdzierny @exoess and future commentators, please, stop it. People getting emails and github notifications for each message in threads they subscribed to. This relates to all threads you participate in, especially in non-github conversations. Just use reactions or provide any other extra useful information to move this thread forward.

[brainlessbitch]

i do actually have some info, i did some testing, i tried changing the scroll factor in hyprland, but it didn't change wezterm's scroll factor, it seems like wezterm is overriding the scroll factor (not sure if this is already known or just not useful)

p.s. sorry, i've never been bothered by it nor known anyone who was annoyed, i was just trying to indicate this is an important issue, sorry tho

[SuperSandro2000]

the following patch feels a lot better and is based on above comments

diff --git a/window/src/os/wayland/window.rs b/window/src/os/wayland/window.rs
index 7b375b615..b9ab06a43 100644
--- a/window/src/os/wayland/window.rs
+++ b/window/src/os/wayland/window.rs
@@ -557,7 +557,7 @@ pub(crate) fn dispatch_pending_mouse(&mut self) {
         }

         if let Some((value_x, value_y)) = PendingMouse::scroll(&pending_mouse) {
-            let factor = self.get_dpi_factor() as f64;
+            let factor = self.get_dpi_factor() as f64 / 2f64;

             if value_x.signum() != self.hscroll_remainder.signum() {
                 // reset accumulator when changing scroll direction

[brainlessbitch]

@SuperSandro2000, are you going to make a pr?

[SuperSandro2000]

I mean I could do that but to be honest dividing by 2 was just a guess in the blue and I really don't know if that is good fix or just a quick and dirty workaround.

[brainlessbitch]

i mean, is there a way to get the scale factor in wayland, cause you'd just wanna divide by that, i think. idk, just needing to reapply a patch every time there's an update seems annoying

[hgaiser]

I created a commit a while ago to introduce a scroll factor into the config. I've used it for a while but honestly due to other Wayland issues at the time I reverted back to x11.

Though if @nbenitez 's option works, I'd advise that one for now until something official is implemented.

[SuperSandro2000]

just needing to reapply a patch every time there's an update seems annoying

Doesn't really concern me on NixOS as long as the patch applies 😅

[mike-lloyd03]

I've opened a PR for this taking inspiration from @SuperSandro2000's patch above and adding a new config option for setting the scroll factor.