Bug 203369 - A4Tech mouse: horizontal scrolling is recognized as vertical since kernel 5.0
Summary: A4Tech mouse: horizontal scrolling is recognized as vertical since kernel 5.0
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-21 11:24 UTC by Igor Kushnir
Modified: 2019-10-15 10:16 UTC (History)
4 users (show)

See Also:
Kernel Version: 5.0
Tree: Mainline
Regression: Yes


Attachments
Patch which fixes the bug (1.14 KB, patch)
2019-05-01 09:55 UTC, Błażej Szczygieł
Details | Diff

Description Igor Kushnir 2019-04-21 11:24:23 UTC
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"?
Comment 1 Błażej Szczygieł 2019-04-25 07:10:35 UTC
I also have this problem - A4Tech Opto 429, kernel 5.0.
Comment 2 Błażej Szczygieł 2019-05-01 09:55:46 UTC
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.
Comment 3 Igor Kushnir 2019-05-01 11:09:09 UTC
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.
Comment 4 Błażej Szczygieł 2019-05-01 14:28:28 UTC
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.
Comment 5 Igor Kushnir 2019-05-02 17:57:24 UTC
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?
Comment 6 Błażej Szczygieł 2019-05-02 21:32:51 UTC
Igor Kushnir, I'll submit this patch (this is the first time when I do a patch for the Linux Kernel).
Comment 7 Ivan Kalvachev 2019-07-12 10:23:45 UTC
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.
Comment 8 Igor Kushnir 2019-07-13 10:52:26 UTC
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.
Comment 9 LukasH 2019-07-17 15:32:49 UTC
(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
Comment 10 Igor Kushnir 2019-07-20 18:09:37 UTC
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).
Comment 11 Igor Kushnir 2019-10-15 10:16:13 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.