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

[Chase Douglas]

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?

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

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.

Thanks,

-- Chase