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

[Daniel Stone]

On Thu, Dec 23, 2010 at 10:04:09AM +1000, Peter Hutterer wrote:
> On Wed, Dec 22, 2010 at 11:39:34AM +0000, Daniel Stone wrote:
> > 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).

Yep, I've no problem with that, I just really don't want to rush into
specifying behaviour for the sake of it, lest we specify something
really awkward and inconvenient for clients that we can't subsequently
change.

> > > 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)?

Sure, that's fine.  The name is awkward (I tried to come up with a
better one, but failed), but I think that End/Terminated is more
confusing still.  Maybe TouchLifted or TouchContactEnded or something?
Either way, if we're adding a new event type for this, then we should
really add a new event type for ownership changes too, and that could
get messy.  I think the simplicity of the existing three events works
OK.  After all, PendingFinish doesn't mean anything more than 'you won't
get any more valuators from this touch'.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101223/af806a81/attachment.pgp>