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

[Henrik Rydberg <rydberg@euromail.se>]

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

> Op 02-08-10 13:46, Henrik Rydberg schreef:
>> On 08/02/2010 01:33 PM, Éric Piel wrote:
> :
>>>> 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.
> Yes, exactly.
> 
>> 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.
> Yes, with "random opposite" being "quite often the actual corners where
> the fingers are".


Right. It is not very compelling for someone actually trying to use the MT
points to anything useful.

>> Without this patch, synaptics shows jerky behavior. With this patch, synaptics
>> works a bit better.
> No. This patch, doing the tracking, doesn't change at all the behaviour
> with synaptics.
> 
> Synaptics already detects the transitions between singletap/doubletap,
> and avoid cursor jumps. So tracking the finger doesn't help. The only
> patch that ever helped was the one in the subject of this email:
> reporting the double touch in ST-protocol as the middle of the two
> touches. That helps a lot when you do scrolling with one finger fixed
> and one finger moving (because without it half of the time nothing
> happens). If your gesture is to move both fingers at the same time, it
> has always worked fine.


So "this patch" got intermingled. The part that you describe is the part that I
was referring to.

> The tracking patch improves cursor jumps for other userspace apps which
> do not detect singletap/doubletap transitions... but in practice I don't
> know any other app that read the touchpad events! So that's not a big
> improvement ;-)


Right.

>> The above tells me that the MT situation did not improve much, and that the
>> major improvement is to paper over the synaptics problem.
> For me it has changed because my argument was "with two finger we report
> crap anyway, so let's report the average". With the tracking, we
> actually (often) report the real position of the fingers, so this
> argument is not valid anymore. Now we can happily say we conform to the
> official protocols: ST (which apparently requires to always reports an
> actual position), and MT-A.


It does not comply with MT-A as long as two semi-random corners of a rectangle
are reported.

>> 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.
> Do you think that if we implement full tracking in kernel, we can do
> _better_ than the small tracking + mtdev? I don't think so (but, hey,
> I've been tinkering with multitouch for something like 20h in my life,
> so I might have missed something ;-) ). If you have in mind a better
> performing algorithm, then let me know, and I'll happily implement it in
> kernel :-)


We can do better in the sense that since the device cannot comply with MT-A, we
can do as close as possible to MT-B with less cpu usage. But frankly, the best
solution at this stage seems to be to drop MT handling altogether, since there
does not seem to be any plan to use it.

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