https://bugzilla.novell.com/show_bug.cgi?id=144682 ------- Comment #55 from mhopf@novell.com 2007-05-14 10:09 MST ------- (In reply to comment #44)
This is bogus. MouseReadInput() is for low level event reading.
Yes.
Mapping details don't belong there but should all be handled in the PostEvent handling.
IMHO this is not mapping, but how the protocol is specified to report two axes.
I would like to separeate all these post event handlings to make it available to other mice drivers. Therefore it needs to be kept away from the low level event reading code.
It doesn't make sense to provide this "mapping" to other mice drivers which speak another protocol. (In reply to comment #46)
Originally the driver read data from the PS/2 interface directly. Here we should have had two different protocols to distinguish. Now since the kernel deals with the different mice protocols internally it should also normalize this zaxis/button behavior.
Yes, and this is about to change, or has already changed. So we will have to deal with both protocol variants for some time, even in /dev/input/mice emulation mode. That there are two variants of this protocol hasn't been clear until recently, and it's IMHO quite broken - as they cannot be distinguished from each other, or only in one direction and only on some (few) events. Actually, the whole concept that's currently used is broken, having the kernel to emulate a serial mouse over /dev/input/mice, and why on earth has such a broken protocol been selected? It also only allows for 5 buttons... I don't want to sound ungrateful, though, X has neglected input hotplugging for too long... (In reply to comment #48)
Currently, the kernel interprets 0xe/0x2 as "wheel1 twice", while x.org interprets it as "wheel2".
Which is wrong (read comment #39). Xorg only interprets as wheel2 if told to do so.
I don't see this in the EXPPS2 protocol handling.
+ case 0x02: dw = 1; break; + case 0x0e: dw = -1; break;
The patch however contains: else if (dw > 0 || dz > 1) zbutton = pMse->positiveW;
No, it *removes* this. This code was IMHO dead ugly, and probably wrong.
Get rid of the insane if (dw < 0 || dz < -1) ^^^^^^^
Agreed.
I wonder if the new ExplorerPS/2 mice use the two upper bits to signal the second wheel. If so it'd be easy to implement - hoping that all other mice un
Read comment #32 and comment #33.
the planet using this protocol are sane enough to always set these bits to 0 instead of letting them float.
No, they are not. They use it for multi wheel events.
Do we really want to map fast mouse wheel movements to a series of up/down events unconditionally? If a user does want to use the wheel for button events
? Wheel events are typically always mapped to button 4&5 events... What else do you want to map mouse wheel movements to? Remember, with some explorer mice you even get a series of 1 wheel move events for a fast wheel movement, for some you get larger ones. One sane idea would probably to leave these wheel events axis events, but I assume the mouse driver doesn't allow for more than two axes right now.
We are moving away from this mouse driver and to evdev anyhow.
Right. That's why I wouldn't invest too much here.
I'd suggest to do the following: 1. We ignore the strange behavior of A4Tech PS/2 mice in the EXPS2 protocol.
I only wanted to know the difference first. Given the description of Balazs, it seems it talks exactly the protocol that's implemented now in the Xorg mouse driver, but the kernel cannot detect that and thus emulates the new ExplorerPS/2 mapping with 2 wheels, but consolidates the W wheel events to 2 z wheel events. Apparently, nobody implemented the regular 2-wheel mode protocol in the Xorg mouse driver so far.
2. Just for the sake of completeness add a new protocol or option for the A4Tech mice to the X driver to account for the A4Tech quirk. This will be irrelevant for Linux users unless they still use 2.4 or lower kernels. A
ZAxisMapping "4 5 6 7" should do exactly that. When not using /dev/input/mice. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.