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

[Henrik Rydberg <rydberg@euromail.se>]

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

> Op 02-08-10 12:02, Henrik Rydberg schreef:
>> On 08/02/2010 10:17 AM, Éric Piel wrote:
>>
>>> Op 01-08-10 15:57, Henrik Rydberg schreef:
>>>> On 08/01/2010 01:28 PM, Éric Piel wrote:
>>> :
>>>>> I still think that for the very specific use case of scrolling when
>>>>> pressing one finger and moving up and dow the other one, reporting the
>>>>> average works better than the first finger. However, I guess this can be
>>>>> considered just as a drawback of the ST protocol, and fixed in userspace
>>>>> by using the MT protocol.
>>>>>
>>>>> What do you think? Does it look fine to you? Below is the code.
>>>>
>>>>
>>>> I might have lost track of what problem needs to be solved. The current patch
>>>> seems to implement tracking, but still does not solve the individual MT finger
>>>> problem. And, it uses the same definition of ABS_X/Y as before. I was also under
>>>> the impression that synaptics needs fixing, anyways. All of this taken together
>>>> sadly suggests that this patch could just as well be reverted to the original
>>>> one. Or? Alternatively, one could switch to the type B protocol, since no
>>>> further tracking improvement is possible in userspace. The implementation is
>>>> tidy and simple enough, I think.
>>> Yes, you're right, the patch I've sent was still with the "average of
>>> the 2 fingers", but I'm now willing to drop it. With the tracking, at
>>> least we can keep sending info about a real finger and avoid jumps at
>>> the transition 1->2, so reporting the first finger might have advantages
>>> over reporting the average :-) The improvement for the test case can
>>> just go to userspace.
>>>
>>> The tracking is still not so clever, so it's definitly not adapted to a
>>> type B MT protocol (think transition 2->1).
>>
>>
>> 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.

> Concerning 3 fingers (and more), the hardware reports only one set of
> coordinates, the lower ones. So in this case, tracking is definitely not
> possible.


Ok.

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