New approach to multitouch using DIDs and bitmasked events

[Rafi Rubin]

On 07/03/2010 02:07 PM, Chase Douglas wrote:
> 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.

Never assumed we'd use 0 valuators, but I misunderstood the point of using a 
single device.  Certainly this seems quite efficient and minimally perturbs the 
code both in the input driver and the clients.

Sorry to have missed the cleverness of your solutions.  Sometimes its hard to 
see something when you have two other pictures in your mind.  Thanks for clarifying.


Yes, this approach is also quite safe with regards to the devices that I've been 
using.

>> 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.

Since, I seem to have missed some of the nuance of this discussion, I'd like to 
ask for clarification.  If the mt events are coming down axes that core ignores, 
why make the distinction?