[PATCH] touchpad: reset motion history when nfingers changes on semi-mt pads

[Hans de Goede]

Hi,

On 07/22/2014 09:18 AM, Hans de Goede wrote:
> Hi,
> 
> On 07/22/2014 01:34 AM, Peter Hutterer wrote:
>> On Mon, Jul 21, 2014 at 03:25:47PM +0200, Hans de Goede wrote:
>>> On semi-mt touchpads the reported position of the first finger down may
>>> jump when the pad switches from st to mt mode. When this happens a large
>>> delta gets seen on the first finger at the same time the second fingers
>>> is first seen down, causing a spurious 2 finger scroll event.
>>>
>>> Reset the motion history when nfingers changes on semi-mt pads to avoid this.
>>>
>>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>>
>> I don't seem to have any good recordings here that show the SEMI_MT jumps.
>> Any chance you can get one and add a test device for this?
> 
> Attached is a recording.
> 
> The jump starts at line 315, there slot 0 x / y are aprox. 640 / 1300, then
> at line 326 they jump to 1400 / 1272. This jump happens because in 2 finger
> mode the touchpad no longer reports exact locations, instead we get
> a bounding box, where the fingers occupy 2 opposing corners, and in this case
> the fingers are on 2 different corners then the ones the kernel chooses to
> always report.
> 
> I guess the kernel could / should be made smarter here, and could decide which
> 2 corners to pick based on the last single touch coordinate, instead of always
> picking the upper left and bottom right corners. I'll take a look at that,
> resetting the motion history is still the right thing to do though, since
> the 2 finger coordinates basically use a different coordinate system which
> gets scaled to the single touch coordinate system.

Thinking more about it, I think the kernel behavior is left best as is.
The current behavior is KISS and predictable. I'm afraid that trying to make
it smarter will make it non KISS, non predictable, and may lead to people
to expect accurate reporting of finger position with 2 or more fingers which
is just not possible. E.g. I might have never noticed the spurious scroll
events if the kernel tried to be smart, but I'm sure some users would have
come up with a hard to reproduce way to trigger it non the less.

Regards,

Hans