New approach to multitouch using DIDs and bitmasked events

[Chase Douglas]

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.

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

-- Chase