mirror of https://gitee.com/openkylin/linux.git
4c711ef628
This Far-Eastern company's PS/2 mice use a deviant format for the data relating to movement of the scroll wheels for, at least, their dual wheel mice, such as their "Optical GreatEye Wheelmouse" model "WOP-35". This product has five "buttons" (one of which is the click action on the first wheel) and TWO scroll wheels. However for a byte comprising d0-d7 instead of setting one of d6-7 in the forth byte of the mouse data packet and a twos complement number of scroll steps in the remaining d5-d0 (or d3-d0 should there be a fourth (BTN_SIDE - d4) or fifth (BTN_EXTRA - d5) button to report; they only report a single +/- event for each wheel and use a bit pattern that corresponds to +/-1 for the first wheel and +/- 2 for the second in the lower nibble of the fourth byte. The effect with existing code is that the second mouse wheel merely repeats the effect of the first but providing two steps per click rather than the one of the first wheel - so there is no HORIZONTAL scroll wheel movement detected from the device as far as the rest of the kernel sees it. This patch, if enabled by the "a4tech_workaround" module parameter modifies the handling just for mice of type PSMOUSE_IMEX so that the second scroll wheel movement gets correctly reported as REL_HWHEEL events. Should this module parameter be activated for other mice of the same PSMOUSE_IMEX type then it is possible that at the point where the mouse reports more than a single movement step the user may start seeing horizontal rather than vertical wheel events, but should the movement steps get to be more than two at a time the hack will get immediately deactivated and the behaviour will revert to the past code. This was discussed around *fifteen* *years* *ago* on the LKML and the best summary is in post https://lkml.org/lkml/2002/7/18/111 "Re: PS2 Input Core Support" by Vojtech Pavlik. I was not able to locate any discussion later than this on this topic. Given that most users of the "psmouse" module will NOT want this additional feature enabled I have taken the apparently erroneous step of defaulting the module parameter that enables it to be "disabled" - this functionality may interfere with the operation of "normal" mice of this type (until a large enough scroll wheel movement is detected) so I cannot see how it would want to be enabled for "normal" users - i.e. everyone without this brand of mouse. I am using this patch at the moment and I can confirm that it is working for me as both a module and compiled into the kernel for my mouse that is of the type (WOP-35) described - I note that it is still available from certain on-line retailers and that the manufacturers site does not list GNU/Linux as being supported on the product page - this patch however does enable full use of this product: http://www.a4tech.com/product.asp?cid=3D1&scid=3D8&id=3D22 Signed-off-by: Stephen Lyons <slysven@virginmedia.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> |
||
|---|---|---|
| .. | ||
| gameport | ||
| joystick | ||
| keyboard | ||
| misc | ||
| mouse | ||
| rmi4 | ||
| serio | ||
| tablet | ||
| touchscreen | ||
| Kconfig | ||
| Makefile | ||
| apm-power.c | ||
| evbug.c | ||
| evdev.c | ||
| ff-core.c | ||
| ff-memless.c | ||
| input-compat.c | ||
| input-compat.h | ||
| input-leds.c | ||
| input-mt.c | ||
| input-polldev.c | ||
| input.c | ||
| joydev.c | ||
| matrix-keymap.c | ||
| mousedev.c | ||
| sparse-keymap.c | ||