[PATCH synaptics] Revert "Don't store fake events in the motion history"

[Derek Foreman]

On 02/20/2012 06:20 AM, Daniel Stone wrote:
> Hi,
>
> On 20 February 2012 00:20, Peter Hutterer<peter.hutterer at who-t.net>  wrote:
>> This commit introduced a regression. On some touchpads, the pointer keeps
>> moving in the last direction when the finger movement stops but the finger
>> is left on the touchpad.
>>
>> Cause appears to be get_delta() which calculates the deltas based on the
>> motion history but has no control flow for the lack of fake motion events
>> in the history after this commit. Thus, under some conditions, the delta is
>> always non-zero as the history does not change.
>>
>> Reproducer attached to bug
>> https://bugs.freedesktop.org/show_bug.cgi?id=45278#c11
>>
>> X.Org Bug 45278<http://bugs.freedesktop.org/show_bug.cgi?id=45278>
>>
>> This reverts commit c8b098214b44cf0585d78c460401ea7d143769f3.
>>
>> Signed-off-by: Peter Hutterer<peter.hutterer at who-t.net>
>
> Acked-by: Daniel Stone<daniel at fooishbar.org>
>
> Yes, this was both designed for and only works on, terrible hardware.
> It was meant to give more accurate motion by actually calculating the
> new events based on real history, rather than calculations based on
> calculations based on real history.  Unfortunately, this gets
> subverted by hardware which is too accurate.  Synaptics PS/2 pads
> can/could usually be relied on to give enough jitter once your finger
> had stopped that we'd filter out the motion and stop it.  However,
> some newer Synaptics pads as well as pads from other manufacturers
> tend to not deliver any jittery events once your finger has stopped,
> which is bad news since evdev filters out duplicate events.
>
> I'm not really sure how to fix this (a property indicating a lame
> touchpad with a whitelist? making sure we don't generate too many fake
> motion events? probably both ...) and don't have a whole whack of time
> or devices to test with now, so the revert is OK by me.  Hopefully we
> can revisit this later, because it does subjectively produce 'better'
> events.  Except when it catastrophically fails.

Ultimately, the problem is that (on good devices, or when employing a 
reasonable amount of filtering) we don't know the difference between 
"kernel is filtering data" and "there is no new data coming".

The devices in question drop their sampling rates from 80Hz to 40Hz when 
tracking more than 1 finger - 40Hz being below the screen refresh rate 
resulting in obviously jumpy cursor motion.  Basically, 1/60th of a 
second after receiving a motion packet we don't know if we're in reduced 
rate reporting mode, or if the kernel has started filtering.

By firing a timer faster than the screen refresh rate and using some 
extrapolation, the cursor motion can be made much smoother, with no 
visible change in tracking speed when the user switches from single to 
multiple finger operation.

Keeping fake motion events out of the history (and the reverted 
replacement motion estimator) are a precursor to the extrapolation code.

I have a kernel patch around somewhere that "fixes" this filtering 
problem by making evdev repeat the last sample at the start of 
filtering, and sets a device property to let us know that the driver 
behaves this way.  Relying on something like that to enable this code 
might be the best way to move forward.

I'll remake patches when xf86-input-synaptics settles down a little bit...