GitLab

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>

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>

xf86-input-synaptics-1.8.0/src/synaptics.c:498: var_compare_op: Comparing
"end_str" to null implies that "end_str" might be null.

end_str can't be null, so no need for this check and no need to get Coverity
all confused.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

Just to make it explicit
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>

Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

In file included from /usr/include/string.h:634:0,
                 from /usr/include/xorg/os.h:53,
                 from /usr/include/xorg/misc.h:115,
                 from /usr/include/xorg/xf86str.h:37,
                 from /usr/include/xorg/xf86Xinput.h:54,
                 from synproto.h:36,
                 from synproto.c:24:
/usr/include/xorg/os.h:579:1: error: expected identifier or '(' before '__extension__'
 strndup(const char *str, size_t n);

See http://lists.freedesktop.org/archives/xorg-devel/2014-July/043070.htmlSigned-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Potentially uninitialized, false positive in both cases.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

Per-device logging functions don't interfere with other drivers if they also
use libevdev, so use those instead the global log handler if available. If not
available, drop libevdev logging, I don't want to maintain the ifdef mess and
the logging doesn't give us _that_ much benefit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

When we required a grab on the device, this was a shortcut so we didn't have
to query the device only to realise we can't read events off it anyway. Now
that we don't actually grab the device by default, this is unnecessary.

Something else may have a temporary grab on the device during init, in which
case we just continue as usual and read events if and when they become
available.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Rely on INPUT_PROP_TOP_BUTTONPAD and default button areas as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

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>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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=1086218Signed-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>

And expand DMI strings to more precise matches
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Everytime I look at this I get confused about OPEN_EMPTY vs EMPTY. Let's fix
that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

This is a bit problematic: libevdev only has one global log handler.
So if we have another driver use libevdev, we'll either overwrite that handler
or get overwritten, whichever comes first. So we need to re-set the handler
every time we get an event to make sure we log through our handler.
Likewise, if we ever drop the device, we need to unset the log handler back to
NULL because we may unload the module and our handler may disappear.

Use the lowest logging priority, let the server filter based on the verbosity
level instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Once the sync finishes, we get -EAGAIN. This only indicates the sync is done,
but some events may still be waiting in the pipe for us to read. We must read
those now, otherwise select may not trigger on further data.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

last_mt_vals_slot is only used in one location and there we can just use
cur_slot
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

This was required when we started supporting hotplugging to avoid duplicate
events. These days the drawback of not being able to record events in the case
of a bug is significant.

Check the configuration source on init. If the device was hotplugged through a
a server config backend, disable the grab. If the device was statically
configured through an xorg.conf then leave the default grab enabled to avoid
a duplicate device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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=76156Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Bad fdi file, type="string" is missing and it wouldn't merge properly.

This reverts commit a35b2d62.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This third state is not needed, the behaviour of the touchpad driver is now
good enough to not need an external syndaemon instance to toggle this third
state.

This reverts commit eea73358.

Conflicts:
	man/synaptics.man
	src/synaptics.c
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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>

Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

All kernel touchpad devices now support slots, there isn't really a need to
support protocol A devices in synaptics. If such devices exist, we just treat
them as non-multitouch devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>

When checking the device don't open a new mtdev instance, use the existing
libevdev struct.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>

The kernel guarantees slots start at 0
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>

This was supposed to emulate a SYN_REPORT event so that the upper layers
process what's in the queue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>

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>