[PATCH inputproto multitouch] Cater for clients failing to accept/reject ownership
peter.hutterer at who-t.net
Wed Sep 7 18:52:27 PDT 2011
On Wed, Sep 07, 2011 at 10:12:57AM -0700, Chase Douglas wrote:
> 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?
no, please not! if it's configurable, people will start to use and rely on
it. If at all it should be similar to the OOM killer. Unpredictable and the
raison d'être is that it's either the client or the server that goes down.
> 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.
More information about the xorg-devel