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.
I'll remake patches when xf86-input-synaptics settles down a little bit...
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
