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

[Daniel Stone]

Hi,
Thanks for all the review!

On Wed, Dec 22, 2010 at 01:57:14PM +1000, Peter Hutterer wrote:
> On Fri, Dec 17, 2010 at 05:11:10PM +0000, Daniel Stone wrote:
> > @@ -1308,6 +1490,37 @@ are required to be 0.
> >          deleted from the device, and a XIPropertyNotify event is generated on
> >          the device.  
> >       
> > +    ┌───
> > +        XIAllowTouchEvents: (since XI 2.1)
> > +            deviceid:        DEVICEID
> > +            touchid:         CARD32
> > +            event_mode:      CARD8
> > +    └───
> > +
> 
> event_mode should be a SETofALLOWMODES, with the allow modes specified here.

No problem.

> > +    The XIAllowTouchEvents request allows the current owner of a touch
> > +    sequence to direct further delivery.
> > +
> > +    deviceid
> > +        The grabbed device ID.
> > +    touchid
> > +        The ID of the currently-grabbed touch sequence.
> > +    event_mode
> > +        A bitmask of event modes for future delivery:
> > +        If TouchOwnerAccept is set, the client is deemed to have taken control
> > +        of the touch sequence, and no further events will be sent to any other
> > +        clients for this touch sequence.  Additionally, if
> > +        TouchNoPointerEmulation is set, then no more emulated pointer events
> > +        will be generated from this touch sequence.  
> 
> this needs clarification. if a button press has been generated as result of
> this sequence, the Accept must fake the release. otherwise, we end up with
> stuck buttons.

Good point; mind you, this might cause false drags, so we might need to
say instead that pointer emulation doesn't begin until the touch has
been definitively accepted/rejected by all grab owners.

> 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.

> > @@ -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.

> what is the value of the remaining data if TouchOwnerAccepted is set? the
> last value of the touch? or is the data invalid (or zeroed)?

Invalid/MBZ.  I'll document that.

> > +        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.

> >      Modifier state in mods is detailed as follows:
> >      base_mods
> > @@ -1543,6 +1779,25 @@ EVENTHEADER { type:                       BYTE
> >      locked_group
> >          XKB locked group state.
> >  
> > +    XI 2.1:
> > +
> > +    A TouchBegin event is generated whenever a new touch sequence initializes
> 
> period missing at the end of the sentence.

Thanks.

> > @@ -1675,3 +1930,29 @@ EVENTHEADER { type:                       BYTE
> >       
> >  
> >                                ❧❧❧❧❧❧❧❧❧❧❧
> > +
> > +
> > +Appendix A: XI 2.1 Use-cases
> > +
> > +All use-cases that include the receiving and processing of touch events
> > +require the client to announce XI 2.1 support in the XIQueryVersion request.
> > +
> > +XXX: Add grab usecases.
> 
> yes, please :)
> 
> there's two comments I have about this:
> - whether we'll need the per-axis mode for touch events. I'm ok with leaving
>   it out for now though

Yeah, I'm happy to leave it out until we get a properly-articulated
usecase for them.

> - the pointer emulation bit is really unclear. I haven't looked at the
>   server patches in detail yet (the spec should speak for itself).
>   a quick glance of patch xserver 08/10 shows that emulate_pointer is a
>   write-only field.

Yep.  I haven't tried to implement pointer emulation because it's a
minefield, and any semantics I've come up with thus far are trivially
broken.  Any thoughts there welcome ...

> other than that - looks good. I think this should get us somewhere.

:)

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/20101222/ffbb098f/attachment.pgp>