input-remapper icon indicating copy to clipboard operation
input-remapper copied to clipboard

Mouse wheel events not working when cursor is moving

Open zareami10 opened this issue 3 years ago • 7 comments

So if I set up keyboard keys to do scrolling, the scrolling events will be blocked (maybe by libinput?) if the mouse cursor is moving. (this issue doesn't happen with some apps like Firefox)

zareami10 avatar Feb 03 '22 13:02 zareami10

Firefox is written with GTK, does it work in all other GTK applications as well? for example gedit.

sezanzeb avatar Feb 03 '22 14:02 sezanzeb

I can't reproduce the issue on my end

sezanzeb avatar Feb 03 '22 14:02 sezanzeb

Firefox is written with GTK, does it work in all other GTK applications as well? for example gedit.

No, Nautilus for example has the problem. But shell overview also works fine. The issue seems to happen even with evdev. The only thing I have noticed is that the missed events are preceded with a minus sign in libinput debug.

zareami10 avatar Feb 03 '22 14:02 zareami10

a minus sign in libinput debug.

can you please show where you see this? I haven't heard of libinput debug before

sezanzeb avatar Feb 03 '22 14:02 sezanzeb

The issue seems to happen even with evdev

what does that mean. That you are not seeing the scroll events in evtest?

sezanzeb avatar Feb 03 '22 14:02 sezanzeb

a minus sign in libinput debug.

can you please show where you see this? I haven't heard of libinput debug before

Sure. You just have to run libinput debug-events with root privileges. Then you can see all the events such as POINTER_SCROLL_WHEEL, etcetera.

The issue seems to happen even with evdev

what does that mean. That you are not seeing the scroll events in evtest?

Well by default the input driver used (e.g. as shown in /var/log/Xorg.0.log) is libinput, so I removed that to test with evdev instead. Which made no difference.

zareami10 avatar Feb 03 '22 14:02 zareami10

Thanks.

Expected behavior in sudo evtest would be, that input-remapper mouse injects the mapped wheel events, while your mouse keeps injecting REL_X and REL_Y events.

Since it works in Firefox, the written events most likely are correct. Based on previous incidents of problems of this kind, this is pretty much out of reach for me. The only hope is waiting for someone who knows gnome/libinput/x11/wayland etc. internals who can reproduce the problem and has the time to fix it.

sezanzeb avatar Feb 03 '22 15:02 sezanzeb

I'm also having the same issue.

The only thing I have noticed is that the missed events are preceded with a minus sign in libinput debug.

I couldn't find a documentation on output of libinput debug-events command, but just from messing around I'm pretty sure that the - at the start of the line means that the event source device differs from the one logged in previous line. For example:

 event2   KEYBOARD_KEY            +1035.142s	KEY_LEFTMETA (125) pressed
 event2   KEYBOARD_KEY            +1035.222s	*** (-1) pressed
 event2   KEYBOARD_KEY            +1035.287s	KEY_LEFTMETA (125) released
 event2   KEYBOARD_KEY            +1035.291s	*** (-1) released
-event6   POINTER_MOTION          +1035.511s	 -6.45/ 18.34 (-19.00/+54.00)
 event6   POINTER_MOTION          +1035.525s	 -8.82/ 23.65 (-25.00/+67.00)
 event6   POINTER_MOTION          +1035.533s	 -9.55/ 28.17 (-20.00/+59.00)

rszyma avatar Sep 16 '22 23:09 rszyma

so the events are not dropped/missed

rszyma avatar Sep 16 '22 23:09 rszyma

Or are they? I changed the macro from wheel(down, 30) to event(EV_REL, REL_WHEEL, -1) in order to generate only one event on macro trigger. Turns out every time mouse moves, the next wheel event gets ignored. Further wheel triggers work normally, until I move the mouse again.

rszyma avatar Sep 16 '22 23:09 rszyma

@nutel65 A solution I found was simply installing and running imwheel. No idea why it works though.

zareami10 avatar Sep 17 '22 09:09 zareami10

It worked for me too, thanks.

rszyma avatar Sep 17 '22 11:09 rszyma