[PATCH inputproto xi 2.1] Updates for pointer emulation and more touch device modes

[Chase Douglas]

On 03/02/2011 06:34 AM, Daniel Stone wrote:
> Hi,
> 
> On Wed, Mar 02, 2011 at 10:58:08AM +0000, Daniel Stone wrote:
>> On Tue, Feb 22, 2011 at 10:06:37AM -0500, Chase Douglas wrote:
>>> +In order to prevent touch events delivered to one window while pointer events
>>> +are implicitly grabbed by another, all touches from indirect devices will end
>>> +when an implicit grab is activated on the slave or attached master device. New
>>> +touches may begin while the device is implicitly grabbed.
>>
>> This bit makes me _nervous_.  Unfortunately we can only activate one
>> pointer grab at a time, but I'd rather do something like this:
>>     * populate the window set with the pseudocode described near the top
>>       when the touch begins, regardless of the pointer state
>>     * generate touch events as normal
>>     * if ownership is passed to a pointer grab/selection, skip it if
>>       a pointer grab is already active on the delivering device (the MD
>>       if the selection was on the MD ID or XIAllMasterDevices, otherwise
>>       the SD)
> 
> Let me clarify a bit.  Assume we have the following scenario:
> * root window R, touch grab by gesture recogniser
>   * window manager frame window W, pointer button 1 grab for
>     click-to-raise
>     * client window C, touch selection
> 
> If we do a two-finger scroll on C, we'll get the following:
>   - touch 1 down, owned by R
>   - touch 2 down, owned by R
>   - touch 1 rejected by R, ownership passed to W, touch 2 ended before R
>     can reject it!
>   - touch 1 rejected by W, ownership passed to C
>   - touch 1 physically ends
>   - touch 2 physically ends
> 
> This means C will never see the scroll.  If we just ignore the pointer,
> we will skip straight from R to C if R rejects it: if C selects for
> unowned events, it will at least know that touch 1 is still owned by
> someone above it in the window tree who hasn't decided what to do with
> it yet, and can wait to perform gesture recognition.

This isn't correct.

First, lets take the case where C is selecting for unowned events. It
will receive a begin event for touch 2 when the touch physically begins,
and then update unowned events as soon as they are generated. When the
touch ends, it receives an update unowned event with a pending finish
flag. When R rejects the touch (it *always* must accept or reject a
touch, even if the touch has already ended), ownership passes to C (this
touch isn't pointer emulated, so W isn't in the way). C gets a touch
ownership event and then a touch end event. It's received the entire
stream and can handle the scroll event.

Second, lets take the case where C is selecting only for owned events.
No events are sent to C until R rejects the touch. When R rejects the
touch, C becomes the new owner. Now, the server replays the touch events
from the touch's buffer. C receives a touch begin event, then some touch
update events, then a touch end event. Again, C has received the entire
touch stream for the second touch.

-- Chase