[PATCH inputproto multitouch 02/13] TouchOwnership events must precede the events

[Chase Douglas]

On Wed, Aug 24, 2011 at 09:07:12AM +1000, Peter Hutterer wrote:
> For consistency and easier client-handling, the ownership event should be
> before the actual event that marks the first event owned by the client. This
> is already necessary for the TouchEnd event anyway, let's use the same
> approach for TouchBegin and TouchUpdate.
> 
> Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> ---
>  specs/XI2proto.txt |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
> index c91f135..bdbb35f 100644
> --- a/specs/XI2proto.txt
> +++ b/specs/XI2proto.txt
> @@ -322,10 +322,11 @@ To select for touch events regardless of ownership, a client must set the
>  TouchBegin, TouchUpdate and TouchEnd mask. When selected, a client will receive
>  touch events as they occur on the device without delay. If and when the client
>  becomes the owner of a touch sequence, a TouchOwnership event is sent to the
> -client. If the client is the initial owner of the sequence, the TouchBegin is
> -immediately followed by the TouchOwnership event. Otherwise, TouchUpdate events
> -may preceed a TouchOwnership event. A client is not guaranteed to become the
> -owner of any given touch sequence.
> +client immediately before that first owned event. If the client is the
> +initial owner of the sequence, the TouchBegin is preceded by the
> +TouchOwnership event. Otherwise, TouchUpdate events may preceed a
> +TouchOwnership event. A client is not guaranteed to become the owner of any
> +given touch sequence.
>  
>  The server delivers touch events to all clients that have selected for
>  TouchOwnership and to the current owner of the sequence in parallel.

TouchOwnership has always referred to previous and future events in a stream. I
don't see how this makes client side code easier.

I see TouchOwnership as having a symmetry with client side state
creation/destruction. When a TouchBegin comes in, you create a client side
object to track the stream. When a TouchEnd comes in, you destroy the client
side object. With this change, the logic becomes:

on TouchBegin:
  if (touch owned (i.e. saw TouchOwnership))
    update state
  else
    create state

on TouchOwnership:
  if (saw TouchBegin)
    update state
  else
    create state

This adds an extra check for whether to create state, and requires maintaining
state on whether TouchBegin was seen when a TouchOwnership comes in.

-- Chase