feschber
[dev build] very fast mouse scroll speed on client
I just noticed this on the updated dev build today.
When I scroll with my mouse wheel, it tends to scroll way further than it used to on the client (i.e. the non primary computer).
I'm 96.7% sure that it wasn't this aggressive before - I would have noticed - I use this every day 👍🏻
Is this just a me thing?
Running: Debian Testing Hyprland
Was just looking through history - I'm assuming https://github.com/feschber/lan-mouse/pull/325 is now why I'm finding scrolling SUPER fast in Chrome.
This is one click of my scrollwheel back and forth:
On my host machine, it only moves slightly down the page smoothly.
Update:
I check wev on host vs client machine - and a scroll is the same value across both:
wl_pointer] axis: time: -212050813; axis: 0 (vertical), value: 15.000000
[ 15: wl_pointer] axis_source: 0 (wheel)
Yeah this is a regression in 39b79d88a5b05fd357d6397e795ed518d459309a. axis_descrete takes tiks, not value120
@selckin could you check, if setting axis_source is sufficient for your case? It should technically fix the scrolling regardless.
Without it and only axis_source it still only scrolls a tiny amount for me
lan-mouse
[ 15: wl_pointer] axis_source: 0 (wheel)
[ 15: wl_pointer] axis_value120: axis: 0 (vertical), value120: -1
[ 15: wl_pointer] axis_relative_direction: axis: 0 (vertical), direction: 0
[ 15: wl_pointer] axis: time: -142902005; axis: 0 (vertical), value: -20.000000
[ 15: wl_pointer] frame
real-mouse
[ 15: wl_pointer] axis_source: 0 (wheel)
[ 15: wl_pointer] axis_value120: axis: 0 (vertical), value120: 120
[ 15: wl_pointer] axis_relative_direction: axis: 0 (vertical), direction: 0
[ 15: wl_pointer] axis: time: 1454827716; axis: 0 (vertical), value: 15.000000
Do you have an axis_value120 event ? Maybe its capturing a wrong input value then?
I install hyprland on my the client & server, and did some testing: Server side niri or hyprland have same behavior Client being hyprland then chrome scrolls normally and the events also have 120 value: EDIT: ^ with my change/patch reverted
lan-mouse
[ 15: wl_pointer] axis: time: -138830402; axis: 0 (vertical), value: 20.000000
[ 15: wl_pointer] axis_source: 0 (wheel)
[ 15: wl_pointer] axis_relative_direction: axis: 0 (vertical), direction: 0
[ 15: wl_pointer] axis_value120: axis: 0 (vertical), value120: 120
real-mouse
[ 15: wl_pointer] axis: time: 279190; axis: 0 (vertical), value: 15.000000
[ 15: wl_pointer] axis_source: 0 (wheel)
[ 15: wl_pointer] axis_relative_direction: axis: 0 (vertical), direction: 0
[ 15: wl_pointer] axis_value120: axis: 0 (vertical), value120: 120
So difference in behavior between niri/smithay and hyprland, events also in different order not sure if that matters (yet)
With or without my change, hyprland+chrome scrolls the same amount in my tests
I'll try and investigating it in more in details when I have time and look at what smithay and hyprland do; if you want to revert it till then that makes sense.
Appreciate y'all looking into this!
Bit busy at the moment, but happy to run tests or provide whatever information I can on my end in the next couple of days if needed or wanted.
@selckin you are using niri on both sides, right? I think I will do a partial revert for now and test this myself.
@selckin you are using niri on both sides, right? I think I will do a partial revert for now and test this myself.
yes
Alright, I'm pretty sure this is a niri bug: https://github.com/YaLTeR/niri/blob/e6f3c538da0c646bda43fcde7ef7dc3b771e0c8b/src/protocols/virtual_pointer.rs#L522
they are directly using the discrete (=steps) value here as the v120. This should be multiplied by 120. I'm going to open a PR.
Thank you very much for looking into this, can confirm that everything works for me with the niri patch applied