[PATCH inputproto 2/2] Add touch classes and events, bump to 2.1

[Peter Hutterer]

On Wed, Dec 22, 2010 at 11:39:34AM +0000, Daniel Stone wrote:
> > mind you, it's not clear from this spec how pointer emulation actually
> > works. is the pointer event generated in parallel to the touch event or only
> > generated and delivered when the respective touch event has been rejected
> > from a client?
> > if it's in parallel, we definitely need to make sure that we generate the
> > releases. as an example case, what happens here:
> > 
> > clients C1 and C2, Root window R, Window hierarchy R - A - B.
> > 
> > * C1 sets touch grab on R
> > * C1 sets touch mask on B
> > * C2 sets pointer pgrab on R
> > * C2 sets pointer mask on A
> > 
> > touch event on B. what events are sent where?
> 
> Yeah, parallel seems like a bit of a minefield.  OTOH, this is so
> terrifyingly complex that I think the best thing to do would be to make
> it implementation-defined, with a suggestion in the proto if we really
> need to document it.  Else I fear we'll be stuck with semantics we hate
> in years to come.

"implementation-defined" means "we couldn't figure it out", which makes it
really hard for clients to rely on a specific behaviour.
leave it as implementation-defined for now (with a big fixme), but I think
we should _really_ figure out the right behaviour and define how touch and
pointer emulation works in a nested hierarchy (with both touch and core
clients).

> > > @@ -1526,6 +1751,17 @@ EVENTHEADER { type:                       BYTE
> > >          KeyRepeat means that this event is for repeating purposes, and
> > >          the physical state of the key has not changed.  This is only
> > >          valid for KeyPress events.
> > > +        TouchPointer means that this event is an emulated pointer event caused
> > > +        by a touch device. A client listening to touch events and pointer
> > > +        events should ignore TouchPointer events to avoid duplicate
> > > +        processing.
> > > +        TouchOwner means that the client is the current owner of the touch.
> > > +        TouchOwnerAccepted (for TouchEnd events only) means that the current
> > > +        owner of the touch stream has “accepted” it, and this client will not 
> > > +        receive any further events from that touch sequence.
> > 
> > can TouchOwnerAccepted be set on TouchMotion events (if a client decides to
> > accept early for a long-lasting touch)? or does the accept generate a
> > TouchEnd event?
> 
> The idea was to only send a TouchEnd event, since that touch is dead
> from the client point of view.  Though, now I think of it, right now we
> send a TouchMotion from the server.

make the server emulate a TouchEnd event with invalid coordinates (as said
below) and write that in here. maybe have a stronger statement for the
TouchEnd, such as "may only be set on TouchEnd events" to avoid confusing
people like me :)

> > > +        TouchPendingFinish means that the touch has physically ended, however
> > > +        another client still holds a grab, so the touch should be considered
> > > +        alive until all grabbing clients have accepted or passed on ownership.
> > 
> > This flag can only be set on a TouchEnd?
> > do we need a flag? isn't this implicit when TouchOwner is not set?
> 
> The idea behind TouchEnd is that it's the final event clients receive,
> and that they can clean up all state for that touch as soon as they get
> it.  So, TouchPendingFinish arrives in a TouchMotion event with zero
> valuators.

ah, I didn't notice that when reading the spec. this needs to be explicitly
stated somewhere. (bikeshed: TouchPendingFinish → TouchTerminated?)
is it worth adding another event type for TouchEnd (physical end) and
TouchTerminated (for actual end)?

Cheers,
  Peter