Re: [PATCH 7/7] elantech: average the two coordinates when 2 fingers

[Henrik Rydberg <rydberg@euromail.se>]

On 08/02/2010 01:33 PM, Éric Piel wrote:

> Op 02-08-10 13:22, Henrik Rydberg schreef:
>> On 08/02/2010 01:12 PM, Éric Piel wrote:
> :
>>>> You need to add the tracking id and a couple of lines, but i do not see why the
>>>> 2->1 transition would be treated any differently. The one-finger coordinate
>>>> would be close to either position[0] or position[1], which would determine the
>>>> tracking id to keep. Every time you add a finger you add a new tracking id. What
>>>> is your planned support for three fingers?
>>> Yes, yes, it's probably fairly easy to do some kind of tracking. But I
>>> think that as long as the hardware does not provide such a thing, it's
>>> better to do the minimum in kernel space, just enough to be meaningful,
>>> and leave the rest to userspace.
>>
>>
>> The implemented part could also be done in userspace. Going half-way just to
>> circumvent buggy behavior in synaptics is really not a good idea.
> No, we've been going from protocol 0.5 (report max/min coordinates) to
> protocol A.5 (report finger positions, often with correct track ID). My
> argument is that it's not because we are half-way to B, by chance, that
> we should go up to it. We do just the minimum to respect the minimum
> protocol. Once the driver respects that protocol, all the fancy stuff
> has to stay in userspace. There is already mtdev (I'm sure I don't have
> to tell you ;-) ), I don't see the point of doing some copy-pasting.


Without this patch, the driver reports two points, the lower-left and
upper-right of a rectangle. With this patch, the driver reports two points,
which is either equal to the two actual fingers, or, after resting the fingers
horizontally, two random opposite corners of a rectangle.

Doing userspace tracking without the patch results in properly following the
lower-left and upper-right corners of a triangle. Doing userspace tracking with
the patch results in properly following two random opposite corners of a rectangle.

Without this patch, synaptics shows jerky behavior. With this patch, synaptics
works a bit better.

The above tells me that the MT situation did not improve much, and that the
major improvement is to paper over the synaptics problem.

The argument to go forward implementing protocol B is that the current patch
actually does proper two-finger tracking to the extent that it is possible.
Since mtdev cannot improve the fact that this device does not following fingers
but corners, it makes sense to treat this device specially, and implement the
extra lines in the kernel to make it as good as it can be. Alternatively, one
can give up the idea of using MT in this driver altogether, and just implement
the mean position ABS_X/Y, old-style.

Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html