[PATCH evdev 0/3] Preliminary support of multitouch (rev4)

[Henrik Rydberg]

Benjamin Tissoires wrote:
> 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.

Great! The library is finished, just touching up on packaging. The interface
consist of a single header file, which contains the api to do something like this:

x-input-event-handler()
{
	/* fetch all available kernel events */
	mtdev_pull(&dev, fd, 0);
	/* extract all available MT slot events */
	while (!mtdev_empty(&dev)) {
		mtdev_get(&dev, &ev);
		/* use ev to fill Valuator slots here */
	}
}

maybe that will give you a clue on how to insert it in the code.

Cheers,
Henrik