[PATCH 4/5] Implement early touch reject

[Chase Douglas]

On 02/03/2012 09:07 AM, Peter Hutterer wrote:
> On Fri, Feb 03, 2012 at 06:42:02AM +0100, Chase Douglas wrote:
>> On 02/03/2012 06:40 AM, Peter Hutterer wrote:
>>> On Thu, Feb 02, 2012 at 04:57:57PM -0800, Chase Douglas wrote:
>>>> From: Chase Douglas <chase.douglas at ubuntu.com>
>>>>
>>>> Signed-off-by: Chase Douglas <chase.douglas at canonical.com>
>>>> ---
>>>>  dix/touch.c |    9 ++++++++-
>>>>  1 files changed, 8 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/dix/touch.c b/dix/touch.c
>>>> index e24d9ac..1faeb7c 100644
>>>> --- a/dix/touch.c
>>>> +++ b/dix/touch.c
>>>> @@ -1019,9 +1019,16 @@ AllowTouch(ClientPtr client, DeviceIntPtr dev, int mode, uint32_t touchid,
>>>>      if (i < ti->num_listeners)
>>>>          return BadAccess;
>>>>  
>>>> -    /* FIXME: Implement early accept/reject */
>>>>      if (i > 0)
>>>> +    {
>>>> +        if (mode == XIRejectTouch)
>>>> +        {
>>>> +            TouchRemoveListener(ti, ti->listeners[i].listener);
>>>> +            return Success;
>>>
>>> We need to send a TouchEnd to the listener before we remove it.
>>
>> No, that's how the protocol was written originally. You changed that :).
>> Now, when a client rejects it is done with the touch sequence. It is not
>> guaranteed to receive a TouchEnd event.
> 
> 
> not quite. from the spec:
> RejectTouch
>   The client is no longer interested in the touch sequence,
>   and will receive a TouchEnd event. If the client is the current
>   owner of the sequence, ownership will be passed on to the next
>   listener.
> 
> It think you might be referring to inputproto-2.1.99.4-1-g9611be0, which
> doesn't cover the same use-case:
>     specs: Clarify rejection for touch events on current owner
> 
>     The current owner never gets a TouchUpdate(PendingEnd), that event
>     is superfluous for the owner. The owner receives a TouchEnd when
>     the touch physically ends. If the touch is still active, the
>     owner receives a TouchEnd after rejecting the touch.
> 
> The sequence is always Begin/Update/End, so we need to send an End event
> once rejected.

Ahh, yes, you're right :). I'll fix this up.

-- Chase