multitouch

[Daniel Stone]

On Mon, Mar 01, 2010 at 04:25:48PM +0300, Artem Ananiev wrote:
> On 3/1/2010 3:41 PM, Daniel Stone wrote:
>> On Mon, Mar 01, 2010 at 12:42:40PM +0100, Bradley T. Hughes wrote:
>>> On 03/01/2010 12:22 PM, ext Daniel Stone wrote:
>>>> and so on, and so forth ... would this be useful enough to let you take
>>>> multi-device rather than some unpredictable hybrid?
>>>
>>> It would for me, absolutely. This avoids the multi-device grab problem
>>> described by Peter earlier, but I'm unsure how well it works given that
>>> we still lack the user/gesture context (as described by Peter).
>>
>> Any suggestions? :) Reference to how OS X and/or Windows implement it
>> would be welcome too.
>
> In a few words, Windows expects all the subsequent touch events to occur  
> on the same window as the first touch. If I press another window, the  
> corresponding WM_TOUCH notification is just skipped - not sent to the  
> client. I'm not sure about explicit mouse grab (SetCapture() call), 
> though.

And from the NSTouch (OS X) class documentation:
    Touches do not have a corresponding screen location. The first touch
    of a touch collection is latched to the view underlying the cursor
    using the same hit detection as mouse events.  Additional touches on
    the same device are also latched to the same view as any other
    touching touches.  A touch remains latched to its view until the
    touch has either ended or is cancelled.

I think we're pretty much stuffed trying to define any other semantics,
at least right now.  The biggest problem I can think of is that we don't
know when someone's going to want to intercept the gestures from other
touchpoints on the same device, without forwarding them the grabbed
events.  Even that falls apart pretty quickly: imagine I've got two
fingers down on the same device, which have been declared to be
independent presses (say one's on the volume applet, and one's on an
application somewhere).  What happens when I put a third finger down:
do I forward the third touch to the owner of the volume applet or the
application for processing, or both (and then, in which order)? Closest
to the pin? Most closely-related window wins?

Leaving it up to the client to grab when necessary is always going to
involve a race, and we'll always lose at some point.  We can't really
properly fix this until, er, Wayland.  If ever. :)

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100301/b4d666c7/attachment.pgp>