Le 17/06/2010 10:58, Henrik Rydberg a écrit :
Peter Hutterer wrote:
On Thu, Jun 10, 2010 at 05:47:57PM +0200, Benjamin Tissoires wrote:
Even if there is an interesting thread concerning the use of multitouch on
xorg-devel,
I still send the up-to-date patches to enable multitouch as valuators.
Changes since last time:
* Remove the detection of the maximum number of touches based on the tracking ID
* changes in comments
Henrik, Rafi, others - any further comments on this? Patches look good to
me, with a minor issue (see below) that can be fixed in a follow-up patch.
Benjamin - I'm not sure exposing the tracking ID in a valuator is a good
long-term solution. Does it provide any info that we do not already have by
splitting the touchpoints into different valuators?
Cheers,
Peter
Hi Peter, Benjamin, Carlos,
I have a proposition to make, which might affect the Xevdev patchwork somewhat.
Referencing our discussion in March, one major issue was how to resolve the
kernel events into tracked contacts, before putting them onto the valuators. I
think there is now a solution for it, which can be summarized as:
1. Extract the kernel events
2. Run them through the mtdev converter
3. Extract them as slotted type B events
4. Use the Valuators as slots
Point 1 is all done, no problems there.
The bulk of point 2 is also done, which may come as a surprise. Within a couple
of days, there will be a git tree with a project called mtdev, which is a
standalone converter module, under a free license (MIT/BSD/LGPL), which
transforms all variants of kernel MT events to the slotted type B protocol. This
means that for a device without finger tracking, the tracking is done in
software. For devices with finger tracking, the data is simply transformed. For
devices utilizing the new MT slots, the data goes straight through. Point is, by
sending the events through mtdev, we gain a uniform source of MT events, which
is compatible with the Valuator approach.
This obviously affects the Xevdev code, point 3. However, the effect should be
that the parsing code is simplified, since handling the MT slots is inherently
easier than handling the type A protocol.
Point 4 may or may not be different from what you all had in mind already. By
using the valuators as regular MT slots, much of the ground work is already
done. The protocol is documented, the process is simple, and there is a
mechanism for dealing with adding/modifying/removing contacts.
Comments are very much welcome.
Hi Henrik,
This is great. We will have a common protocol even if the "old" drivers
are not up to date.
I don't think we should change the current patchwork (or we may just
remove the MT_SYNC handling when we will be sure that no one use it
anymore). I had written these patches with the protocol B in mind: it's
as simple as possible to handle protocol A without interfering with the
B one: I have no tracking, no heavy computations, no states, etc...
So I can just start handling the protocol B in my own repository.
Thanks for your efforts
Cheers,
Benjamin
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
