There are common mouses such as logitech g400s and microsoft io1.1 which use an sensitive optical scroll wheel. In a browser, clicking middle click tends to cause unintended scroll wheel movement which is most severe after the switch bottoms out, often missing the pointer target on the monitor. I tested a macro on my mouse to disable the scroll wheel by mouse3 and it greatly minimises the issue. It does not cripple any UI features either as 99 per cent of mouse wheels are fully recessed, so no software has been created to utilise both wheel rotation and mouse3 simultaneously as to do so would require two fingers to both hold and rotate the wheel in a tedious manner. I am aware of one touch scrolling which uses middle click to create emulated scrolls, however I only want libinput to ignore hardware wheel scrolls for the short duration of the middle click hold. Therefore it will not interfere with any laptop touchpad, or stick. I would like for this feature to be included as default as due to its inoffensive and unconscious nature it will be easily ignored.
Can you post an example evemu-record of a sequence that's gone wrong? Like how many inadvertant clicks do you use usually get? Do you get the clicks before/after the wheel triggers the actual button? This is a tricky one for libinput because we don't have any user feedback and making this configurable is a bit pointless. Having it as a hw-specific quirk is easy enough but it will prevent wheel scrolling with the middle button down. Which means we'll likely need some extra heuristics like a threshold when we start scrolling. That again is hard to discover and likely to upset people.
I don't get any inadvertent button clicks, my switches are not faulty, but the log shows the issue. I get wheel movement all the time but since it is so small it is not an issue for me, I can easily compensate with a light touch. in the log you can see rel_wheel goes to 1 after my finger clicks forward. The erratic wheel only becomes an issue when middle clicking. I don't want to affect other users by adding a scrolling threshold, I only want to prevent wheel scrolling when it won't matter to anyone. >>Which means we'll likely need some extra heuristics like a threshold when we start scrolling. That again is hard to discover and likely to upset people. I don't want code of dubious value to filter based on wheel acceleration because I don't need it, and it would just annoy me. It won't upset them because nobody uses wheelscrolls while they hold middle click. saying it would upset them is like saying debouncing is unfaithful to the rustic character of intermittent switches. E: 125.849350 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 126.478355 0004 0004 589827 # EV_MSC / MSC_SCAN 589827 E: 126.478355 0001 0112 0001 # EV_KEY / BTN_MIDDLE 1 E: 126.478355 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 126.500339 0002 0008 0001 # EV_REL / REL_WHEEL 1 E: 126.500339 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 127.071345 0004 0004 589827 # EV_MSC / MSC_SCAN 589827 E: 127.071345 0001 0112 0000 # EV_KEY / BTN_MIDDLE 0 E: 127.071345 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 127.296342 0002 0008 -001 # EV_REL / REL_WHEEL -1 E: 127.296342 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- and another E: 117.928388 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 117.955390 0002 0001 0001 # EV_REL / REL_Y 1 E: 117.955390 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 118.654404 0004 0004 589827 # EV_MSC / MSC_SCAN 589827 E: 118.654404 0001 0112 0001 # EV_KEY / BTN_MIDDLE 1 E: 118.654404 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 118.692373 0002 0001 0001 # EV_REL / REL_Y 1 E: 118.692373 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 118.864398 0002 0008 0001 # EV_REL / REL_WHEEL 1 E: 118.864398 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 119.314392 0002 0001 0001 # EV_REL / REL_Y 1 E: 119.314392 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 119.325374 0002 0001 0001 # EV_REL / REL_Y 1 E: 119.325374 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 119.355388 0004 0004 589827 # EV_MSC / MSC_SCAN 589827 E: 119.355388 0001 0112 0000 # EV_KEY / BTN_MIDDLE 0 E: 119.355388 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 119.366368 0002 0001 0001 # EV_REL / REL_Y
> I don't want code of dubious value to filter based on wheel acceleration because I don't need it, and it would just annoy me. Yeah, but libinput isn't a project just for you, it's in use by virtually every Wayland compositor and most modern xorg installations. So let's take a step back and consider what could work for everyone. > nobody uses wheelscrolls while they hold middle click. let's not have "nobody" or "everybody" arguments, because I'm the one who has to deal with that when the assumed nobodys are shouting at me in a year's time because something breaks. > which is most severe after the switch bottoms out Do you ever get wheel events before the BTN_MIDDLE click? I think the G400 is a programmable mouse but I don't know its features off-hand, did you change the wheel resolution at some point? Is the MOUSE_WHEEL_CLICK_ANGLE or MOUSE_WHEEL_CLICK_COUNT udev property set on the device? Because that could be something we could hook onto. The second recording indicates that the wheel events can happen 200ms after the click event which is about as close to "any time" as we can get. So a timeout after the click isn't suitable here.
>Yeah, but libinput isn't a project just for you Of course not, but any code added is contingent on the bug I submitted. Therefore I am obligated to express my wishes explicitly. Responding in a passive manner is unconstructive. >let's not have "nobody" or "everybody" arguments Fair enough, I completely understand. The 3 button modern mouse is surprisingly standardised however. It's possible that someone could remap middle click and become frustrated by the mouse's disabled wheel. One way to deal with complaints would be to have the feature as an option, then if no complaints are made after the dust settles have it as default. Do you ever get wheel events before the BTN_MIDDLE click? I do as I have removed the wheel detent to lessen rsi. It's a common failure point though and happens to many similar models without intervention. the g502 has built in code to ignore wheel events when moving very slowly, which works well. As I said, I find any motion to be easily compensated and any trade offs of a sensitive wheel are worth it to me for the increased responsiveness. It's only when I attempt to perform an action that difficulty results. I rise my finger to the 12 o clock wheel position before clicking, this prevents wheel events prior to the click. I bought the g400s used so I do not know if the wheel had been software modified. I doubt it supports such a mod as I attempted to remap dpi buttons and it kept reverting to default. I don't know how to check the udev property. In any event mouse specific fixes are beating around the bush. The mouse I am currently using is an io1.1 shell with a teensy 2.0 replacing the mcu. I modified the source to disable the wheel from mouse3, that was how I tested the proposal.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/libinput/libinput/issues/19.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.