[Bug 144682] fast scrolling with mouse wheel scrolls horizontally
https://bugzilla.novell.com/show_bug.cgi?id=144682 ------- Comment #56 from eich@novell.com 2007-05-14 11:12 MST ------- (In reply to comment #55)
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 was referring to pMse->negativeW != MSE_NOAXISMAP, this is mapping. This is a kludge for broken mice protocols. 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.
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.
Right. Because we are confusing mappings and protocols here. 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.
(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.
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.
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...
Exps2 isn't really broken. Some mice are. Other manufactueres are at least nice enough to add an extension the the EXPS2 protocol.
(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.
Right. This happens in the post processing code. I already said that this is completely insane. Moving it up to the low level input layer was the right choice.
I don't see this in the EXPPS2 protocol handling.
+ case 0x02: dw = 1; break; + case 0x0e: dw = -1; break;
Right. That's what you've added.
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
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.
Again I was referring to the extended EXPS/2 protocol Vojtech had mentioned. This isn't discussed in comment #32 and #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.
Again I was referring to the upper two bits: EXPS/2: 0 0 b5 b4 z3 z2 z1 z0 These are masked out in the current driver.
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.
Right. But you may not always want to map buttons to wheel events. This is configurable in xkb.
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.
We are moving away from this mouse driver and to evdev anyhow.
Right. That's why I wouldn't invest too much here.
I won't.
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.
Right. That's what I will do.
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.
So we assume standard EXPS2 && ZAxisMapping == user has a broken a4tech. At least it seems to be the assumption that was made before. I will try to accomodate this somehow. -- 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.
participants (1)
-
bugzilla_noreply＠novell.com