SetPointerMapping protocol braindeadedness

[Daniel Stone]

On Mon, Jul 03, 2006 at 09:12:17PM +0200, Egbert Eich wrote:
> Daniel Stone writes:
>  > On Mon, Jul 03, 2006 at 02:55:16PM +0300, Daniel Stone wrote:
>  > > 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?

This is doable.

>  > > 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. 

Yay for the protocol second-guessing the user.

>  > 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.

The real fix is to get rid of this bizzare SendCoreEvents mess once and
for all.  I have a working implementation[0] of this, which also adds
input hotplug, that I'm just waiting on approval to release.

Then we can just either:
a) ignore core SetPointerMapping events and only listen for Xi events,
   as the core pointer is now a virtual aggregator, or
b) propagate core SPMs down to the invidiual pointers.

Cheers,
Daniel

[0]: Okay, so when you press e then c, or c then e, quite rapidly, then
     you always get c then e.  I'm still looking into that one.  But it
     otherwise works across KDrive and Xorg, and is highly portable to
     other DDXes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060703/d5b8a6f2/attachment.pgp>