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

[Peter Hutterer]

On Fri, Nov 19, 2010 at 01:52:39PM -0500, Chase Douglas wrote:
> ---
> Normally I'd just squash this in and make a v2 patch, but this is the most
> important part of the MT work and it's easier to review separately :). I'll
> squash later.
> 
>  XI2.h        |    3 +++
>  XI2proto.txt |   39 ++++++++++++++++++++++++++++++++-------
>  2 files changed, 35 insertions(+), 7 deletions(-)
> 
> diff --git a/XI2.h b/XI2.h
> index 5d407ea..4995c43 100644
> --- a/XI2.h
> +++ b/XI2.h
> @@ -193,4 +193,7 @@
>  #define XI_TouchEndMask                  (1 << XI_TouchEnd)
>  #define XI_TouchMotionMask               (1 << XI_TouchMotion)
>  
> +/* Convenience compound masks */
> +#define XI_TouchMask                     (XI_TouchBegin | XI_TouchEnd | XI_TouchMotion)
> +
>  #endif /* _XI2_H_ */
> 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.

> +
> +Touch events are broadcast to all clients registered for touch events on a
> +set of windows. The window set is determined at the beginning of each touch
> +and depend on whether the touch device is a direct or dependent device.

s/depend/depends

> +
> +Direct device window sets contain the windows from the root to the child
> +in which the touch originated.

"Window sets for direct device touches ..." is a bit easier to read IMO

> +
> +Dependent device window sets depend on whether other touches are active. If
> +other touches are active, the window set of the other touches is used. In this
> +manner, all dependent device touch events are sent to the same set of windows.
> +If no other touches are active, a new window set is created for the touch. The
> +set is formed in the same manner as direct devices, but location used is the
> +cursor position of the attached master device. If the touch device is floating
> +it will not emit any touch events for the new touch.

I would reword this a bit, I found the above a bit confusing. How about
something like this:
"For the first dependent touch on a device, the window set is the current
window underneath the pointer position up to the root window.
For subsequent touches on this device, the window set is identical to the
window set of the first touch. Once all touches have been released, the
window set is reset and re-calculated on the first subsequent touch.
"


> +
> +The delivery of touch events is not changed by any modifications to the window
> +hierarchy after the window set has been determined for the touch.

>  
>  A device that sends touch events may also generate pointer events on demand.
>  The decision of which touch events are converted into pointer events is
> @@ -1696,9 +1714,9 @@ EVENTHEADER { type:                       BYTE
>      selection of the hotspot of a touchpoint is implementation dependent and
>      may not be the logical center of the touch.
>  
> -    Touch tracking IDs are always provided through one of the touch axis
> -    valuators. Its value is always provided in every touch event. Tracking IDs
> -    are represented as unsigned 32-bit values and are required to increase in
> +    Touch tracking IDs are provided in the detail field of touch events. Its
> +    value is always provided in every touch event. Tracking IDs are
> +    represented as unsigned 32-bit values and are required to increase in
>      value for each new touch. Values will wrap back to 0 upon reaching the
>      numerical limit of IDs.

s/are required to/must/

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

Cheers,
  Peter
  
> @@ -1860,3 +1878,10 @@ require the client to announce XI 2.1 support in the XIQueryVersion request.
>      ⊳ DRV calls the respective input driver API with the touch sequence
>        data. The touch sequence emulating a pointer has the respective flag
>        set. DRV does not submit pointer data for any touchpoint.
> +     
> +
> +                              ❧❧❧❧❧❧❧❧❧❧❧
> +
> +Appendix B: Known Missing Features
> +
> +∙  Any form of grabbing or grab-like semantics for touch events
> -- 
> 1.7.1
>