Subject: Re: Two mouses
To: None <>
From: Wolfgang S. Rupprecht <>
List: port-i386
Date: 03/01/2005 20:29:05
Richard Rauch <> 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      
     Microsoft power cords: "Finding innovative new uses for our
		       blue-screen technology."