I have an A4Tech WOP-49Z mouse, which has two wheels - one for vertical and one for horizontal scrolling. It has worked perfectly well with many Linux kernel versions since 2011. With the latest stable kernel version 5.0, however, the horizontal wheel acts as an inverted vertical wheel. xev reports both vertical and horizontal wheel scrolling as buttons 4/5 with kernel versions 5.0.5, 5.0.7. With kernel versions 4.19.32, 4.19.34 and 4.20.17, xev reports vertical wheel scrolling as buttons 4/5 and horizontal wheel scrolling as buttons 6/7. I'm testing different kernel versions in the same system with the same other package versions. I'm rebooting and switching between different installed kernel versions provided by Manjaro Linux distribution. Could this bug be caused by a mistake in the implementation of the new feature in kernel 5.0 - "Logitech High Resolution Scrolling support"?
I also have this problem - A4Tech Opto 429, kernel 5.0.
Created attachment 282565 [details] Patch which fixes the bug I prepared a patch. After introducing hi-res scrolling for Logitech mice, the A4Tech driver hasn't been updated for new codes.
Błażej Szczygieł, thank you for trying to fix the bug. In this merge commit https://github.com/torvalds/linux/commit/276e722761a1c7903fbfb065420fd1850b00f1dd the documentation for REL_WHEEL_HI_RES states: "If a vertical scroll wheel supports high-resolution scrolling, this code will be emitted in addition to REL_WHEEL." The documentation implies that code, which references REL_WHEEL, should still work as before. The attached patch seems to work some other bug around rather than properly update the A4Tech driver for recent changes. There is no explaining commit message for the patch, so perhaps I just misunderstand something.
Igor Kushnir, thank you for the review. In the commit https://github.com/torvalds/linux/commit/2dc702c991e3774af9d7ce410eef410ca9e2357e#diff-2932ecf7dc8f07f01594df50bcdf0fa5 I can see that "map_rel()" takes the argument of "REL_WHEEL_HI_RES" (0x0b). Previously it was "usage->hid & 0xf" which is "REL_WHEEL" (0x08). The A4tech driver maps the vertical relative scroll as a horizontal scroll for some mice, so I changed the A4tech driver to use the new usage code. There is a possibility that other HID drivers might have similar issues.
I applied the attached patch to kernel 5.0.10 and it fixed the issue for my mouse. I was confused by the outdated documentation. The commit that added it was soon reverted as can be seen here: https://github.com/torvalds/linux/commits/master/Documentation/input/event-codes.rst. The relevant documentation now is: "These event codes are legacy codes and REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES should be preferred where available.". I think the attached patch is indeed a proper way to fix the bug. Błażej Szczygieł, are you going to submit this patch to LKML?
Igor Kushnir, I'll submit this patch (this is the first time when I do a patch for the Linux Kernel).
I have fairly old A4Tech X6-005D. Since 5.1.17 the vertical wheel stopped working completely. I get no events dumping /dev/input/mouse0 . I'm still investigating, but my working speculation is that my mouse does not have hi-resolution wheel.
Hi Ivan, I see that the patch that fixes this bug got included in kernel 5.1.17: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.1.17 (search for "a4tech" on this page). You are probably experiencing the related bug triggered by the patch. There is already a v2 patch for it, which is discussed here: https://www.spinics.net/lists/linux-input/msg62227.html.
(In reply to Ivan Kalvachev from comment #7) > I have fairly old A4Tech X6-005D. > Since 5.1.17 the vertical wheel stopped working completely. I get no events > dumping /dev/input/mouse0 . > > I'm still investigating, but my working speculation is that my mouse does > not have hi-resolution wheel. I have (and not just me) the same experience with old optical A4tech mouse 510D/620D : https://bugzilla.kernel.org/show_bug.cgi?id=204179
Both wheels on my mouse work perfectly with kernel 5.1.18. This must mean that the new bug doesn't affect all A4Tech mice. I'm closing this bug as the new one should be discussed on its dedicated page (see LukasH's link).
Kernel 5.3.6 works perfectly for me and https://bugzilla.kernel.org/show_bug.cgi?id=204179 must be fixed in this version too. I'm closing this bug because both the original issue and the related regression have been eliminated.