SetPointerMapping protocol braindeadedness
keithp at keithp.com
Mon Jul 3 17:53:20 PDT 2006
On Mon, 2006-07-03 at 23:10 +0200, Egbert Eich wrote:
> Daniel Stone writes:
> > >
> > > Would it be better to add a 'fixedSetPointerMapping' to XFIXES?
> > This is doable.
> Right. The question is - should we bother?
> Retaining the old (sometimes broken) protocol behavior as much
> as possible seems to be the way to go to ensure that those of the
> tons of legacy apps that may need the old behavior continue to
We're reworking the input system to make the mouse and keyboard virtual
devices; that means we'll need to find other ways of signalling the
current physical device state. The keyboard does this through keymap
updates, the pointer should be able to do this the same way but the core
protocol is limiting the utility of the reported mapping. As this
affects only the mapping reported through the SetPointerMapping request
and not input events in general, it seems like just fixing it to do what
we want is sensible. This allows new applications to determine how many
buttons are actually available presently, while not restricting how many
buttons may be available when new input devices are connected.
> Right of hand I can't see any other reason.
I'm sure that's the reason; mice had only a few buttons, and couldn't be
replaced on the fly; screwing up could make the computer inaccessible.
> > 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.
> I'd opt for a mixture of a and b to retain the old behavior as much
> as possible:
> Aggregate XInput pointers to a core pointer and use SetPointerMapping
> to do an overall remapping of the core pointer buttons after they have
> been processed by the device specific layer.
Yeah, there's not a lot we can do here; you have to make existing
left-handed mice configuration applications continue to work.
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg