New approach to multitouch using DIDs and bitmasked events

[Rafi Rubin]

On 07/05/2010 12:54 PM, Chase Douglas wrote:
> On Mon, 2010-07-05 at 12:26 -0400, Rafi Rubin wrote:
>>>> 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?
>
> I'm not sure I follow your question completely. I've rephrased your
> question to what I think you mean and answered it.
>
> If X core ignores MT valuators, why bother with DIDs?
>
> (Even this doesn't quite make sense once you understand the answer)
>
> The problem comes from the fact that the first two valuators of a
> pointer device are assumed by the server to be the X and Y pointer
> coordinates (relative or absolute). If a device is pure multitouch (i.e.
> not a magicmouse), we still want the first two valuators to be the X and
> Y coordinates of each touch, but we don't want them to be handled by the
> server as though they were traditional X core motion events. Otherwise,
> we'd have the following:
>
> Event: (from touch 0)
> 	X
> 	Y
> 	Slot ID
> Event: (from touch 1)
> 	X
> 	Y
> 	Slot ID
>
> If these were passed through X core, the server would think the mouse
> pointer is flickering back and forth between the two touch coordinates.
> The solution is to "float" the input device so it's not tied to a master
> pointer.

Ok, didn't realize it made that assumption.

We could use vestigial valuators :)

Just a dummy X/Y that we could ignore, or if you prefer use while only 1 contact 
is active.  I know that eventually we should pull the conventional valuators 
eventually (doesn't scale to multi-user sessions, grabs....), but for now it 
seems like a cheap solution to a decent user experience in the near future.

> The reason we can't pass DIDs as XI1 events is because an XI1 client
> also doesn't see "floating" input devices that aren't attached to master
> pointers. Only XI2 can see events from "floating" input devices.

Would vestigial valuators enable us to support XI1?  Do we care about XI1?

> Now, in the magicmouse case, X core does ignore MT valuators. However,
> in this case we actually have a real pointing device giving valid
> relative pointer coordinates through X core. It's very much a different
> type of device, compared to a pure multitouch touchpad, with a separate
> set of meanings attached to pointer and touch coordinates.

Still considering the difference between the way I want to use (assuming I knew 
nothing and walked up to computers with each to play) a magic mouse and a MT 
trackpad on a laptop.  The biggest difference I see is that I'd like single 
finger motion on the trackpad to move the cursor.  But in both cases, I'd expect 
MT commands to follow the cursor.


We should convince someone to emulate a mm like device using a pointer stick, 
and treating the keys as a MT sensors :)

Rafi