[Scroll Wheel] Emulate discrete scrolling from v120 events #6881
Conversation
|
will this work with 6608? |
Agent00Ming
force-pushed
the
hires-discrete-emulation
branch
from
5c33a33
to
61cfecd
Compare
|
It should, I originally wrote it and tested on aq branch and it worked fine, but since the logic can be entirely contained in hyprland source, I backported the patches to main. |
Agent00Ming
force-pushed
the
hires-discrete-emulation
branch
3 times, most recently
from
31d2f63
to
4ccbb4d
Compare
|
@Ciel-MC for insanely high res mouse. @CNR0706 @noahfraiture for bug reports. |
|
Hi, just did some testing on the branch, in xwayland(minecraft tested, latest and 1.7), the scrolling seems roughly 5x too fast, if I set the scrolling sense to 0.2 on 1.20, it would almost always scroll 1 slot in the hotbar for every physical stepped scroll on the mouse, but it's still not perfect as if you scroll a few times, it will jump by two every now and then, and on 1.7 which does not have scrolling sensitivity, it currently mostly scrolls by 5 slots, but sometimes 6 and rarely 4, this behavior is consistent between a G502(standard 15deg hires) and a MX Master 3s (1deg hires). |
|
What happens when you tweak the Hyprland |
How do you want me to tweak it? I'll put on the patch now |
|
try changing the scroll factor to |
|
I was wondering why the patch wouldn't apply when I noticed I didn't switch branch yet, so I'm just using some past version of the main branch .-. I'll actually try the branch now Well, the patch failed anyway cause there was a stray comment XD no worries I applied it manually |
Alright actually tried out the patch, the G502 is very close to perfect, with it single scrolling most of the time, and only double scrolling every ~6/7 times, here's the logs for that The MX Master 3s though, is actually a big downgrade from main, with the scroll wheel being extremely fast on both regular desktop usage and in game, here are two figure to show the problem Given the differences, I don't think there is a need to test the scrolling scale factor, so that is not tested. |
If I go to the most recent main, where the mx master 3s' scroll behaves correctly, I get ~80k px/s peak, which is almost spot on for a 15x at 1.2mil projected pixels, so I think we've found the suspect. |
|
mx3s log looks weird... try setting |
As expected, 0 does very well, expect being ~5x faster in game, while 2 is completely borked with the scrolling speed everywhere Also yeah I don't think it takes a dev to notice something is not quite right for a single scroll, lol that entire log are two separate scrolls only, separated by an empty line |
|
also, can you get a |
Interesting... it would seem like how Hyprland works under under |
|
and what does |
|
Oh and, if it provides you any closure, if I just delete the factor of 15 on that line, the wheel appears to work in regular app,s but is still utterly broken in Minecraft, which you can either take at a good thing because half of the issue is solved, or as a bad thing because I have never had only minecraft be extremely fast(even previous |
This is a single step on |
Oh and yes, that does cripple the G502's scrolling speed, suggesting that this multiplier needs to change per device |
|
it honestly looks like the WHEEL_HI_RES values are off by a factor of 120 (should be divided by 120), try tinkering around with the hwdb overrides. I'm assuming you put the 360 click count because it should have that precision but it's being interpreted as 360 discrete events for a full rotation instead of the 360 degrees of high-res events. the reason it "works" with |
Did a bit more further digging, it does seem like it would be a libinput issue, still not certain though. Anyway, now the only issue is the occasional double scroll on the g502 |
|
Seems to work perfectly on default settings with G502, G502 LS and G502 X Plus. Horizontal scroll works fine too. |
are you sure it's not because of slightly ticking the wheel in the opposite direction when you are scrolling? it doesn't seem like it's a rounding error because I only deal with integers inside of the accumulator I managed to repro it once here but it's not really consistent |
I don't think so, it's overscrolling which I'm not sure how any accident can cause that? Maybe it's too sensitive to events? But even if I scroll very steadily I may get 2 steps
I reported to libinput and they informed me that it is the fault of the kernel, and I checked and indeed my specific Master 3s is not supported, so I am recompiling the linux with a patch now and see how it goes |
|
I mean, with |
Agent00Ming
force-pushed
the
hires-discrete-emulation
branch
from
4ccbb4d
to
3fa01f0
Compare
|
There technically is a possible rounding error in the interval * scroll factor but it's so insignificant that you'd have to scroll continuously for a while to get a single 'unintentional' double scroll. It's fixable by switching the scroll factor to affect the discrete value instead of the interval and then clamping/rounding that to clean divisors of 120 but that's more work for something that you won't even notice for 99.9999% of the time (source: I made it up). An interesting interaction of The seat change is to mitigate a bug with some apps thinking that an empty axis event with axis_stop() is from a touchpad or something (why do they not look at the axis source?) and doing the momentum scrolling thing... We still send the 'empty' event because v120 is still attempted to be sent in case the application supports it. The ceil/floor rounding was changed back to normal rounding if the absolute value is more than 1 because turning 1.25 discrete into 2 is a bit jarring. If it is less than 1 (but not 0) then it's clamped to 1 to avoid rounding 0.49 discrete to 0 (buggy behaviour and breaks scrolling entirely in some apps). |
* seat: avoid sending axis_stop() when source is wheel * fix rounding for absolute discrete values greater than 1
Agent00Ming
force-pushed
the
hires-discrete-emulation
branch
from
3fa01f0
to
8b63066
Compare
|
This should be ready for review. @vaxerski |
|
I agree, outside of games, as Ive been screwing around with the kernel to try and get my shit fixed, the system seems pretty stable, so Id say it’s good to go |
|
I'm using a G502 with hyprland 0.43.0-1 and I still get frequent double scrolls and the scroll just generally not being in sync with the mouse wheel. Is there a new issue tracking this? |
Describe your PR, what does it fix/add?
Fixes #6681. Adds an accurate emulation of discrete scrolling when given scroll wheel events that are fractions of 120. It is configurable to be force enabled (
2) / disabled (0) but it defaults to automatic detection (input:emulate_discrete_scroll1)Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
No clue how this will interact with horizontal scroll wheels because I don't have a mouse that can do that. Should not affect normal, non-highres, scroll wheel behaviour.
Is it ready for merging, or does it need work?
Needs some more testing and could use some touch-ups. Tested with an old wireless mouse that does scrolling in multiples of 30 degrees and a normal wired mouse.