Mouse wheel events not working when cursor is moving

[zareami10]

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)

[sezanzeb]

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

[sezanzeb]

I can't reproduce the issue on my end

[zareami10]

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.

[sezanzeb]

a minus sign in libinput debug.

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

[sezanzeb]

The issue seems to happen even with evdev

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

[zareami10]

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.

[sezanzeb]

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.

[rszyma]

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]

so the events are not dropped/missed

[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.

[zareami10]

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

[rszyma]

It worked for me too, thanks.