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

[Peter Hutterer]

On Mon, Feb 20, 2012 at 12:20:19PM +0000, 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.

do you have any device descriptions for such a device that simulate the
issue? preferably evemu format so they are reproducible.
 
Cheers,
  Peter