New approach to multitouch using DIDs and bitmasked events

[Rafi Rubin]

On 07/05/2010 01:31 PM, Chase Douglas wrote:
> On Mon, 2010-07-05 at 13:20 -0400, Rafi Rubin wrote:
>> 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.
>
> We actually want X to handle the first two valuators for us as though
> they were pointer coordinates. X takes these first two valuators and
> translates them to screen coordinates,which then become the root
> coordinates of the event. These root coordinates are used for event
> propagation. Thus, we can use the same infrastructure as traditional
> pointers for event propagation by placing the MT coordinates first.
> Defining the device as a DID just ensures we don't send the events as
> though they were real pointers.

Ok, another fine point I missed.  So you will have a pair of conventional X/Y 
which are determined somehow.  You just don't want to use them for core events.

>>> 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?
>
> Heh, I feel like we're returning to the conversation I had with Peter
> about legacy client support. Essentially, you need XI2 for multitouch,
> and the toolkit layer should use XI2 and translate to toolkit events as
> required. XI1 just isn't extensible enough for multitouch.

Yup, I was thinking of what you said before with something watching all the MT 
contacts moving around and producing conventional pointer events where they are 
needed.  It sounds like a great idea.

However, it is yet another obstacle in the path of getting MT to the X desktop. 
  When you say toolkit, I hope you mean just some separate piece of code, and 
not requiring gtk/qt to get conventional pointer events.  I'd hate to loose 
support for some real legacy apps (which I actually use for my work), where it 
really is standard X events or nothing (programs written in straight xlib, 
statically compiled, obscure toolkits, etc).

Rafi