[RFC XI 2.1] Implementation patches (without grab support)

[Daniel Stone]

Hi,
I'm back from 2.5 months of holidays and am slowly working my way
through the email backlog ... I'm working on multitouch fulltime though,
so hopefully we can get this sorted and merged fairly soon.

On Fri, Nov 12, 2010 at 05:35:00PM -0500, Chase Douglas wrote:
> In the past two weeks I took Daniel Stone's initial XI 2.1 multitouch
> implementation and reworked it to push it forward.

Nice, thanks! :)

> The major issue with Daniel's approach was the hardcoding of much of the
> per-touch data in the protocol. For example, the proposal codified touch
> size to be described in one and only one way. However, touch hardware
> thus far have presented touch size in many different possible ways. Some
> define it as a single number, like a diameter of a circle. Others define
> it as an upright rectangle with a width and a height. Further, Apple
> devices define it as a elipse with an orientation.
> 
> Rather than codifying one way of describing a touch size and shape, I
> decided to leave each bit of meta data as a valuator axis. This is the
> approach Peter Hutterer proposed, and I followed it fairly closely.

Yep, this is fine with me.

> The basic idea is that an input device defines one touch class and a
> number of touch axis classes, one for each type of metadata. Three touch
> axis classes are required for the device to function: an x axis, a y
> axis, and a touch ID axis. Note that I built the support on top of the
> new masked valuators input API, so any of these axes or other metadata
> axes may be updated individually. The one requirement is the touch ID
> axis must always be provided.

Hm, I'm not convinced that the touch ID should be an axis: it's
not valuator data in any sense other than its being numeric.  I'd be a
lot happier seeing the touch ID pulled back out of axis data, and
enumerated separately both in GetTouchEvents(), and in the events
themselves.

> Another change from Daniel's implementation is that touch events are
> sent to all clients who register on any window within the window trace
> of a touch. If three clients register on the root window, a top level
> window, and a sub-window respectively, and the touch begins within the
> sub-window, then all three clients will receive the event. However, the
> window closest to the root window "owns" the event, and all other
> clients see a flag informing them the events are not theirs to use in a
> non-reversible manner yet (one example: they could start gesture
> recognition in the hope that they become the owner for the touches at
> some point). Please note that these semantics are not set in stone and
> are not even implemented in this patch set outside of the event
> broadcasting.

I'm still not entirely sure what the purpose of this is.  It doesn't
seem unsafe per se (given the owner flag), but it seems like it'd
probably cause huge wakeup storms just to avoid keeping the touch
history within the server.  It just seems misguided ... if the purpose
is to avoid lag because gesture recognition is computationally
expensive, then surely having more than one client doing it at all times
will exacerbate the problem?

> My intention with this release of patches is to generate a discussion
> and eventual agreement on the base support: event subscription mechanics
> and event structure for typical (non-grabbed) events. From there we can
> continue on through grabbing semantics. I have not updated XI2proto.txt
> in the inputproto package, but one may refer to Peter's proposal at
> http://cgit.freedesktop.org/~whot/inputproto/tree/XI2proto.txt?h=multitouch
> for guidance, as the basic support implemented here matches.

Do you envision grabbed events looking different?

> I will be following this message with a bunch of patches to a bunch of
> X components. I am maintaining all the source code in my own
> repositories at cgit.freedesktop.org (acct name cndougla), and right now
> this code exists in the xi2.1-new branches (xi2.1-new-stable for
> xserver). Some of the patches are merely bug fixes that need to be
> merged; I need to get off my butt and push them appropriately :).
> 
> I have pushed a set of packages to a PPA on Launchpad.net. If you run
> Ubuntu you can install the packages or follow development by going here:
> https://wiki.ubuntu.com/Multitouch/XDevelopment. Note that I've been
> developing against xserver 1.9 (master for everything else) due to ABI
> breakage issues when I started. The xserver source code is essentially
> 1.9 plus a backport of the X input ABI 12 work. I believe it should be
> trivial to rebase the xserver patches on top of master, and I will
> likely do so after the merge window closes for 1.10 on Dec 1st.

Thanks for doing this.  Give me a day or two to catch up and I'll try to
come back with some more detailed comments.

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/20101201/7c59533a/attachment.pgp>