mouse button mapping

[dep]

the plot thickens -- has suse screwed around with xfree? here's why i 
wonder:

at http://www.xfree86.org/current/mouse.html we find this --

6.3. Kensington Thinking Mouse and Kensington Expert Mouse (serial, 
PS/2) 
These mice have four buttons. The Kensington Expert Mouse is really a 
trackball. Both Thinking mice support the PnP COM device specification.

To use this mouse as a serial device: 

        Option  "Protocol"      "Auto"

 or: 
        Option  "Protocol"      "ThinkingMouse"

To use this mouse as the PS/2 device and the OS supports PS/2 mouse 
initialization: 

        Option  "Protocol"      "ThinkingMousePS/2"

To use this mouse as the PS/2 device but the OS does not support PS/2 
mouse initialization (the third and the fourth buttons act as though 
they were the first and the second buttons): 

        Option  "Protocol"      "PS/2"

To use this mouse as the PS/2 device and the OS supports automatic PS/2 
mouse detection: 

        Option  "Protocol"      "Auto"

and there is even a suggested configuration:

The Kensington Expert mouse is really a trackball. It has 4 buttons 
arranged in a rectangle around the ball.

 

 
Section "InputDevice"
        Identifier  "DLB"
        Driver      "mouse"
        Option      "Protocol" "ThinkingMousePS/2"
        Option      "Buttons" "3"
        Option      "Emulate3Buttons"
        Option      "Device" "/dev/mouse"
        Option      "DragLockButtons" "2 1 4 3"
EndSection

 In this example, button 2 is a drag lock button for button number 1, 
and button 4 is a drag lock button for button 3. Since button 2 is 
above button 1 and button 4 is above button 3 in the layout of this 
trackball, this is reasonable. 

Because button 2 is being used as a drag lock, it can not be used as an 
ordinary button. However, it can be activated by using the 
"Emulate3Buttons" feature. However, some people my be unable to press 
two buttons at the same time. They may prefer the following InputDevice 
section which defines button 4 as a master drag lock button, and leaves 
button 2 free for ordinary use. 

 
Section "InputDevice"
        Identifier  "MasterDLB"
        Driver      "mouse"
        Option      "Protocol" "ThinkingMousePS/2"
        Option      "Buttons" "3"
        Option      "Device" "/dev/mouse"
        Option      "DragLockButtons" "4"
EndSection


now. the first of these configurations works, kind of. problem is, there 
is no "ThinkingMousePS/2" protocol available. if i use plain old "PS/2" 
i get kind of expected behavior with the thing -- the top two buttons 
are locks of the lower two buttons -- but there is no reason i can find 
for a drag rmb, the way a locked lmb is useful for, say, selecting test 
or scrolling a long web page. the second configuration doesn't seem to 
work at all.

ideally, the top left would be the lmb, the bottom left an lmb lock; the 
top right would be the rmb, and the lower right would emulate the third 
mouse button, which is to say would paste.

what makes me think that suse has screwed around with this is that with 
"PS/2" and no modifiers i should have two right and two left, but i 
don't -- i have one right -- lower right -- and one left -- lower left, 
and two middle buttons. meanwhile, despite all my efforts to convince 
it otherwise, suse has decided that i have an "ImPS/2 Generic Wheel 
Mouse," which i don't. i've rerun yast to change it to plain old PS/2, 
but all this does is get it to change my XF86Config so that the screen 
is screwed up. i keep a backup of a good XF86Config, and can 
cut'n'paste to include the new stuff that yast hath wrought without 
losing my monitor config, but this is just plain screwy.

guesses or suggestions welcome.
-- 
dep

Liberalism has been degraded into liberality. Men have tried to turn
"revolutionise" from a transitive to an intransitive verb.
							  -- G.K. Chesterton, "Orthodoxy"