High resolution scrolling with regards to keybinds

Bugs / FRs / Support
, ,
1
Hyprland version 
Hyprland 0.50.0 built from branch makepkg at commit fdbbad04bbf2382e9a980418c976668fc062f195  (core: enter unsafe state on boot if there are no mons).
Date: Tue Jul 22 09:14:12 2025
Tag: v0.50.0-26-gfdbbad04b, commits: 6305
built against:
 aquamarine 0.9.1
 hyprlang 0.6.3
 hyprutils 0.8.1
 hyprcursor 0.1.12
 hyprgraphics 0.1.4


no flags were set

I have a mouse that uses high-resolution scrolling (Logitech MX Master 3S), and I use the following binds (the dispatcher is from a plugin, doesn’t really matter):

bind = $mainMod, mouse_up, split-cycleworkspacesnowrap, next
bind = $mainMod, mouse_down, split-cycleworkspacesnowrap, prev

When I use a mouse that doesn’t have high-resolution scrolling, this works as expected, one detent per workspace. But when I use one with it, it jumps like 4-5 workspaces at a time. I’ve tried using input::emulate_discrete_scroll 0, 1, and 2, but it doesn’t seem to have any effect on this.

2

try setting the timeout with scroll_event_delay

3

the problem with that is if I scroll to fast (I have pretty good muscle memory by this point, this worked flawlessly in GNOME) it will completely lock up, and if I set it low enough that it doesn’t do that, the problem shows up again. Even if it didn’t lock up and released another input after the timeout, it would still not match workspaces scrolled vs number of detents on the mouse. I don’t think that’s a real solution, especially that I’ve seen it done correctly in other compositors.

4

hm, it shouldn’t lock up. That sounds like a bug

5

Just looked at the code, and input:emulate_discrete_scroll happens after the keybind has already been processed by the keybind manager. It would be nice if we had binds:emulate_discrete_scroll as well; this would fix it pretty much perfectly from what I can see (I like the way it’s implemented).

I added a log in CKeybindManager::onAxisEvent and got

[LOG] Axis event: delta: 9, deltaDiscrete: 0
[LOG] Axis event: delta: 2, deltaDiscrete: 0
[LOG] Axis event: delta: 2, deltaDiscrete: 0
[LOG] Axis event: delta: 2, deltaDiscrete: 0

Currently, this counts as 4 inputs, but the total is 15, so it should only count as one. Sometimes I do get a total of 14 or 16, so I think the way it’s done in input manager is good, trigger on first input for responsiveness, and reset after a timeout. A separate one for keybinds would be great because it makes sense to have it work in apps that support it, but it doesn’t make sense for keybinds

As for why the scroll_event_delay locks up, you’re resetting the timer on every event, so it never expires if you continue scrolling. Not sure what the intended behaviour is but that’s what’s causing it.

6

I know why it locks up, but it’s a bug.

7

I’ve committed a patch that should fix the infinite lockups

1 Like