Administrace komentářů

On Dec 01, 06 12:34:01 +0100, karpi wrote:
> > > Now i found you probably fixed this behavior as a bug in the version
> > > 1.1.1 :((
> > 
> > Yes, this was a bug, and you were probably the only guy who liked this
> > behavior 
> Oh! on the whole whole world, in the all space only me? Im feeling
> _so_ importent :))

:-P  We all do


> > > Is there some way to got this behavior back ?
> > Option "zAxisMapping" "4 5 6 7"
> > 
> unfortunatelly not :(

Ok, then we have to analyze.
Are you sure you only changed the X.org release (and not e.g. the kernel
as well)? I do not remember exactly, but it could well be that the
kernel guys changed the interface as well in the meantime (because the
way it was it didn't allow for multiwheel mice).

> (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7

Hm, that worked.

> .. but xev announces only :
> ButtonRelease event, serial 30, synthetic NO, window 0x2000001,
>     root 0x4d, subw 0x0, time 1035637284, (169,2), root:(170,748),
>     state 0x1010, button 5, same_screen YES

Try "evtest /dev/input/eventX" (you have to try different values for X
to find the right event interface).

If you only get values -1 and 1 for (Wheel) events, the kernel has
changed indeed. You used to get higher values here as well.

> I would like speak for returning this behavior back as a feature, in
> some way so that nobody was confused (any new option or something). My
> opinion is that is more usefull to have 7 configurable buttons then 5,
> on common chep mouse. Do you share this idea ?

Actually, the former behavior was clearly a bug. Having this behavior on
purpose could be considered a feature, but so far I doubt there will be
many people that like this behavior. And given that the days of the
standard mouse driver are probably counted, I doubt there will be anyone
working on that.

Except of course, if you implement it yourself, if the patch is well
structured I'll happily apply it upstream :)

CU

Matthias