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

[Daniel Stone]

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.

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

> > +    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
-------------- 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/20110302/0aa62f9e/attachment.pgp>