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

[Henrik Rydberg <rydberg@euromail.se>]

On 08/02/2010 06:26 PM, Dmitry Torokhov wrote:
> On Mon, Aug 02, 2010 at 01:22:15PM +0200, Henrik Rydberg wrote:
>> 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.
>>
> 
> What synaptics you are talking about here? Userspace driver or the
> in-kernel synaptics support? If the latter, then the device is not truly
> multitouch device (latest versions of the hardware/firmware aside) as it
> is capable of reportiong only one set of coordinates (X/Y) in addition
> to number of fingers on the surface.
> 

I was referring to the user-space driver.

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