GNOME Bugzilla – Bug 753431
Scroll events from wireless mouse are ignored
Last modified: 2015-09-09 14:59:11 UTC
Created attachment 308996 [details] evemu recording of event15 So I have a HP wireless mouse connected (the kind that has its own tiny USB dongle) and I can't scroll with it. Well I sort of can – the scroll wheel works in gedit and gnome-terminal – but it is completely ineffective in nautilus and gtk3-demo. Meanwhile, my laptop touchpad and my _other_ mouse (a regular wired USB mouse) scroll the same areas just fine. Perhaps it's because the wireless dongle also (apparently) claims to have touchpad & keyboard capabilities, according to `libinput-list-devices`? Also this only happens with X11; everything's fine under Wayland. gtk 3.17.6-15-gb9bced6 (git master)
That might be the case, I see the libinput x11 driver just attaches all capabilities to the same internal device. I'm still a bit puzzled as to why it works on selected places, do we maybe just get 4-7 button events on scroll? Could you attach similar output from xinput test-xi2 (after scrolling a bit above the displayed window)?
Created attachment 309458 [details] "xinput test-xi2" recording of the mouse
Created attachment 309460 [details] full device list I should clarify that are *two* device nodes for the same USB dongle – one shows up as an actual keyboard, the other as as mouse "with keyboard capabilities". A bit weird.
(In reply to Mantas Mikulėnas from comment #3) > Created attachment 309460 [details] > full device list > > I should clarify that are *two* device nodes for the same USB dongle – one > shows up as an actual keyboard, the other as as mouse "with keyboard > capabilities". A bit weird. Yeah that's not totally uncommon, the multimedia keys usually come from the pointer device node on those wireless keyboard/mouse sets. Hmm, although seeing the xi2-test output, I see you get crossing events on every button press. Is this mutter/gnome-shell? with extensions? some other wm? I feel this is one more bug in the saga of: https://bugzilla.gnome.org/show_bug.cgi?id=750870#c3 https://bugzilla.gnome.org/show_bug.cgi?id=750994 Although it completely puzzles me if the wired mouse just works on the same wm/circumstances.
Yes, that's gnome-shell 3.17.4+master, on Xorg 1.17.2, no special configuration nor exts. (I'll try on Openbox just in case...)
Created attachment 309470 [details] "xinput test-xi2", both mice For comparison, I got the wired mouse again. First is the wired mouse scrolling (and being unplugged), next is the wireless mouse scrolling.
Created attachment 309943 [details] xinput-list-devices
Oops my commetn got deleted. So that happens to me aswell with a bluethooth thinkpad keyboard with emulated wheel for the trackpoint. Events are reported correctly doing xinput test on it. The events are the same as with a mice that works perfectly. With the keyboard firefox, chrome, and a VM with f22 works perfectly, but gtk3 apps in the system (f23) doesn't work.
works on wayland
I've seen more reports of scroll wheels not working, so putting this on the blocker list
yeah same issue for me: bluetooth mouse scroll doesn't work with gnome-terminal, nautilus, other gtk3 apps (though it works in kde + firefox), but switching to a wired mouse works fine.
*** Bug 754639 has been marked as a duplicate of this bug. ***
In regard to Bug 754639, I have described that scrolling with touchpad doesn't work. I have to contradict that: It does work, I did a scrolling with touchpad wrong (different area used by libinput I guess). I also have a wireless mouse and keyboard that use an usb dongle as a receiver, and it doesn't work when scrolling with it.
Created attachment 310997 [details] [review] x11: Declare variable for the inner loop Otherwise the outer loop control variable is messed up, and we end up with uninitialized axes if there were any more valuators after the XIKeyClass one. This bug was sneakily introduced by fdb9a8e14, many thanks to Carlos Soriano for helping spot the source of this bug.
Attachment 310997 [details] pushed as dbf85cc - x11: Declare variable for the inner loop
This is now fixed in master, it turned out that, for those pointer devices with "key" capabilities (most mouse+keyboard sets falling there, as pointed out in comment #4) the initialization of scroll axes was broken, which made GDK ignore any changes in those. Other mice with no "key" capabilities were unaffected.