[PATCH v6 inputproto 1/1] Multitouch updates for pointer emulation

[Chase Douglas]

On 03/02/2011 06:29 AM, Daniel Stone wrote:
> Hi,
> 
> On Wed, Mar 02, 2011 at 04:34:30PM +1000, Peter Hutterer wrote:
>> On Tue, Feb 08, 2011 at 10:53:19AM +0000, Daniel Stone wrote:
>>> --- a/XI2.h
>>> +++ b/XI2.h
>>> @@ -67,6 +67,7 @@
>>>  #define XIGrabtypeEnter                         2
>>>  #define XIGrabtypeFocusIn                       3
>>>  #define XIGrabtypeTouchBegin                    4
>>> +#define XIGrabtypeTouchBeginInert               5
>>
>> I'm struggling to come up with a better name but I'm not sure Inert is the
>> best option here.
> 
> I thought of a better name on the way to the train, and then forgot it.
> Ugh.
> 
> Oh! 'Observer'?
> 
>>> @@ -83,8 +84,8 @@
>>>  
>>>  /* XIAllowTouchEvents bitmask event-modes */
>>>  #define XITouchOwnerAccept                      (1 << 0)
>>> -#define XITouchOwnerReject                      (1 << 1)
>>> -#define XITouchNoPointerEmulation               (1 << 2)
>>> +#define XITouchOwnerRejectEnd                   (1 << 1)
>>> +#define XITouchOwnerRejectContinue              (1 << 2)
>>
>> just thinking aloud: XITouchOwnerReject and XITouchOwnerPass?
>> or XITouchOwnerIgnore and XITouchOwnerPass?
>>
>> also, after 10 minutes of reading this over and over I found what was
>> bothering me. We have XIGrabtypeTouchBeginInert for the grab type to get the
>> behaviour that XITouchOwnerRejectContinue gives us too. these two need to be
>> consistently named. to go with my suggestions from above:
>> XIGrabtypeTouchBeginPass and XITouchOwnerPass?
> 
> How about TouchBeginObserve and TouchOwnerObserve? I'm sure we could do
> better, but it's a start.
> 
>> Chase, this should also clarify your comment here. Inert isn't a new event
>> type it's a grab on touch with an automatic RejectContinue if the grab
>> activates.
> 
> Yep, just avoids a round trip.
> 
>>> +        TouchAccepted (for TouchEnd events only) means that the current owner
>>> +        of the touch stream has “accepted” it, and this client will not receive
>>> +        any further events from that touch sequence.
>>
>>
>> thinking about this again, it leaves us with a strange situation for
>> RejectContinue:
>> Given the window hierarchy A being parent of B being parent of C and touch
>> grabs by different clients on all three.
>>
>> Touch starts
>>   * TouchBegin + TouchUpdate to A
>>   * TouchBegin + TouchUpdateUnowned to B and C
>>
>> RejectContinue on A
>>   * TouchUpdateUnowned to A
>>   * TouchOwner + TouchUpdate to B
>>   * TouchUpdateUnownd to C
>>
>> Accept on B
>>   * * TouchUpdateUnowned to A, or
>>     * TouchUpate(End) to A
>>   * TouchUpdate + eventual TouchEnd to B
>>   * TouchUpdate(End) to C
>>
>>
>> so depending on what we do with A, we have the two different scenarios:
>> - if we keep sending events to A, this means that you can only do touch
>>   event monitoring (such as for the visual feedback) you're on top of all
>>   other windows. all clients will thus race to the top and compete there
>>   (only one client can select on a window, right?)
>> - if we stop sending events to A, then exactly the features this would allow
>>   aren't possible (and GrabtypeInert/RejectContinue becomes rather pointless)
>>
>> The only solution seems to be  keep sending UpdateUnowned events regardless
>> of the "accept" status. this needs to be worked into the text.
> 
> Oh, ugh.  I think we should do the observer rename, and state that
> observer grabs, or grabs where ownership has been passed on with
> TouchOwnerObserve, will always receive all events between the first
> TouchBegin sent to any client, and the last TouchEnd.
> 
> Does that sound OK?
> 
>>> +    other grabs (including device freezing), although any pointer events
>>> +    generated by emulation will still be subject to all the same constraints
>>> +    as normal pointer events, including enter/leave events, and being affected
>>> +    by frozen devices.
>>
>> btw, what will get really interesting is if you have a confine_to window
>> involved. I think the best solution here is to simply state that confine_to only
>> affects pointer emulation but not touch events.
> 
> Yeah, I'll be more explicit about that.
> 
>> I think this looks good, but by now my head is rather spinning.
> 
> Thanks, I'll sort all those out for the next revision I send out.

Everything stated here sounds good to me too.

-- Chase