Bad backport, had a superfluous break which made it half-work on some devices.
On Apple touchpads, it crashes outright, but the real fix is a bit more
involved.
This reverts commit fbf8df1669.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Touchpads are limited by a fixed sampling rate (usually 80Hz). Some finger
changes may happen too fast for this sampling rate, resulting in two distinct
event sequences:
* finger 1 up and finger 2 down in the same EV_SYN frame. Synaptics sees one
finger down before and after and the changed coordinates
* finger 1 up and finger 2 down _between_ two EV_SYN frames. Synaptics sees one
touchpoint move from f1 position to f2 position.
That move causes a large cursor jump. The former could be solved (with
difficulty) by adding fake EV_SYN handling after releasing touchpoints but
that won't fix the latter case.
So as a solution for now limit the finger movement to 20mm per event.
Tests on a T440 and an x220 showed that this is just above what a reasonable
finger movement would trigger. If a movement is greater than that limit, reset
it to 0/0.
On devices without resolution, use 0.25 of the touchpad's diagonal instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 41b2312c00)
Default resolution is 1, don't allow setting 0 to avoid divisions by 0 or
just general weirdness.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 049611bd7f)
open_slots holds the slot index, resetting it to 0 is a bad idea. And make
sure that we do reset after DEVICE_INIT. We already do so on DEVICE_CLOSE, but
after the first DEVICE_ON the data could still be random.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit afbbcfa10e)
And warn when we run out of labels.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit d239f831f1)
Conflicts:
src/eventcomm.c
Default on evdev devices is CLOCK_REALTIME. If that clock falls behind the
server's CLOCK_MONOTONIC, motion after a clickpad click may be delayed by the
difference in the clocks.
In detail:
When the timer func is triggered, GetTimeInMillis() which is CLOCK_MONOTONIC,
is stored as hwState->millis. The eventcomm backend uses struct
input_event time (CLOCK_REALTIME).
When we read events from the device, if the evdev time is less than the server
time, the fix for (#48777) sets the current event time to hwState->millis.
Until the evdev time overtakes that stored time, all events have the
hwState->millis time.
If during that time a clickpad triggers a physical click,
clickpad_click_millis is set to hwState->millis + the ignore-motion timeout.
Thus, all motion is ignored until the event time overtakes that stored
time.
The whole issue is further enhanced by us unconditionally setting the timer
func if we get any events, which is a separate issue anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry-picked from commit 90d1930230)
When two fingers are used, the coordinates of only one of them is taken into
account. This can lead to sudden variations of the absolute coordinates when
two-fingers taps are performed if the finger considered changes.
Take into account coordinates variations to prevent unwanted taps only if
the number of fingers doesn't change.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 7d0ff39519)
We had reports that the top software button area is hard to hit for those
using the trackpoint and clicking the buttons with their thumb.
Analysis of event recordings (3 different people) for left, right and middle
clicks shows that there is a significant amount of events up to about 10mm
(with outliers up to 12mm) from the top of the touchpad. That maps to 15%.
Interestingly, the middle button does not seem to need this, presumably the
haptic feedback of the little dots sticking out from the surface make hitting
the button easier. Its size is increased to 15% anyway, for simplicity and
because a sample set of 3 is too small to be definitive about this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 7301012234)
Add a HasSecondaryButtons boolean config option which defaults to true for
devices with the INPUT_PROP_TOPBUTTONPAD and false for all other devices.
Only parse the SecondarySoftButtonAreas when this option is true, effectively
disabling the top buttons when it is false. Likewise, only initialize the
SecondarySoftButtonAreas property if we enable support for it.
This means that it is now safe to always set a SecondarySoftButtonAreas
default in 50-synaptics.conf, and that he section which was intended for
use with future pnp-id matching can be dropped, as that is now all handled
in the kernel.
While at also remove the comment about disabling the bottom edge area, as that
is now done automatically.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 7bf2756841)
Conflicts:
src/eventcomm.c
Enabling clicks in off mode also allows for the new Lenovo *40 series to use
the top software buttons while the touchpad is disabled. This benefits those
that usually disable touchpads altogether but still need the buttons for the
trackstick.
This changes existing behaviour, but TouchpadOff was always intended to stop
erroneous events while typing. Physical button presses are hard to trigger
accidentally. On the touchpads that TouchpadOff concept was originally
designed for the buttons are nowhere near the keyboard and are physically
separated from the touchpad anyway. On Clickpads, triggering a physical
click requires more force than accidentally touching the surface.
https://bugs.freedesktop.org/show_bug.cgi?id=76156
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit dc5474964d)
Clicking in the top soft button area causes the trackpad to begin
registering motion, even if the finger never leaves the top soft button
area. We don't want this kind of behavior for the top soft button area,
since it makes clicking and dragging items much more difficult when
using a pointing stick.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit b40a5255fe)
This was originally intended as a fixed xorg.conf option only (and still
largely is seen as such). Secondary software button are required only on a specific series
of touchpads and should be pre-configured by the system and/or the
distribution. As such, the property will not be initialized if it is not set
in the xorg.conf and will thus not respond to runtime changes.
Exposing the property in this way gives clients a chance of detecting if a top
software button area is present and thus adjust their behaviour accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 66240dc329)
It is possible for a click to get reported before any related touch events
get reported, here is the relevant part of an evemu-record session on a T440s:
E: 3.985585 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 3.997419 0003 0039 -001 # EV_ABS / ABS_MT_TRACKING_ID -1
E: 3.997419 0001 014a 0000 # EV_KEY / BTN_TOUCH 0
E: 3.997419 0003 0018 0000 # EV_ABS / ABS_PRESSURE 0
E: 3.997419 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0
E: 3.997419 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 5.117881 0001 0110 0001 # EV_KEY / BTN_LEFT 1
E: 5.117881 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 5.133422 0003 0039 0187 # EV_ABS / ABS_MT_TRACKING_ID 187
E: 5.133422 0003 0035 3098 # EV_ABS / ABS_MT_POSITION_X 3098
E: 5.133422 0003 0036 3282 # EV_ABS / ABS_MT_POSITION_Y 3282
E: 5.133422 0003 003a 0046 # EV_ABS / ABS_MT_PRESSURE 46
E: 5.133422 0001 014a 0001 # EV_KEY / BTN_TOUCH 1
E: 5.133422 0003 0000 3102 # EV_ABS / ABS_X 3102
E: 5.133422 0003 0001 3282 # EV_ABS / ABS_Y 3282
E: 5.133422 0003 0018 0046 # EV_ABS / ABS_PRESSURE 46
E: 5.133422 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1
E: 5.133422 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
Notice the BTN_LEFT event all by itself!
If this happens, it may lead to the following problem scenario:
-touch the touchpad in its right click area
-let go of the touchpad
-rapidly click in the middle area, so that BTN_LEFT gets reported before the
new coordinates (such as seen in the trace above, this may require some
practicing with evemu-record to reproduce)
-the driver registers the click as a right click because it uses the
old coordinates from the cumulative coordinates to determine the
click location
This commit fixes this by:
1) Resetting the cumulative coordinates not only when no button is pressed,
but also when there is no finger touching the touchpad, so that when
we do get a touch the cumulative coordinates start at the right place
2) Delaying processing the BTN_LEFT down transition if there is no finger
touching the touchpad
This approach has one downside, if we wrongly identify a touchpad as
a clickpad, then the left button won't work unless the user touches the
touchpad while clicking the left button.
If we want we can fix this by doing something like this:
1) Making update_hw_button_state return a delay; and
2) Tracking that we've delayed BTN_LEFT down transition processing; and
3) When we've delayed BTN_LEFT down transition return a small delay value; and
4) If when we're called again we still don't have a finger down, just
treat the click as a BTN_LEFT
But this is not worth the trouble IMHO, the proper thing to do in this
scenario is to fix the mis-identification of the touchpad as a clickpad.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit bbe4c56c49)
When a button click and new coordinates get reported in one go we sync the
cumulative coordinates to the old x and y, rather then the newly reported ones.
This keeping of the old coordinates causes the following issue:
-touch the touchpad in its right click area
-let go of the touchpad
-rapidly click in the left click area (or middle area), so that the
new location and the click get reported in one syn (may require some
practicing with evemu-record to reproduce)
-the driver registers the click as a right click because it uses the
old coordinates from the cumulative coordinates to determine the
click location
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 743c45b9cf)
This fixes my #1 anoyance with clickpads, where 2 out of 3 clicks turn into
a click + drag unless I hold my finger really really still.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Replaced property with a hardcoded 100ms. This is not something that we should
expose as property, we should find a delay that works best and live with it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 71652fe1f0)
Unless the motion has started outside the soft-button area.
Note that we must start reporting motions regardless of whether we think we're
in the button area or not as soon as we've switched to using cumulative
coordinates, since then the coordinates are no longer absolute.
This fixes the reporting of unintended motion just before a click in a soft
button area which sometimes causes mis-clicks.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 3adaf46238)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Conflicts:
src/synaptics.c
We only use it to store button state which we already have in
priv->lastButtons.
While at it also properly indent the code block checking the various
soft button areas.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit effeee86c1)
While at it also move the enum for the soft button edges out of
is_inside_button_area() so that it can be used elsewhere too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 840670508e)
New generation of laptops with trackstick do not have physical buttons
associated with the trackstick, but instead rely on software buttons at
the top of the clickpad.
Adding a secondary software button area for this purpose.
As we're likely detecting the devices that need it based on udev tags
and MatchTag configuration items, this area doesn't need to be exposed
through properties. So static configuration is fine.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
[couple of man-page additions and rewrites]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 402cc87257)
synaptics offers an option to make parts of the touchpad insensitive. This
is ie useful to do palm avoidance rather then palm detection (which may be
unreliable) by disabling an area of 15% on the right and left side of the
touchpad.
Currently a motion which has started inside the active area, stops as soon
as it moves outside of the active area.
If a motion started inside the active area and thus has already generated some
move events, this makes no sense. If the user moves outside of the active
area in this case, this is very likely because the user wants to continue
the motion.
This commit allows such motions to continue normally.
I would like to thank Juerd Waalboer for the basic idea, some coding and lots
of testing for this fix.
Cc: Juerd Waalboer <juerd@tnx.nl>
Reported-by: Juerd Waalboer <juerd@tnx.nl>
Tested-by: Juerd Waalboer <juerd@tnx.nl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 945acfc261)
When trying to do a 3 fingerclick on a touchpad which only tracks 2 touches,
this may register as a 3 or 2 fingerclick depending on the order in which
the touchpad detects the fingers. If the 2 outer fingers of the 3 get seen
first, then the 2 touches will be too far apart for the heuristic to see
them as being close together, and the click gets counted as a 2 finger click.
A user will likely never do a 2 finger click with a 3th finger resting
somewhere else on the pad, where-as the above misdetection of the clicks is
a real issue, so simply always count a click with trippletap set as a
3 finger click on pads which track less then 3 touches.
https://bugzilla.redhat.com/show_bug.cgi?id=1086218
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit a6f0f4c9a5)
Some touchpads provide BTN_TOOL_TRIPLETAP but do not track more than two
touchpoints. For those, try to detect clickfinger3 actions as best as we can.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 51b6bf3c10)
Some Macbooks are being tagged as MODEL_UNIBODY_MACBOOKs when they should not
be. This causes the default sensitivity to be very low for them, making the
touchpad almost unusable. This change puts those devices into the correct
bucket again.
Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit efa424b5c9)
If a slot's ABS_MT_TRACKING_ID event was received during SYN_DROPPED, the
driver isn't aware that a touchpoint has started or ended in that slot. When
the next ABS_MT_TRACKING_ID event arrives, the driver would unconditionally
close or open a new touchpoint. This could lead to two or more touchpoints
being opened in the same slot, the first of which is never terminated.
Or it could lead to a touchpoint being terminated that was never opened.
The event sequences that trigger this are:
ABS_MT_TRACKING_ID 83
ABS_MT_TRACKING_ID -1
SYN_DROPPED // new touchpoint started here
ABS_MT_TRACKING_ID -1
and
ABS_MT_TRACKING_ID 83
SYN_DROPPED // touchpoint ended here
ABS_MT_TRACKING_ID 84
ABS_MT_TRACKING_ID -1
We don't properly handle SYN_DROPPED, but we can avoid this by only starting a
new touchpoint when we transition between -1 and a valid tracking ID.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
6d47d33 disallows a zero value for horizontal/vertical scroll deltas but the
man page wasn't updated. We've added separate toggles to enable/disable
scrolling a few years ago, setting the distance to 0 is not recommended.
X.Org Bug 75074 <http://bugs.freedesktop.org/show_bug.cgi?id=75074>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 2ea76fad65)
This reverts commit 0903d99ada.
Scroll buttons are still present in some modern devices, e.g. the Fujitsu
Lifebook E782 and others in the series.
Conflicts:
include/synaptics.h
man/synaptics.man
src/synaptics.c
(cherry picked from commit e0069c1544)
For symmetry, the kernel should ungrab when we close the fd.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[modified for the 1.7 branch which isn't using libevdev yet]
(cherry picked from commit 5d391e352f)
For absolute devices in relative mode, i.e. touchpads, the server now takes
device resolution into account. Doing so means that the driver mustn't
scale, so we deactivate those bits in the driver.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 0fb59b3487)
xf86SetStrOption() returns a strdup'd string that must be freed after use.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Apple Magic Trackpad can report 16 slots. In clickpad_guess_clickfingers()
the array allocated on the stack contains only 10 slots.
As (.num_mt_mask == .num_slots), the function writes out of the bounds
of close_point.
Use a size 32 bitmask instead and warn if we ever get past 32 touchpoints.
This fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=952221
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reported-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
For percent-based configuration in the form of
middle button 33%-66%, right button 66%-0 we'd get an error because of the
one device unit overlap. This was neither documented nor useful, because
leaving a 1% gap leaves an actual gap between the buttons. Allow for an
overlap of one device unit on the edge of the buttons.
What's picked in that case depends on the implementation of
is_inside_softbutton_area but since one device unit is so small, it doesn't
matter.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
