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

[Peter Hutterer]

On Thu, Mar 10, 2011 at 03:39:18PM -0500, Chase Douglas wrote:
> I'll be sending an update to the protocol soon. I've picked out just a
> few comments here to reply to. The rest should be covered by the updated
> protocol.
> 
> 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:
> >> My implementation sets the timestamp of the touch events as they are
> >> sent to the client, so the timestamp of replayed events will not match
> >> the timestamp of the original events as sent to the grabbing clients. I
> >> don't see this as a problem because X timestamps just don't work for
> >> multitouch events. Henrik Rydberg implemented a Kalman filter for
> >> velocity estimation and compensation in utouch-frame, a library for
> >> extracting touch events into frames for easier consumption by the
> >> client. The library can work on top of mtdev or XI 2.1. When mtdev is
> >> used, the evdev timestamps are used and the filter works well. When XI
> >> 2.1 is used we have to disable the filter because the X timestamps are
> >> so wildly inaccurate. The correct solution, imo, is to add a valuator
> >> axis to the devices whose value represents "device" time. On Linux, this
> >> would be set to the timestamps from evdev. The valuator values of the
> >> device events are copied into the ring buffer, so when they are replayed
> >> the values would be representative of the original events.
> > 
> > valuators are _not_ fields we can dump random values in just because we
> > can't fix them elsewhere. especially for this, we already have an event
> > time. if that is "wildly inaccurate" then it's mostl likely a bug. what's
> > the cause for the inaccuracy?
> 
> I've addressed the timestamp meaning issue in the protocol update.

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

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

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?

Cheers,
  Peter