* Re: [hid-logitech-dj] Inaccurate Mouse Wheel Behaviour using G502 with Logitech Lightspeed Receiver (USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1)
2023-08-18 22:16 [hid-logitech-dj] Inaccurate Mouse Wheel Behaviour using G502 with Logitech Lightspeed Receiver (USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1) Sewer56
@ 2023-08-19 18:42 ` Rahul Rameshbabu
0 siblings, 0 replies; 2+ messages in thread
From: Rahul Rameshbabu @ 2023-08-19 18:42 UTC (permalink / raw)
To: Sewer56; +Cc: linux-input
On Fri, 18 Aug, 2023 23:16:14 +0100 "Sewer56" <admin@sewer56.dev> wrote:
> When scrolling with a Logitech G502 Lightspeed mouse (046d:c08d) in wireless mode
> with the official wireless receiver (046d:c539, i.e. USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1
> in `hid-logitech-dj.c`), the REL_WHEEL event is not fired consistently on mouse wheel notch/tick.
>
> [Note: This only affects wireless through receiver; wired works as expected]
>
> Rather than the event being fired when the mouse skips a notch/tick on the scroll
> wheel, it feels like the REL_WHEEL event is fired somewhere roughly around the middle
> point of the last notch/tick and the next notch/tick.
>
> I recorded a quick video to demonstrate this:
> https://youtu.be/IwaQAMDkotg
>
> In this clip I scroll the mouse wheel gently up and down, back and forth. Notice the
> appearance of REL_WHEEL_HI_RES with the value changing from 15 to -15 as the direction
> is changed; the wheel is being scrolled past the notch, but the REL_WHEEL event is not fired.
I think it's good to provide some background on what REL_WHEEL and
REL_WHEEL_HI_RES values indicate for the sake of this conversation.
REL_WHEEL is the number of detents (notches) that have been scrolled by.
REL_WHEEL_HI_RES is 1/120th of a detent. For fancier gaming peripherals,
having this capability is important to be able to advertise high
resolution information when someone makes minute wheel movements.
Event: time 1692246247.376147, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15
Event: time 1692246247.376147, -------------- SYN_REPORT ------------
Event: time 1692246247.448155, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15
Event: time 1692246247.448155, -------------- SYN_REPORT ------------
Event: time 1692246247.519161, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15
Event: time 1692246247.519161, -------------- SYN_REPORT ------------
Event: time 1692246247.549169, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15
Event: time 1692246247.549169, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1692246247.549169, -------------- SYN_REPORT ------------
Event: time 1692246247.589171, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15
Event: time 1692246247.589171, -------------- SYN_REPORT ------------
Event: time 1692246247.626176, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15
Event: time 1692246247.626176, -------------- SYN_REPORT ------------
Event: time 1692246248.574336, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value 15
Event: time 1692246248.574336, -------------- SYN_REPORT ------------
Event: time 1692246248.593325, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value 15
Event: time 1692246248.593325, -------------- SYN_REPORT ------------
Event: time 1692246248.606319, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value 15
Event: time 1692246248.606319, -------------- SYN_REPORT ------------
Event: time 1692246248.619329, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value 15
Event: time 1692246248.619329, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1692246248.619329, -------------- SYN_REPORT ------------
What hid-logitech-dj does for the lightspeed receiver is append
information about the report descriptor structure to tell the HID stack
how to parse the HID reports provided by the mouse. For the lightspeed
receiver, hid-logitech-dj will concat the mse_high_res_descriptor
descriptor.
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/tree/drivers/hid/hid-logitech-dj.c?id=1d7546042f8fdc4bc39ab91ec966203e2d64f8bd#n380
When you use the generic usbhid driver, you do not parse the special
report table with the high resolution information but only the defacto
descriptor with the mouse wheel USAGE information.
Event: time 1692245830.208738, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1692245830.208738, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -120
Event: time 1692245830.208738, -------------- SYN_REPORT ------------
Event: time 1692245831.231868, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1692245831.231868, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value 120
Event: time 1692245831.231868, -------------- SYN_REPORT ------------
Event: time 1692245831.783933, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1692245831.783933, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -120
Event: time 1692245831.783933, -------------- SYN_REPORT ------------
Event: time 1692245833.004410, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1692245833.004410, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value 120
Event: time 1692245833.004410, -------------- SYN_REPORT ------------
What you will notice here is we do get the single detent measurements,
and they are correct. However, we have lost the granularity to measure
the high precision information supported by the device (which is why we
see REL_WHEEL_HI_RES toggle between -120 and 120). This works out well
for games where you do not care about the high resolution precision but
is problematic in general. That said, not accurately counting detents is
also a problem.
>
> When the hid-logitech-dj module is blacklisted, and linux defaults to a more generic
> driver (usbhid); this issue is not present; which can be seen here: https://youtu.be/8AkVWHUe88M
>
> To put this into a realistic end user perspective: If you try to play a game on Linux
> with the current behaviour; and perform an action that requires the use of a scroll wheel
> [for example; changing the current weapon in a shooter], the input is often 'dropped' from
> the user perspective, leading to frustration.
The experience may seem like it's 'dropped', but I am getting a feeling
its more about miscounting . At least that's my intuition, but I think
what would likely shine light on this is collecting more information.
>
> I'm not exactly sure what further sort of information I could provide; I've only got back
> to using Linux on the desktop after 7 years; and it's my first time raising a kernel issue.
> That said, I'm happy to provide any further feedback, or even play with the kernel sources
> if someone could give me ideas of what I should experiment with.
>
I think collecting more information using hid-tools would be helpful.
https://gitlab.freedesktop.org/libevdev/hid-tools
I am interested in capturing a HID recording of the following.
1. Move the wheel just one detent in a single direction
2. Wait for a moment
3. Move the wheel back one detent in the opposite direction
4. Wait for a moment
5. Move the wheel two detents in the original direction
If you are interested in looking at the report descriptor structure
yourself, you can use hid-decode on the recording or directly on the
hidraw device fs node.
Here is an example of what happens when I use hid-decode to read the
report descriptor of my mouse device.
hid-decode /dev/hidraw0 # ran with elevated privileges
# device 0:0
# 0x05, 0x01, // Usage Page (Generic Desktop) 0
# 0x09, 0x02, // Usage (Mouse) 2
# 0xa1, 0x01, // Collection (Application) 4
# 0x09, 0x01, // Usage (Pointer) 6
# 0xa1, 0x00, // Collection (Physical) 8
# 0x05, 0x09, // Usage Page (Button) 10
# 0x19, 0x01, // Usage Minimum (1) 12
# 0x29, 0x10, // Usage Maximum (16) 14
# 0x15, 0x00, // Logical Minimum (0) 16
# 0x25, 0x01, // Logical Maximum (1) 18
# 0x75, 0x01, // Report Size (1) 20
# 0x95, 0x10, // Report Count (16) 22
# 0x81, 0x02, // Input (Data,Var,Abs) 24
# 0x05, 0x01, // Usage Page (Generic Desktop) 26
# 0x09, 0x30, // Usage (X) 28
# 0x09, 0x31, // Usage (Y) 30
# 0x16, 0x01, 0x80, // Logical Minimum (-32767) 32
# 0x26, 0xff, 0x7f, // Logical Maximum (32767) 35
# 0x75, 0x10, // Report Size (16) 38
# 0x95, 0x02, // Report Count (2) 40
# 0x81, 0x06, // Input (Data,Var,Rel) 42
# 0x09, 0x38, // Usage (Wheel) 44
# 0x75, 0x08, // Report Size (8) 46
# 0x95, 0x01, // Report Count (1) 48
# 0x15, 0x81, // Logical Minimum (-127) 50
# 0x25, 0x7f, // Logical Maximum (127) 52
# 0x81, 0x06, // Input (Data,Var,Rel) 54
# 0x05, 0x0c, // Usage Page (Consumer Devices) 56
# 0x0a, 0x38, 0x02, // Usage (AC Pan) 58
# 0x95, 0x01, // Report Count (1) 61
# 0x81, 0x06, // Input (Data,Var,Rel) 63
# 0xc0, // End Collection 65
# 0xc0, // End Collection 66
#
R: 67 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 10 15 00 25 01 75 01 95 10 81 02 05 01 09 30 09 31 16 01 80 26 ff 7f 75 10 95 02 81 06 09 38 75 08 95 01 15 81 25 7f 81 06 05 0c 0a 38 02 95 01 81 06 c0 c0
N: device 0:0
I: 3 0001 0001
Some new documentation was recently merged into next. Might be a helpful
reference as well.
https://www.kernel.org/doc/html/next/hid/hidintro.html
--
Thanks,
Rahul Rameshbabu
^ permalink raw reply [flat|nested] 2+ messages in thread