https://bugzilla.novell.com/show_bug.cgi?id=144682 ------- Comment #58 from mhopf@novell.com 2007-05-14 12:17 MST ------- (In reply to comment #56)
IMHO this is not mapping, but how the protocol is specified to report two axes. I was referring to pMse->negativeW != MSE_NOAXISMAP, this is mapping.
Arguably. I don't think so. It might look like mapping, but in fact it is disassembling wrong (broken) z axis information into z and w axis information. The code could look different, first checking this "flag", then depending on the outcome interpret the protocol. That would be duplicate code, though, and I wanted to change as little as possible in this mess. In this particular part of the code, wheels are actually wheels, and not buttons yet. It's only the "flag" testing code, that is - well - dubious.
This is a kludge for broken mice protocols.
Agreed.
And we try to derive if the user has this broken mouse from if he has configured a second wheel on an EXPS2. This is ugly. Besides I don't want to use pMse->negativeW in the low level input function.
Ok, you could implement a different mouse protocol, and call it ExplorerPS/2/With2Wheels or something like that. I don't think that would be more transparent, because this would result in duplicate code.
The post mouse event handling, all the 'gestures' and whatever people have added to the mouse driver to rotate coordiantes etc. is unrelated to the protocol.
I 100% agree! All this wheel to mouse button handling is horribly broken in the code. I actually believe that this should belong in *any* mouse driver at all. This should be outside the driver code.
The only broke variant seems to be the a4tech. Here the manufactuerer should have chosen a different protocol instead of reinterpreting an existing one. Really bad choice.
Yes. I didn't know about the correct protocol until right now. If that was known to me before, I had probably never introduced this broken protocol as a possibility. But upstream apparently nobody had complete information.
Exps2 isn't really broken. Some mice are. Other manufactueres are at least nice enough to add an extension the the EXPS2 protocol.
Ok, I meant the original ExPS2. W/o extensions. Does the kernel mouse emulation include code for >5 button protocol extensions?
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.
Sorry, i was referring to the patch that was pointed to by the first link in comment #37
Ah! Yes, you're right.
Read comment #32 and comment #33.
Again I was referring to the extended EXPS/2 protocol Vojtech had mentioned. This isn't discussed in comment #32 and #33.
My bad. Misunderstood your comment.
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.
Right. Kludge around the core protocol limitations.
.. Nothing to say :-/
wheel events. Apparently, nobody implemented the regular 2-wheel mode protocol in the Xorg mouse driver so far.
Right. That's what I will do.
Great! Together with the default ZAxisMapping "4 5" this should work out-of-the-box for *all* mice when Xorg uses /dev/input/mice, when the kernel has implemented the correct two-wheel protocol bits. As soon as you send the escape sequence it should send you the extended protocol data. The only exception is this brain-dead mouse, which needs manual intervention. Either configure /dev/psaus with ZAxisMapping "4 5 6 7", or use /dev/input/mice as before and tell the kernel to use the a4tech protocol.
So we assume standard EXPS2 && ZAxisMapping == user has a broken a4tech.
Right now, yes. I assume it wouldn't help the code quality too much if you change this to another protocol or use an additional option. (In reply to comment #57)
Right, i understand this. This was what was implemented in X using a horrific kludge which used to mess up the handling for all other mice.
Well, it's not *that* bad. Standard behavior is just like before. Only if ZAxisMapping is manually set, behavior changes. -- 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.