[PATCH inputproto xi 2.1] Updates for pointer emulation and more touch device modes

[Peter Hutterer]

On Fri, Mar 11, 2011 at 11:28:11AM -0500, Chase Douglas wrote:
> On 03/11/2011 12:15 AM, Peter Hutterer wrote:
> > On Thu, Mar 10, 2011 at 03:39:18PM -0500, Chase Douglas wrote:
> >> On 03/08/2011 11:59 PM, Peter Hutterer wrote:
> >>> On Tue, Mar 08, 2011 at 10:24:42AM -0500, Chase Douglas wrote:
> >>>> On 03/08/2011 12:41 AM, Peter Hutterer wrote:
> >>>>> On Wed, Mar 02, 2011 at 11:35:41AM -0500, Chase Douglas wrote:
> >>>>>> On 03/02/2011 05:58 AM, Daniel Stone wrote:
> >>>>>>> On Tue, Feb 22, 2011 at 10:06:37AM -0500, Chase Douglas wrote:
> > [...]
> >> I don't think it's a bug either. The X server runs as a process. The
> >> latency between when an event physically occurs and when the server
> >> handles the event includes an irq context switch, kernel/userspace
> >> context switch, scheduling delays, and then signal context switch
> >> (hopefully this is eliminated with the threaded I/O work). 
> > [...]
> >> In contrast, the Linux input system sets the evdev event timestamp to
> >> the current kernel time when the event is generated in irq context.
> > [...]
> > 
> > and we can't pass the timestamp from the event with the event itself?
> > something like xf86PostMotionEvent(device, timestamp, mask); and then
> > convert the stamp to server time.
> 
> Good idea :). I'd propose leaving the conversion from device time to
> server time in the input module, and adding the argument only on the end
> of the xf86Post*EventM functions so we don't have to fix up every
> xf86Post* call in the old modules. Sound good?

both make sense yes.

> >>>>> I guess daniel meant s/removed/reattached/, not as in "unplugged". But you
> >>>>> answered the question, a client registering for touch events must re-select
> >>>>> for touch events on every hierarchy change that affects the SD (including
> >>>>> the race conditions this implies).
> >>>>>
> >>>>> What is the reason for this again? If we already require clients to track
> >>>>> the SDs, can we assume that they want the events from the device as
> >>>>> selected, even if reattached?
> >>>>
> >>>> We enforce one touch client selection per physical device per window at
> >>>> selection request time. Let's say on the same window you have client A
> >>>> selecting on detached slave device S, and client B selecting on
> >>>> XIAllMasterDevices. When you attach device S to a master device, you now
> >>>> have two competing selections. Do you send touch events to client A or
> >>>> client B? I feel that client B has priority and client A's selection
> >>>> should be cancelled. If you inverted the priority, you would break X
> >>>> core and XI 1.x clients by removing their selections without them knowing.
> >>>
> >>> can you even select for XIAllMasterDevices for touch events? master devices
> >>> don't send touch events so you can't really select for them. Not sure how
> >>> that situation would then happen.
> >>>
> >>> if you can, I need an extra blurb to see the semantics for
> >>> XIAllMasterDevices on XISelectEvents.
> >>
> >> I'm not sure where the confusion here lies. In ubuntu, qt selects on
> >> XIAllMasterDevices for touch events and things work fine. I guess I'm
> >> not sure what needs to be clarified.
> > 
> > ok, one thing first:
> > a protocol spec and an implementation are two different things. they're tied
> > to each other, something that makes sense in a protocol spec may not
> > be feasable to implement and implementation doesn't necessarily make sense
> > as protocol.
> > 
> > Coupling those two up is dangerous. Look at RawEvents in XI2
> > for example. made sense when implementing, doesn't make sense from the
> > protocol. look at the XI2 library headers. protocol extensibility makes
> > sense, implementation completely missed it. so "things work fine" can apply
> > to any implementation.
> 
> This is a good point. My reply glossed over this.
> 
> > anyway:
> > XIAllMasterDevices has certain semantics. It's mostly the same as selecting
> > for all master devices with a few extra quirks.
> > touch events are not sent through master devices. so we can't select for
> > touch events on a master device, but instead require the client to select on
> > SDs directly. is this right? 
> > if you can't select on master devices, XIAllMasterDevices shouldn't have any
> > effect.
> > 
> > If it does have an effect and I select for (ButtonPress|Touch{Begin|...}) on
> > XIAllMasterDevices, I get touch events from the slave device but button
> > press from the master device?  Can I still select on the slave device if
> > I've selected on the master? with current XI2.0, I can because the two
> > events are not coupled.
> > 
> > has the meaning of XIAllMasterDevices changed to "select for events on slave
> > devices that are currently attached for certain event masks but not the
> > other events masks"? where am I going wrong here?
> 
> Actually, the meaning of selecting for touch events from
> XIAllMasterDevices is the same as selecting for pointer events. A client
> can select for touch events from a specific device, all devices, a
> specific master device, or all master devices. I didn't state this
> explicitly in the protocol because it's not a departure from XI 2.0.

as I understand it, master devices don't send touch events. in XI2 the two
device types are decoupled and if you select from SD and MD you'll actually
get two different events (they really may contain different states, aside
from the source/deviceid of course).

that was at least in the last implementation I saw, but I couldn't find
anything in the protocol spec. so I'm not sure what the latest state of this
is. given XI 2.0 semantics, you're correct, everything is fine. but if we really
use different semantics, then then the above applies.

so which delivery mode do we use?

Cheers,
  Peter

> I suppose you don't remember, but it was you who suggested it should
> operate this way and changed my thinking :).
> 
> The only thing that's different with touch event delivery is the special
> case of pointer emulated events from direct touch devices. My
> understanding is that events from a slave device represent that slave
> device in particular. Say you detach your touchscreen from the master
> pointer. Should it send emulated pointer events? I believe that it
> shouldn't because a touch screen device really has no concept of a
> single "pointer". I don't know of any use case that requires emulated
> pointer events from direct touch devices either.