| Summary: | Scrolling problems due to Logitech mouse also presenting as keyboard | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Ambroz Bizjak <ambrop7> | ||||||
| Component: | Input/evdev | Assignee: | Peter Hutterer <peter.hutterer> | ||||||
| Status: | RESOLVED WONTFIX | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | peter.hutterer | ||||||
| Version: | unspecified | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
Note, I suspect what's causing the device-changed events is that the "keyboard mouse" is temporarily being made the "current pointer device" each time that it emits an event, but the corresponding device-changed event does not reach client (presumably because it is filtered out). So the client only sees device-changed events when the "current pointer device" is corrected back to an actual mouse. run evemu-record against the device node(s) and attach the output here please, thanks. Created attachment 126080 [details]
evemu output for the mouse node
Created attachment 126081 [details]
evemu output for the keyboard node
These two attachments are evemu outputs for the mouse and keyboard event nodes of the mouse respectively:
/dev/input/by-id/usb-Logitech_Gaming_Mouse_G300-event-mouse
/dev/input/by-id/usb-Logitech_Gaming_Mouse_G300-if01-event-kbd
During the trace, I did the following:
- Pressed LMB and released LMB.
- Scrolled down two times.
- Scrolled up two times.
In the second trace the events correspond to:
LMB pressed:
E: 0.000001 0003 0028 0001 # EV_ABS / ABS_MISC 1
LMB released:
E: 0.154035 0003 0028 0000 # EV_ABS / ABS_MISC 0
Scroll down twice:
(no events)
First scroll up:
E: 3.832100 0003 002a 0001 # EV_ABS / (null) 1
Second scroll up:
(no events)
Note that evemu-record fails to resolve the event code for that last code, just says (null). The actual code is 42.
For anyone who has the problem, a workaround is to add this to xorg configuration:
Section "InputClass"
Identifier "Ignore keyboard mouse device"
MatchIsKeyboard "on"
MatchProduct "Logitech Gaming Mouse G300"
Option "Ignore" "on"
EndSection
fwiw, libinput doesn't have this problem, it ignores those events correctly. For evdev the fix is trickier as it's a fairly simple stupid driver. evdev is also in maintenance mode and will be replaced with libinput over time so any specialised device handling will focus on libinput. Since there's a simple workaround with the above snippet I'm going to close this as WONTFIX, sorry. |
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.
I have a Logitech Gaming Mouse G300, and I have interesting issue scrolling in Qt5 applications (only). Every time after I click into a scrollable area (including if the area already had focus) and then try to scroll with the wheel, unexpected things happen, like: (1) A big scroll jump up or down in the scrollable area. (2) One or two following scroll wheel motions being inhibited. The issue exists at the Xinput2 layer so Qt5 is presumably not to blame here. When I run "xinput test-xi2 <master-pointer>", I am seeing curious behavior, that every time I press or release a mouse button, I see a DeviceChanged event, claiming the active master-pointer device has changed to this mouse, before the button events. Most interesting is that I only see device-changed events to this mouse, and no device-changed events to another mouse. So xorg is repeatedly telling applications "this mouse is the active mouse" every time I press or release a button on that mouse. The root cause of this is that this mouse presents as two evdev devices, as seen e.g. in the kernel log: [14100.893881] usb 2-1.4.1: Product: Gaming Mouse G300 [14100.893883] usb 2-1.4.1: Manufacturer: Logitech [14100.895685] input: Logitech Gaming Mouse G300 as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.1/2-1.4.1:1.0/0003:046D:C246.000B/input/input25 [14100.895914] hid-generic 0003:046D:C246.000B: input,hidraw1: USB HID v1.10 Mouse [Logitech Gaming Mouse G300] on usb-0000:00:1d.0-1.4.1/input0 [14100.899702] input: Logitech Gaming Mouse G300 as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.1/2-1.4.1:1.1/0003:046D:C246.000C/input/input26 [14100.950749] hid-generic 0003:046D:C246.000C: input,hiddev0,hidraw2: USB HID v1.10 Keyboard [Logitech Gaming Mouse G300] on usb-0000:00:1d.0-1.4.1/input1 And Xorg also sees them separately: ⎡ Virtual core pointer id=2 [master pointer (3)] ... ⎜ ↳ Logitech Gaming Mouse G300 id=10 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ... ↳ Logitech Gaming Mouse G300 id=9 [slave keyboard (3)] Using a custom test program I see that the "keyboard mouse" evdev generates ABS_MISC events where the value is a mask of currently pressed buttons. E.g. one gets this by pressing LMB, pressing RMB, releasing LMB, releasing RMB (EV_SYN not shown). type=EV_ABS code=ABS_MISC value=1 type=EV_ABS code=ABS_MISC value=3 type=EV_ABS code=ABS_MISC value=2 type=EV_ABS code=ABS_MISC value=0 So this special device must be interfering with Xorg's input system and causing the spurious device-changed events and the scrollig issues I mentioned. Issue (1) is a manifestation of bug #62321. I confirm the last two suggested patches there (combined) resolve the erroneous scroll jumps. The jumps seem to be a result of the device-change resetting the absolute scroll position to 0 but the application not being informed properly due to this bug. However issue (2) remains, as do the device-changed xinput events. Actually what remains after that fix is apparently only this: - Click into a scrollable area of a Qt5 application. - Scrolling down works fine, no scrolls "lost". - But the first scroll-up is "lost" (regardless of how many scroll-downs we did, if any). And the root cause seem to be these events emitted from the mysterious evdev device, just at the times of the lost scroll-up: type=EV_ABS code=42 value=1 I look at "xinput test-xi2 <master-pointer>" and I see this happening as I do the procedure explained above: - DeviceChanged, ButtonPress, ButtonRelease (as I press and release the LMB) - Motion(-1), Motion(-2), Motion(-3) (as I scroll down - note the scroll wheel values have been reset to 0 by the mouse press) - DeviceChanged, Motion(1), Motion(2), Motion (3) (as I scroll up - again note the reset to 0; the first scroll-up event (to 1) is lost in Qt5 app but not sure why).