[PATCH v6 inputproto 1/1] Multitouch updates for pointer emulation

[Peter Hutterer]

On Wed, Mar 02, 2011 at 11:29:22AM +0000, Daniel Stone wrote:
> Hi,
> 
> On Wed, Mar 02, 2011 at 04:34:30PM +1000, Peter Hutterer wrote:
> > On Tue, Feb 08, 2011 at 10:53:19AM +0000, Daniel Stone wrote:
> > > --- a/XI2.h
> > > +++ b/XI2.h
> > > @@ -67,6 +67,7 @@
> > >  #define XIGrabtypeEnter                         2
> > >  #define XIGrabtypeFocusIn                       3
> > >  #define XIGrabtypeTouchBegin                    4
> > > +#define XIGrabtypeTouchBeginInert               5
> > 
> > I'm struggling to come up with a better name but I'm not sure Inert is the
> > best option here.
> 
> I thought of a better name on the way to the train, and then forgot it.
> Ugh.
> 
> Oh! 'Observer'?
> 
> > > @@ -83,8 +84,8 @@
> > >  
> > >  /* XIAllowTouchEvents bitmask event-modes */
> > >  #define XITouchOwnerAccept                      (1 << 0)
> > > -#define XITouchOwnerReject                      (1 << 1)
> > > -#define XITouchNoPointerEmulation               (1 << 2)
> > > +#define XITouchOwnerRejectEnd                   (1 << 1)
> > > +#define XITouchOwnerRejectContinue              (1 << 2)
> > 
> > just thinking aloud: XITouchOwnerReject and XITouchOwnerPass?
> > or XITouchOwnerIgnore and XITouchOwnerPass?
> > 
> > also, after 10 minutes of reading this over and over I found what was
> > bothering me. We have XIGrabtypeTouchBeginInert for the grab type to get the
> > behaviour that XITouchOwnerRejectContinue gives us too. these two need to be
> > consistently named. to go with my suggestions from above:
> > XIGrabtypeTouchBeginPass and XITouchOwnerPass?
> 
> How about TouchBeginObserve and TouchOwnerObserve? I'm sure we could do
> better, but it's a start.

I had to read this thrice to see the difference between
Touch>>Begin<<Observe and Touch>>Owner<<Observe. This is bound to be a
source of bugs. However, I am partial towards TouchReject and TouchObserve.
Observe is definitely a good name for this approach.

which brings me to the next thing - s/Owner// in the defines above?

> > Chase, this should also clarify your comment here. Inert isn't a new event
> > type it's a grab on touch with an automatic RejectContinue if the grab
> > activates.
> 
> Yep, just avoids a round trip.
> 
> > > +        TouchAccepted (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.
> > 
> > 
> > thinking about this again, it leaves us with a strange situation for
> > RejectContinue:
> > Given the window hierarchy A being parent of B being parent of C and touch
> > grabs by different clients on all three.
> > 
> > Touch starts
> >   * TouchBegin + TouchUpdate to A
> >   * TouchBegin + TouchUpdateUnowned to B and C
> > 
> > RejectContinue on A
> >   * TouchUpdateUnowned to A
> >   * TouchOwner + TouchUpdate to B
> >   * TouchUpdateUnownd to C
> > 
> > Accept on B
> >   * * TouchUpdateUnowned to A, or
> >     * TouchUpate(End) to A
> >   * TouchUpdate + eventual TouchEnd to B
> >   * TouchUpdate(End) to C
> > 
> > 
> > so depending on what we do with A, we have the two different scenarios:
> > - if we keep sending events to A, this means that you can only do touch
> >   event monitoring (such as for the visual feedback) you're on top of all
> >   other windows. all clients will thus race to the top and compete there
> >   (only one client can select on a window, right?)
> > - if we stop sending events to A, then exactly the features this would allow
> >   aren't possible (and GrabtypeInert/RejectContinue becomes rather pointless)
> > 
> > The only solution seems to be  keep sending UpdateUnowned events regardless
> > of the "accept" status. this needs to be worked into the text.
> 
> Oh, ugh.  I think we should do the observer rename, and state that
> observer grabs, or grabs where ownership has been passed on with
> TouchOwnerObserve, will always receive all events between the first
> TouchBegin sent to any client, and the last TouchEnd.
> 
> Does that sound OK?

yes, that makes sense.

Cheers,
  Peter

> > > +    other grabs (including device freezing), although any pointer events
> > > +    generated by emulation will still be subject to all the same constraints
> > > +    as normal pointer events, including enter/leave events, and being affected
> > > +    by frozen devices.
> > 
> > btw, what will get really interesting is if you have a confine_to window
> > involved. I think the best solution here is to simply state that confine_to only
> > affects pointer emulation but not touch events.
> 
> Yeah, I'll be more explicit about that.
> 
> > I think this looks good, but by now my head is rather spinning.
> 
> Thanks, I'll sort all those out for the next revision I send out.
> 
> Cheers,
> Daniel