SetPointerMapping protocol braindeadedness

[Egbert Eich]

Daniel Stone writes:
 > On Mon, Jul 03, 2006 at 02:55:16PM +0300, Daniel Stone wrote:
 > > Hi all,
 > > The protocol spec for SetPointerMapping says:
 > > 'A zero element disables a button.  Elements are not restricted in value
 > > by the number of physical buttons, but no two elements can have the same
 > > nonzero value (or a Value error results).'
 > > 
 > > Right now, we test for button values being n > 1 and n < 255.  I propose
 > > we trade one protocol violation for another: allow n == 0 to disable
 > > buttons altogether, but at the same time, also allow duplicate button
 > > mappings (e.g. 1 2 3 4 5 6 7 3, being valid, if you want button eight to
 > > behave like button three).

Would it be better to add a 'fixedSetPointerMapping' to XFIXES?

 > > 
 > > Does anyone know why this restriction was enforced in the protocol,
 > > and/or have any objections to this change?

Was probably added to prevent you from loosing mouse buttons by accidental
remapping. 

 > 
 > In case you're curious: someone asked me how to make his under-thumb
 > button (8) behave like the middle button (3) and have them both work
 > as paste.  I didn't have a good answer.

There are more issues which involve the DDX: With SendCoreEvens one can
make another input device send core mouse events. SetPointerMapping
of course acts only on the 'real' core mouse. So if you do a remapping
it does not efect the other input devices.
Now one could argue that this is the intended behavior as remapping is
per physical device and not per device class - however from client side
there is no way to detect which input device also sends core events
- not even thru the ill designed xf86misc extension.
It would be easy to add this as another wart to this extension.

Cheers,
	Egbert.