Generic Precedence Grouping for Input Devices

Cedric Sodhi manday at gmx.net
Mon Jun 4 00:55:44 PDT 2012


Is it feasible to improve XI2 in a way that arbitrary pointers of
devices which provide "usage" information (such as the "proximity" of
wacom which tells whether the pen is actually "used" - i.e. in the
proximity of the tablet) can be assigned priorities, so that events from
devices for pointers with lower priority are ignored when ones which
higher priority submit data?

The concept is of course useless for any device which has no notion of
"usage", such as a regular mouse - but providing such means to the class
of devices which do have a method of knowing that, could be consistently
incorporated into the system.

If we group all devices into those which do have such a capability and
the rest which don't, we could distribute priorities among the former
(and their multiple pointers) and a single priority for all the latter.

The one priority given to all the former which do not have that
capability then designates what happens if at least one of the former
devices currently holds a "grab" and the latter (e.g. a regular mouse)
emits an event.

If at least one of the former holds a "grab", the event from the regular
mouse only comes through, if the common priority of all the latter is
higher than the highest of those devices, currently holding a grab.

Vice versa, the "grabbing" devices always take priority over the
non-grabbing ones.

Optionally, one may think of having the devices which do not report
"proximity" automatically take a grab one the first event, and only
release it after there has been no activitiy for a configurable time.

While the solution is surely not overly elegant, it is the best thing
possibly doable, as far I can see.

I'm sure some would argue that such mechanism should better be
implemented as part of daemon, but so I ask you: Why? Not only would
this likely require different kinds of hacks, neither do I see a reason
why such a rather simple mechanism shouldn't be provided by XI2 itsself.

Cedric



More information about the xorg-devel mailing list