New approach to multitouch using DIDs and bitmasked events

Peter Hutterer peter.hutterer at who-t.net
Mon Jul 5 17:25:20 PDT 2010


On Sat, Jul 03, 2010 at 01:10:24AM -0400, Rafi Rubin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/02/10 05:59, Henrik Rydberg wrote:
> > Peter Hutterer wrote:
> > [...]
> >> It'd be interesting to see how much work it is to have this API
> >> _replace_ the current API. Gives us more exposure and better testing.
> >> Note that I have some more API changes planned (not coded) that simplify
> >> the init process, they should all go in in one go.
> >> Another change that goes with that is the ability to easily split up
> >> devices into multiple X devices. This would make it easier to handle
> >> devices that have both MT events and normal events - they would simply
> >> end up being two devices, one normal one, one DID.
> >>
> >> Henrik, Rafi - do you think this would work for the MT devices we've
> >> seen so far?
> > 
> > From a device perspective, absolutely. In the kernel, a single device can have
> > any combinations of BTN, ABS, and MT events. Keys are getting there as well, but
> > are still normally separated by force. In other words, trusting the kernel to
> > make a logical split of events which fits the X framework is not very fruitful.
> > 
> > Going forward, I wonder why we split input into separate devices at all. We have
> > different types, and different behavior based on capabilities, but input is
> > becoming so intermixed that the notion of separated devices looses its meaning.
> > Why not just put all input events into the same bucket, and let clients specify
> > what event types to listen to?
> 
> I agree, I don't see the need to artificially separate keyboards and pointers.

say hello to my friend the core protocol. approximately 100% of all
applications rely on it (rounded to the nearest percent) :)
who needs enemies if you got friends like this.

fwiw, about a year ago I had a private branch that gets rid of the
pointer/keyboard distinction and provide a unified master device that's both
pointer and keyboard. that didn't turn out well, grab synchronization is a
nightmare.

Cheers,
  Peter


More information about the xorg-devel mailing list