[PATCH v6 inputproto 1/1] Multitouch updates for pointer emulation
peter.hutterer at who-t.net
Wed Mar 2 22:13:24 PST 2011
On Wed, Mar 02, 2011 at 11:29:22AM +0000, Daniel Stone wrote:
> 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.
> 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.
> > > + 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.
More information about the xorg-devel