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<[email protected]> 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<[email protected]> > > > >Acked-by: Daniel Stone<[email protected]> > > > >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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
