New approach to multitouch using DIDs and bitmasked events

[Peter Hutterer]

On Wed, Jul 07, 2010 at 06:54:17AM +0200, Henrik Rydberg wrote:
> Peter Hutterer wrote:
> > On Tue, Jul 06, 2010 at 08:29:34AM +0200, Henrik Rydberg wrote:
> >> Peter Hutterer wrote:
> >>> 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.
> >> I will take your word for it, but it does sound like there is not much of a
> >> resistance against the idea. :-)
> > 
> > I can give you the branch if you're really interested but it didn't get
> > further than a lot of search/replace of inputInfo.pointer and
> > inputInfo.keyboard. When I started sorting out how a single master device
> > may be grabbed sync on the keyboard but async on the pointer with different
> > replaying order or sync/async swapping I gave up.
> > 
> > Branch date's back to march 2009, so it's a bit out of date.
> 
> Oh, that would be nice. Not saying I would do anything with it, but I am
> curious. :-)

people.freedesktop.org/~whot/xserver.git single-master-device

don't expect too much ;)

Cheers,
  Peter