multitouch

Daniel Stone daniel at fooishbar.org
Mon Mar 1 03:22:53 PST 2010


Hi,

On Mon, Mar 01, 2010 at 11:50:49AM +0100, Bradley T. Hughes wrote:
> On 02/27/2010 02:25 PM, ext Matthew Ayres wrote:
>> The impression I get from reading through this thread is that the
>> simplest (and therefore possibly best) approach to grouping touch
>> events is to group them according to which X window they intersect.
>> That is, where a second touch event takes place in the same window as
>> the first, it is part of the same master device; where it takes place
>> elsewhere, it is another master device.  I'm not sure why this would
>> not be a useful assumption.
>
> I like this idea (and this is similar what I did in Qt when trying to  
> determine context for a touch-point), the only concern is that Peter and  
> others have comment on how expensive it is to add/remove master devices.

Not to mention the deeply unpleasant races -- unless you grab
XGrabServer, which is prohibitively expensive and extremely anti-social.

If you really need multiple devices, how hard is it to group events
together when they come from separate devices? I'm guessing it can't be
that hard: you'd be tracking _less state_, and it'd be _more
predictable_.  How a hybrid system is easier for anyone is honestly
beyond me, but hey.

I still think a multi-level device hierachy would be helpful, thus
giving us 'subdevice'-alike behaviour.  So if we were able to go:
MD 1 ->
        Touchpad 1 ->
                      Finger 1
                      Finger 2
        Wacom 1 ->
                   Pen 1
                   Eraser 1
MD 2 ->
        Touchpad 2 ->
                      Finger 1

and so on, and so forth ... would this be useful enough to let you take
multi-device rather than some unpredictable hybrid?

(What happens in the hybrid system when I get an event from finger 1,
decide I like it, take out a grab, and then finger 2 presses on another
window.  Do I respect the event and give the app the finger 2 press it
likely doesn't want, or break the grab and deliver it to another client?
Neither answer is pleasant.)

>> Here comes my arrogant proposal:  Suppose that the client application
>> determines, from a given gesture, that actually the new slave/whatever
>> is trying to act as a separate master.  I think it would be useful to
>> provide a mechanism for the application to tell the server that and to
>> request that the slave be detached and created a new master.  Some
>> negotiation would be needed of course, but it would be useful (for
>> instance) if it turns out to be a second user trying to drag something
>> from another user's window.  So what I imagine would go something like
>> this:
>>
>> Touch1 in WindowA (ApplicationX) = MD1 + SD1.
>> Touch2 in WindowA (ApplicationX) = MD1 + SD2.
>> ApplicationX determines that Touch2 wants to do something of its own.
>> ApplicationX tells Xserver to make Touch2 into MD2 + SD1.
>
> This is probably possible just by using the techniques described by Peter 
> at http://who-t.blogspot.com/2009/06/xi2-recipies-part-2.html

Rather.

>> So my apologies for butting in like that, but I felt I might as well
>> say something.
>
> There's no need to apologize, is there? Discussions in the open like this 
> are done for exactly this reason, to invite input from others.

Indeed. :)

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/ef8c6028/attachment.pgp>


More information about the xorg-devel mailing list