[PATCH inputproto multitouch] Cater for clients failing to accept/reject ownership

[Chase Douglas]

On 08/31/2011 12:11 PM, carlosg at gnome.org wrote:
> From: Carlos Garnacho <carlosg at gnome.org>
> 
> The multitouch protocol definition largely assumed well behaved
> clients, and had no way to deal with misbehaved ones that wouldn't
> claim nor deny ownership on the sequence.
> 
> So, introduce the TouchExpired flag, to be used by the server when
> forcing touch sequences to expire after being unhandled for some
> time. The correct behavior is also emphasized in the spec.
> 
> Signed-off-by: Carlos Garnacho <carlosg at gnome.org>
> ---
>  XI2.h              |    1 +
>  specs/XI2proto.txt |    9 +++++++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/XI2.h b/XI2.h
> index 2aea35e..7a38ede 100644
> --- a/XI2.h
> +++ b/XI2.h
> @@ -160,6 +160,7 @@
>  #define XITouchPendingEnd                       (1 << 16)
>  #define XITouchCanceled                         (1 << 17)
>  #define XITouchResumed                          (1 << 18)
> +#define XITouchExpired                          (1 << 19)
>  
>  /* Touch modes */
>  #define XIDirectTouch                           1
> diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
> index 2a96162..9bf53d7 100644
> --- a/specs/XI2proto.txt
> +++ b/specs/XI2proto.txt
> @@ -310,7 +310,10 @@ has not accepted or rejected ownership, the client receives a TouchUpdate event
>  with the TouchPendingEnd flag set, but must still accept or reject the sequence
>  nonetheless. If the owner rejects the touch sequence, the server will still
>  attempt to exhaust all other passive grabs and/or event selections looking for
> -a final owner.
> +a final owner. If the client fails to either accept or reject ownership on the
> +touch sequence, the server may finally dispose it after a reasonable timespan,
> +in that case the last owner of the sequence will receive a TouchEnd event with
> +the TouchExpired flag set.

There are three issues I see with this:

1. What is a reasonable timeout? Should it be configurable?

2. This introduces indeterminate behavior. If the timeout is 0.5 s (just
throwing it out there, I don't know if it's reasonable or not), someone
with a fast machine may never see a touch expire, but someone with a
slow/swapping machine may see all kinds of expired touches.

3. It papers over the real bug in the client holding up ownership
propagation. The most annoying bugs tend to get fixed first, and if you
can't use your desktop because your WM isn't rejecting touches then the
WM is likely to get fixed real quick :).

Issue 3 is the big one for me. Even if you put in some expiration timer,
the experience will still feel awful. Adding this to the spec would
complicate the protocol and implementation just so the server can limp
along until the buggy client is patched. I'm not sure the cost/benefit
ratio of maintaining this part of the protocol would be worth it.

-- Chase