[PATCH] Add touch events to protocol.

[Chase Douglas]

On 07/07/2011 09:52 AM, Kristian Høgsberg wrote:
> 2011/7/7 Chase Douglas <chase.douglas at canonical.com>:
>> On 07/07/2011 07:28 AM, Kristian Høgsberg wrote:
>>> On Tue, Jul 5, 2011 at 1:08 PM, Chase Douglas
>>> <chase.douglas at canonical.com> wrote:
>>>> On 06/29/2011 07:54 AM, Laszlo Agocs wrote:
>>>>> +
>>>>> +    <!-- Indicates the end of a contact point list. -->
>>>>> +    <event name="touch_frame">
>>>>> +    </event>
>>>>> +
>>>>> +    <!-- Sent if the compositor decides the touch stream is a global
>>>>> +         gesture. No further events are sent to the clients from that
>>>>> +         particular gesture. -->
>>>>> +    <event name="touch_cancel">
>>>>> +    </event>
>>>>>     </interface>
>>>>
>>>> I never understood the concept behind "touch cancel". If I'm a client,
>>>> I'm supposed to sit around waiting for a touch cancel event at any
>>>> point? Is it bounded in time, or could I get a touch cancel event 20
>>>> seconds into a stream of motion events? I don't see a way to get around
>>>> explicitly conferring whether a touch  is "accepted" or "rejected"
>>>> (implicitly or explicitly) at some point, which is what XInput 2.1 is
>>>> aiming to do. However, the exact mechanisms may be different in Wayland
>>>> since we don't have the old X cruft to deal with.
>>>
>>> Yes, any stream of touch event, no matter how long, can be cancelled
>>> by the compositor at any time.  The use cases are when the compositor
>>> recognizes a global gesture (three finger pinch to go to home screen
>>> or so) or if an important system event happens (incoming phone call or
>>> such).
>>>
>>> Whether and how to undo the effects of the touch events up until the
>>> cancel is an application policy decision.  If you're just scrolling a
>>> browser window, it probably doesn't make sense to undo the scrolling.
>>> Even if you're, say, painting in a paint app, it probably makes sense
>>> to just treat cancel as end and commit the paint action, provided the
>>> user can just undo that if necessary.
>>
>> I think undoing automatically would be better, but I'm not a paint app
>> developer, and it's beside the point :).
>>
>>> In general, undoing the touch stream is similar to undo, which most
>>> apps are already handling.  From an application point of view, if you
>>> have to handle unowned events (that's the XI 2.1 term, right?) for a
>>> small initial window (100ms, 3s or a week), you end up with the same
>>> application side complexity, and I don't see what it is apps can do
>>> differently once they know that the remaining event stream belongs to
>>> them.
>>
>> Lets say the WM responds to a short flick gesture. The user performs the
>> entire gesture before the WM has decided whether it matches the flick
>> pattern. Now we've sent the touch stream in its entirety to the wayland
>> client, and we have to cancel it after the fact.
>>
>> This leaves the client in a precarious situation. It has received the
>> entire stream of touch events for a touch, but it doesn't yet know if
>> the stream might be cancelled or not. The client may be buffering the
>> application state so it can undo changes if it receives a touch cancel.
>> We don't want to force it to buffer state changes forever, so we must
>> provide some guidance to developers on how to handle this situation. Do
>> we say that after 1 s the client can assume the touch stream is theirs?
>> That's hackish and may produce annoying side effects if the machine is
>> swapping and goes "dead" for a few seconds.
> 
> The touch stream ends with either 1) all touch points up or 2) touch
> cancel.  If the application receives up events for corresponding to
> all touch down events, the touch stream belongs to the client.

What do we do when the user performs a one finger flick and the flick
hasn't been recognized until the touch end (one definition of flick is
if the final velocity at touch end is above a certain threshold)? Do we
withhold the touch end event from the client until we are sure?

If we withhold the touch end event, we should at least send a touch
update event to describe the location of the touch end event (if
different than the previous event). If you do that, then the touch end
event is the same as a touch ownership event, as it only conveys the
fact that the client now owns the touch stream.

At best we can eliminate one event, the touch ownership-like event, if
the compositor is certain before the touch stream ends that the stream
does not comprise a compositor gesture. The trade-off for potentially
saving one event is we are forcing clients to assume a touch stream can
be canceled at any time, which may be a burden for a very long touch stream.

-- Chase