Richard Rauch <rkr@olib.org> 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
-- 
Wolfgang S. Rupprecht                http://www.wsrcc.com/wolfgang/
     Microsoft power cords: "Finding innovative new uses for our
		       blue-screen technology."