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

[Peter Hutterer]

On Wed, Feb 22, 2012 at 02:05:25PM -0600, Derek Foreman wrote:
> 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.

yes please. that seems liek the only sane way forward.

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

thanks.

Cheers,
  Peter