Open hgaiser opened 1 year ago
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.
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.
I added a log statement here to test a few things, these are my results:
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.
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. 👌🏻
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?
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.
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).
Wait.. There is no way to configure scrolling sensitivity? I am also using touchpad and I cannot see any way to configure scrolling multiplier.
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!
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!!!
@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.
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
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
@SuperSandro2000, are you going to make a pr?
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.
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
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 😅
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.
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
andxf86-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