[PATCH inputproto] Add touch classes and events, bump to 2.1

[Daniel Stone]

Hi,

On Thu, Jan 06, 2011 at 11:43:22AM -0500, Chase Douglas wrote:
> On 12/28/2010 12:58 PM, Daniel Stone wrote:
> > +XI 2.1 requires devices to track touch points over time. Devices that cannot
> > +do so in hardware must employ software trackers to be useable with XI 2.1.
> 
> s/useable/usable/ (according to thunderbird :)

Ha, right.

> > +Dependent device window sets depend on whether other touches are active. For
> > +the first dependent touch on a device, the window set contains the windows from
> > +the root to the the current window underneath the position of the device's
> 
> too many the's ^^
> 
> I would like to reword the ending of this sentence to: "... underneath
> the position of the attached master device's pointer." I don't think
> "sprite" is defined anywhere in this document.
> 
> (These may have been original mistakes of mine, doh!)
> 
> > +sprite. 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.
> > +
> > +No touches from a dependent device may begin while the device is floating, as
> > +it does not have a sprite to focus events to.
> 
> s/does not have a sprite/does not have an associated pointer position/

OK, I'll try to clear up the wording a bit here.

> > +        TouchOwner means that the client is the current owner of the touch.
> > +        TouchOwnerAccepted (for TouchEnd events only) means that the current
> > +        owner of the touch stream has “accepted” it, and this client will not 
> > +        receive any further events from that touch sequence.
> > +        TouchPendingFinish means that the touch has physically ended, however
> > +        another client still holds a grab, so the touch should be considered
> > +        alive until all grabbing clients have accepted or passed on ownership.
> 
> Is this flag set only on TouchMotion events? I think it should be stated
> on which event(s) the flag is valid. I'm going to assume TouchMotion
> events only for comments further down.

TouchOwner is valid for all events, whereas TouchPendingFinish is only
valid for TouchMotion events.

> > +∙ Client C wants to process touch events from a device D on window W.
> > +    ⊳ C calls XISelectEvent for XI_Touch{Begin|Motion|End} from D on W.
> > +    ⊳ C receives XITouchBegin whenever a touch sequence starts within
> > +      W's borders.
> 
> A note is needed here that every client must check the ownership flag
> before processing events. I propose the following:
> 
> ⊳ C begins using touch data if the XITouchOwner flag is set, otherwise C
> buffers the touch data and may perform reversible processing of the data
> (e.g. gesture analyzing or touch hinting).
> 
> > +    ⊳ C receives XITouchMotion events whenever a touch axis valuator value
> > +      changes for a touch sequence it received an XITouchBegin event for.
> 
> ⊳ If C is buffering events and then receives an XITouchMotion event with
> the XITouchOwner flag set, it may begin permanent processing of the data.
> 
> > +    ⊳ C receives XITouchEnd whenever a touch it received an XITouchBegin event
> > +      for ceases.
> 
> (adding onto above bullet point...) If C never received an XITouchMotion
> event with the XITouchOwner flag set, it must discard the touch
> sequence. Any processing of touch data must be undone.

Sounds good to me.

> > +∙  Driver DRV provides touch support from tracked device D:
> > +    ⊳ DRV initializes a TouchClass for the device and a TouchAxisClass for
> > +      each axis available on the device.
> > +    ⊳ DRV parses D's device protocol and selects one touch sequence to be
> > +      emulated as pointer event.
> > +    ⊳ 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.
> 
> I was under the impression that the driver would be handling pointer
> events and touch events separately. This wording sounds like the server
> handles pointer emulation internally based on touch data.
> 
> The current MT code in evdev has separate processing, so which way are
> we going with this?

Honestly? I don't know.  I'd be inclined to say that it'd be more robust
to do it in the server, so we can get a better association between the
touch and related pointer events, but certainly the trend in the kernel
has been to post ABS_[XY] events as well as the MT events, so I'm not
really sure.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110107/fdac95ae/attachment-0001.pgp>