[PATCH inputproto] Add touch classes and events, bump to 2.1
Daniel Stone
daniel at fooishbar.org
Fri Jan 7 08:02:09 PST 2011
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>
More information about the xorg-devel
mailing list