The driver assumes x/y is always valid but after coming from a resume we may
get a few events with either ABS_X or ABS_Y (not both). Thus we process with
hw->x == 0 and hw->y == somevalue, causing cursor jumps when calculating
deltas whenver the real hw->x comes in.
Fix this by resetting hw->x/y to INT_MIN and skip state processing until
both axes are available.
For clickpads, this means handling of data will be delayed until we get
at least one motion on each axis. Button presses won't be recognised either
until that happens. It requires some skill to not trigger motion on both
axes, even more to press a button without doing so.
For non-clickpads, handling of motion events will be delayed likewise. If a
physical button is pressed immediately after resume we have to assume deltas
of x/y.
- If the next event is a new touch, it will have ABS_X/ABS_Y set anyway
- If the finger was already down, a button event is generated, and the
finger has generated ABS_X or ABS_Y only before the event, the next event
containing the missing data will cause a jump. The fix for this is more
invasive and this is quite a corner-case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
(cherry picked from commit cd569377cd)
The open slots array is used for clickpad cumulative delta computation.
If the array is not reset and becomes corrupted during the device
disable/enable cycle, the cumulative deltas may be wrong. This manifests
as jumpy cursor behavior on some clickpads after suspend/resume.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 0054b144f3)
If a touch is physically active when the device is enabled, then all
events for that touch must be ignored. In particular, we cannot close
the touch or we will decrement touch count counters below zero. If these
counters go below zero memory corruption can occur.
Note that a device is disabled and enabled every time the user types on
the keyboard if synclient is used to disable the trackpad while typing.
This is a very common option.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 55fc42e7c9)
CoastingSpeed is defined as scrolls/s. The previous code just used
delta/seconds which depended on the device coordinate range and exceeded the
default CoastingSpeed at almost any scroll event.
Divide the estimated delta by the scroll distance to get the accurate
scrolls/s number. Since that now changes the contents of what's in
coast_speed_y, change the users of that too.
http://bugzilla.redhat.com/813686
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 0de4445ff8)
Moving into a different soft button's area during drag-n-drop would trigger
a click of that button.
We only have the current button state and we mess with it, so the conditions
for a possible clickpad soft-button event are:
- hw->left is down now
- none of left|right|middle were down before. since we change hw->left to
hw->right/left we need to check all three
If hw->left is down but one of the other buttons was already down, copy that
button state and continue.
http://bugzilla.redhat.com/819348
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
(cherry picked from commit a1d6784d79)
Provides for a more consistent scrolling experience, otherwise delta
leftovers may trigger extra events even when the actual scrolling action
stays the same.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Regression introduced in cddab79c40.
If an event has a delta of less than scroll_dist_vert, the delta is
unconditionally divided by the distance, leaving some remainder close to 0
and never actually triggering the scroll amount.
Fix this by working with the increment, not the normalised values.
X.Org Bug 46617 <http://bugs.freedesktop.org/show_bug.cgi?id=46617>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
We implicitly rely on this already since we calloc the struct. Do it
expliclity on DeviceOn().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
TS_3 is second tap down. Unconditionally set the button as down, later, in
HandleTapProcessing we have the required conditions to reset it to TS_START
and TBS_BUTTON_UP.
Meanwhile, TBS_BUTTON_DOWN stays down, so the second tap is counted and sent
as button event. This restores double-tapping if TapAndDrag is disabled.
X.Org Bug 31854 <http://bugs.freedesktop.org/show_bug.cgi?id=31854>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The eventcomm backend takes the timestamp from the kernel, but the timer
uses the timer's "now". This timestamp may be later than the one from the
next event we read from the kernel, causing a negative dtime in get_delta()
and a cursor jump by (unsigned int)-1.
Ensure that the new event's timestamp is at least the last used one.
X.Org Bug 48777 <http://bugs.freedesktop.org/show_bug.cgi?id=48777>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Gavin Troy <gavtroy@gmail.com>
As a result of commit 5a1612d449, coasting speed
was bumped up to a different scale by removing the divisor during the
calculation of initial coasting speed. This caused coasting friction to have
little to no effect, resulting in coasting that lasted virtually forever using
the default coasting friction value of 50.
This patch multiplies the scroll_dist_{horiz,vert} which was previously used as
a divisor for initial coasting speed to the coasting friction before deducting
it at each step, thus bringing coasting friction back under control.
Signed-off-by: Chow Loong Jin <hyperair@debian.org>
Tested-by: <Magnus.Kessler@gmx.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There is currently a problem that can lead the coasting to continue while scrolling in a particular situation :
with
Option "VertTwoFingerScroll" "on"
Option "CornerCoasting" "0"
Option "CoastingSpeed" "10"
Option "CoastingFriction" "50"
Option "CornerCoasting" "0"
If you scroll down with two finger then raise a finger, coasting will start. But if you put down that finger and try to
scroll up, the inertia will still scroll down while you scroll up. This can look like a very particular situation, but
happens to me often while scrolling in a big document.
This (awfully simple) patch stop coasting when detecting two-finger scroll.
Signed-off-by: Pierre Lulé <pierre@lule.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch allows scroll direction to be inverted by allowing
VertScrollDelta and HorizScrollDelta to be set to negative values. This
enables behaviour that is consistent with modern touchscreen devices,
where the content scrolls in the same direction as the user's finger
movement.
Signed-off-by: Alyssa Hung <ahung@isisview.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This resolves a regression from da461b9165
where three touch tap and click actions on certain devices no longer
work.
Some devices report a higher touch count than the number of touches they
can provide data for. For example, many Synaptics touchpads can report
up to five touches, but only provide data for two of them. We need to be
able to report the correct number of touches for these devices when
there are three touches. Using the maximum of the reported touch count
and the number of touches provided ensures the count is accurate for all
device types.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes a bug introduced in commit 2603ad69b9
(Use the scroll distances as increment for scrolling valuator axes)
Since this commit, scroll distance was set with SetScrollValuator function
but it was still used as a divisor to calculate coasting,
thus making coasting too slow. (at least on my computer)
Deleting the divisor fixes the issue.
A report of the same bug : https://bugs.archlinux.org/task/28955
Signed-off-by: Pierre Lulé <pierre@lule.fr>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A finger may be closer than the required distance to more than one finger.
e.g. for fingers A, B, C, AB, AC and BC may trigger the check and count
C twice -resulting in a 4 finger click.
Avoid double-counting by marking those fingers already close enough to a
previous finger to avoid overcounting.
X.Org Bug 48316 <http://bugs.freedesktop.org/show_bug.cgi?id=48316>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
We guess ten simultaneous touches if the device does not tell us. The
Linux drivers for the Apple multitouch trackpads do not tell the number
of simultaneous touches, but they can do more than ten. When this
occurs, the array index into the touch records will be invalid. We must
not process the touch or else we will segfault.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Though this looks like a behavior change, it really isn't since the
maximum tap_max_fingers that was previously possible was already handled.
The only real change is that if a tap is recognized but the
tap_max_fingers is zero, a tap will no longer be emitted. This shouldn't
happen in the real world.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The evdev protocol only goes up to three touches for non-multitouch
devices. If you perform a four touch tap, the finger count will only go
up to three touches if you roll your fingers, or will always be 0 if all
four touches land at the same time.
This change ensures the correct finger count is reported.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The right-half of the bottom 18% of the touchpad are enabled as right button
by default. On Apple touchpads (these don't have marking for the right
button) disable them by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
