New approach to multitouch using DIDs and bitmasked events

[Chase Douglas]

On Sat, 2010-07-03 at 00:57 -0400, Rafi Rubin wrote:
> I think its clear that valuators are an extremely limited solution that just
> can't scale, certainly not without breaking up a device into multiple virtual
> devices each with a reasonable number of contacts.  Just imagine something like
> the 3m screens that support 20+ contacts, really, the numbers just start to get
> a little silly, and I'm pretty sure we'll see much larger devices capable of
> supporting many people working with many fingers simultaneously.

Just to be clear, we'll be using valuators in all approaches. The
difference is that in the DIDs approach we won't have an array of
touches comprised of an array of valuators for each touch. Instead, we
will just have an array of valuators to describe a single touch, and a
new event is sent for each individual touch event.

> So moving each contact off into its device is definitely a step in the right
> direction.

My approach doesn't make new input devices for each touch. It still has
the concept of one piece of hardware == one device. We use the Abs MT
Slot valuator to distinguish between the touches.

I just realized that I need to reinsert the code in xf86-input-evdev to
check for the existence of the ABS_MT_SLOT axis from the kernel or for
MTDEV (which translates to the slotted protocol). Otherwise, we should
just disable multitouch support for the device.

> I think the points I was trying to get to in earlier threads was more about the
> structure of input hierarchy, and even in those cases moving the contacts into
> separate devices simplifies implementation.  Though I think that is really a
> tangential discussion (which we may or may not get back too in time, no rush).
> 
> At the moment I'm using the evdev+mtdev driver that Chase composed out of Ben's
> valuator implementation, and its working well.  I like what I've been seeing,
> but it will still be a little while before I update to try out the DID version,
> if you really want my post testing opinion, I will make it a higher priority.
> - From what I've seen, I really don't foresee trouble.
> 
> Just one small point, if you do make these DIDs look more pointer nodes, and we
> can come up with some way to associate them with a more classical device, I'd
> like to see the magic mouse and others also abandon valuators and switch to
> children of the normal mouse.  That just seems to me like a more consistent and
> easier to support approach.

DIDs cannot be associated with traditional X pointers, even though they
may send motion events through XI2. However, in the mixed mode patches I
I made, we can support the magic mouse as a non-DID because it has a
traditional pointer. In this instance, it is assumed that the touch
surface is more of an augmentation of the pointer instead of as a
pointing device itself. Thus, we can attach the device to a master
pointer and clients can grab it.

Thanks,

-- Chase