[RFC XI 2.1 - inputproto] Various fixes in response to Peter Hutterer's review

[Chase Douglas]

On 11/23/2010 01:07 AM, Peter Hutterer wrote:
> On Fri, Nov 19, 2010 at 01:52:39PM -0500, Chase Douglas wrote:
>> diff --git a/XI2proto.txt b/XI2proto.txt
>> index fd47643..6976683 100644
>> --- a/XI2proto.txt
>> +++ b/XI2proto.txt
>> @@ -197,11 +197,29 @@ stage is optional. Within this document, the term "touch sequence" is used to
>>  describe the above chain of events. A client wishing to receive touch events
>>  must register for all three touch events simultaneously.
>>  
>> -Touch events are sent to all clients registered for them on any window in the
>> -window tree from the root window to the child window directly under the touch.
>> -
>>  A touch event is not delivered according to the device hierarchy. All touch
>> -events are sent only through their originating slave devices.
>> +events are sent only through their originating slave devices. However,
>> +dependent touch devices will only emit touch events if they are attached to a
>> +master device. This is due to the touch delivery being dependent on the
>> +location of a cursor.
> 
> it is still not clear why you don't want to route touch events through the
> master device (other than that leaving it in the SD alone is easier to
> implement). is there a list of pros and cons for both approaches?
> 
> especially in the case of touch-based pointer emulation, when the master
> will send events caused by the slave device. so some events have to be
> routed either way.

Direct touch devices will not send any touch events through master
pointing devices. If we send dependent touch events through the master
pointing devices, there will be a much larger difference in the event
handling for dependent and direct touch devices. We may see developers
write applications that handle MT on their laptop trackpads and not
realize they don't work on touchscreens.

If we send events through the master device, we have to handle DCEs as
well. Two separate dependent touch devices may be attached to the same
master device. I'm trying real hard to not have to deal with DCEs for MT
devices :). Not only is it more surface area in the protocol to
implement, it presents more opportunity for implementation or protocol bugs.

Part of the purpose of master devices is to coalesce pointer motion from
multiple devices into one cursor on screen. The cursor on screen has the
same boundaries and behavior across all attached devices. There's no MT
analog to relative devices so I'll leave those aside. Absolute devices
are transformed from device coordinates to screen coordinates. I don't
believe dependent touch devices should be mapped to screen coordinates;
if you want such behavior, make the device behave as a direct device. So
if dependent touch devices don't move the cursor by themselves, and they
have different properties such as resolution and limits, what do we gain
by sending them through the same master device?

Given the extra work, it seems to me that we should be asking why we
want to send touch events through master devices. I don't know of any
great reason to send touch events through the master devices. Do you
have any thoughts here?

In the case of pointer emulation, I don't see any issue with sending
them as detailed here. There's a flag to denote whether the event is
caused by pointer emulation, which should be enough for MT aware clients
to filter out these movements either from the pointer or from the touch
events depending on what the client is doing with the data. Since
pointer emulation is implementation defined, attempting to specify a
relationship between touch events and pointer events would be
problematic. I think the flag on pointer emulation events is the most we
can do.

[...]

> feel free to squash typo corrections etc. in with previous commits, they're
> not semantical changes after all.

I've incorporated the wording and typo changes you noted. Once we have
the dependent events through master devices straightened out I'll resend
the entire patch once more.

Thanks,

-- Chase