Subject: Re: Two mouses
To: None <firstname.lastname@example.org>
From: Wolfgang S. Rupprecht <wolfgang+gnus20050301T200456@dailyplanet.dontspam.wsrcc.com>
Date: 03/01/2005 20:29:05
Richard Rauch <email@example.com> writes:
> Some applications have hard-coded assumptions, as indicated previously,
> about the buttons that correspond to the wheel. xterm defaults to
> assuming 4 & 5, but can be told otherwise.
Yea, there seem to be some really grotty assumptions in most X clients
that any mouse has at most 3 buttons. Modern high-end mice in
addition to having nice 800dpi optical sensors also tend to have a
crapload of buttons. Getting X to use them requires reading between
the lines of the source as far as I can tell.
I recently bought a Logitech MX-510 to replace a ball-mouse that was
getting pretty crunchy. It took a while to piece together what X
expected of the mouse. Here is my take:
Buttons 1-3 can stay where they are.
Buttons 4-9 need to be declared in xorg.conf/XF86Config as the
following in the "InputDevice" section:
Option "Buttons" "10"
Option "ZAxisMapping" "9 10"
Option "Resolution" "800"
From the shell (eg. in one of the X shell scripts):
xmodmap -e "pointer = 1 2 3 6 7 8 9 10 4 5"
One needs to shuffle the real buttons with the scroll-wheel since all
the darn X programs expect the scroll wheel to appear as button 4 and
5 presses. The real buttons 4 and 5 need to be moved up higher (say
to 6 and 7) while the wheel that was mapped onto 9 and 10 needs to be
moved down to 4 and 5. Mapping the wheel onto 4 and 5 directly from
the xorg.config file is a loose, since it will them be impossible to
untangle wheel motion from the real button 4 and 5 key presses.
Pretty simple huh?
We could really use some real scroll-wheel input events. It is weird
that the same amount of finger motion that causes 100 pixels of X or Y
motion causes a single "button press" worth of Z motion. It just
doesn't feel right.
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
Microsoft power cords: "Finding innovative new uses for our