Users should really consider switching to rmi-smbus instead of plain PS/2.
Notify them that they should report a missing pnpID in the file.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The Synaptics touchpads are now either using i2c-hid or rmi-smbus.
Warn the users if they are missing the rmi-smbus modules and have no
chance of reporting correct data.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Or the user might have the touchpad unbound from PS/2 but never picked
up by rmi-smbus.ko
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

synaptics_query_hardware() was being passed a 'struct synaptics_device_info'
in uninitialized stack memory, then not always initializing all fields.
This caused garbage to show up in certain fields, making the touchpad
unusable.

Fix by zeroing the device info, so all fields default to 0.

Fixes: 6c53694f ("Input: synaptics - split device info into a separate structure")
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The rest of the kernel uses u8, u16, etc for data coming form hardware,
let's switch ti using u8 here as well.

Also turn pkt_type into an enum.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Let's stop using -1 as a universal return value and instead propagate
errors from underlying calls up the stack.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Use standard infrastructure, such as BIT and GENMASK, instead of rolling
bitmasks by hand.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Factor out querying and parsing 3-byte response into an integer value.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Most of the Synaptics devices are connected through PS/2 and a different
bus (SMBus or HID over I2C). The secondary bus capability is indicated by
the InterTouch bit in extended capability 0x0C.

We only enable the InterTouch device to be created for the laptops
registered with the top software button property or those we know that are
functional. In the future, we might change the default to always rely on
the InterTouch bus. Currently, users can enable/disable the feature with
the psmouse parameter synaptics_intertouch.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

In preparation for SMBus/Intertouch device support, move static device
information that we query form the touchpad upon initialization into
separate structure. This will allow us to query the device without
allocating memory first.

Also stop using "unsigned long", everything fits into 32 bit chunks.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Let's stop using !!x to reduce value of trackstick button expression to 0/1
and use shift instead. This removes the following sparse warning:

  CHECK   drivers/input/mouse/synaptics.c
drivers/input/mouse/synaptics.c:943:79: warning: dubious: !x | y

Also, the bits we are testing are not capabilities, so lets drop "_CAP"
suffix from macro names.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of using custom method of "passing" extended buttons from the
touchpad to trackstick, let's switch to the newly introduced SERIO_OOB_DATA
channel.
Tested-By: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Looks like the fimware 8.2 still has the extra buttons spurious release
bug.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=114321
Cc: stable@vger.kernel.org
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This reverts commit e51e3849: we
actually do want the device to work in extended W mode, as this is the
mode that allows us receiving multiple contact information.

Cc: stable@vger.kernel.org

Bit 2 of the mode byte has dual meaning: it can disable reporting of
gestures when touchpad works in Relative mode or normal Absolute mode,
or it can enable so called Extended W-Mode when touchpad uses enhanced
Absolute mode (W-mode). The extended W-Mode confuses our driver and
causes missing button presses on some Thinkpads (x250, T450s), so let's
make sure we do not enable it.

Also, according to the spec W mode "... bit is defined only in Absolute
mode on pads whose capExtended capability bit is set. In Relative mode and
in TouchPads without this capability, the bit is reserved and should be
left at 0.", so let's make sure we respect this requirement as well.
Reported-by: NNick Bowler <nbowler@draconx.ca>
Suggested-by: NGabor Balla <gaborwho@gmail.com>
Tested-by: NGabor Balla <gaborwho@gmail.com>
Tested-by: NNick Bowler <nbowler@draconx.ca>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Make extended capabilities obtained through $10 query also available in
touchpad identification.
Signed-off-by: NJiri Kosina <jkosina@suse.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This reverts commit 63c4fda3 as it
causes issues with detecting 3-finger taps.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100481
Cc: stable@vger.kernel.org
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1223051#c2

Cc: stable@vger.kernel.org
Tested-by: tommy.gagnes@gmail.com
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When slowly dropping 1, 2 and then 3 fingers on an image sensor touchpad,
we can see that the first finger gets reassigned a new slot while it did
not move. This is due to the kernel tracking algorithm which can not assign
correctly the 3 touches, being out of slots.

Declaring that we support 3 slots allows to actually forward:
slot 0 -> down, slot 1 -> up, slot 2 -> down
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: Henrik Rydberg <rydberg@bitmath.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This reverts commit 09d042a2 ("Revert "Input: synaptics - use dmax in
input_mt_assign_slots"")

Now that balanced slots assignments seem to be fixed, let's re-enable the
use in synaptics.c and wait for users to complain if there are still
problems.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: Henrik Rydberg <rydberg@bitmath.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Commit 98dc0703 ("Input: synaptics - add quirk for Thinkpad E440") had
a typo in ymax, this changes the value to the one reported by
touchpad-edge-detector and mentioned in the commit.
Signed-off-by: NFilip Ayazi <filipayazi@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Its ClickPad shares PNP ID "LEN2006" with the one in model E540 which is
already handled by the driver (both are Haswell iterations of the Edge
line, launched in 2014) but the dimensions it reports are different:

  $ sudo ./touchpad-edge-detector /dev/input/event3
  Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event3
  Move one finger around the touchpad to detect the actual edges
  Kernel says: x [1472..5044], y [1408..3398]
  Touchpad sends: x [1024..5045], y [2457..4832] /^C

Fortunately we can use the board ID, which is also different, to
distinguish among them.

  $ dmesg | grep -i synaptics
  psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1,
      caps: 0xd001a3/0x940300/0x127c00, board id: 2691, fw id: 1494646
  psmouse serio1: synaptics: serio: Synaptics pass-through port at
      isa0060/serio1/input0
  input: SynPS/2 Synaptics TouchPad as
      /devices/platform/i8042/serio1/input/input4

Board ID in E540 is 2722:

  psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1,
      caps: 0xd001a3/0x940300/0x127c00, board id: 2722, fw id: 1484859

(from https://launchpadlibrarian.net/179702965/BootDmesg.txt)
Signed-off-by: NRamiro Morales <cramm0@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This reverts commit 6ab17a84 since it,
according to Benjamin, causes issues with slot assignment:

E: 15.669119 0000 0000 0000     # ------------ SYN_REPORT (0) ----------
E: 15.954242 0003 002f 0000     # EV_ABS / ABS_MT_SLOT          0
E: 15.954242 0003 0039 0505     # EV_ABS / ABS_MT_TRACKING_ID   505
E: 15.954242 0003 0035 3851     # EV_ABS / ABS_MT_POSITION_X    3851
E: 15.954242 0003 0036 4076     # EV_ABS / ABS_MT_POSITION_Y    4076
E: 15.954242 0003 003a 0034     # EV_ABS / ABS_MT_PRESSURE      34
E: 15.954242 0001 014a 0001     # EV_KEY / BTN_TOUCH            1
E: 15.954242 0003 0000 3851     # EV_ABS / ABS_X                3851
E: 15.954242 0003 0001 4076     # EV_ABS / ABS_Y                4076
E: 15.954242 0003 0018 0034     # EV_ABS / ABS_PRESSURE         34
E: 15.954242 0001 0145 0001     # EV_KEY / BTN_TOOL_FINGER      1
E: 15.954242 0000 0000 0000     # ------------ SYN_REPORT (0) ----------
... (bunch of regular events)...
E: 16.020614 0000 0000 0000     # ------------ SYN_REPORT (0) ----------
E: 16.043601 0003 0035 3873     # EV_ABS / ABS_MT_POSITION_X    3873
E: 16.043601 0003 0036 3903     # EV_ABS / ABS_MT_POSITION_Y    3903
E: 16.043601 0003 003a 0050     # EV_ABS / ABS_MT_PRESSURE      50
E: 16.043601 0003 0035 3032     # EV_ABS / ABS_MT_POSITION_X    3032
E: 16.043601 0003 0036 3832     # EV_ABS / ABS_MT_POSITION_Y    3832
E: 16.043601 0003 003a 0044     # EV_ABS / ABS_MT_PRESSURE      44
E: 16.043601 0003 0000 3032     # EV_ABS / ABS_X                3032
E: 16.043601 0003 0001 3832     # EV_ABS / ABS_Y                3832
E: 16.043601 0003 0018 0044     # EV_ABS / ABS_PRESSURE         44
E: 16.043601 0001 0145 0000     # EV_KEY / BTN_TOOL_FINGER      0
E: 16.043601 0001 014d 0001     # EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 16.043601 0000 0000 0000     # ------------ SYN_REPORT (0) ----------
E: 16.068837 0003 002f 0001     # EV_ABS / ABS_MT_SLOT          1
E: 16.068837 0003 0039 0506     # EV_ABS / ABS_MT_TRACKING_ID   506
E: 16.068837 0003 0035 3912     # EV_ABS / ABS_MT_POSITION_X    3912
E: 16.068837 0003 0036 3743     # EV_ABS / ABS_MT_POSITION_Y    3743
E: 16.068837 0003 003a 0056     # EV_ABS / ABS_MT_PRESSURE      56
E: 16.068837 0003 002f 0000     # EV_ABS / ABS_MT_SLOT          0
E: 16.068837 0003 0035 3026     # EV_ABS / ABS_MT_POSITION_X    3026
E: 16.068837 0003 0036 3708     # EV_ABS / ABS_MT_POSITION_Y    3708
E: 16.068837 0003 003a 0052     # EV_ABS / ABS_MT_PRESSURE      52
E: 16.068837 0003 0000 3026     # EV_ABS / ABS_X                3026
E: 16.068837 0003 0001 3708     # EV_ABS / ABS_Y                3708
E: 16.068837 0003 0018 0052     # EV_ABS / ABS_PRESSURE         52
E: 16.068837 0000 0000 0000     # ------------ SYN_REPORT (0) ----------

Slot 0 and 1 gets inverted in the second report above, which
introduces a cursor jump. The problem is that this cursor jump is
often enough to leave the current widget, and X sends the
scrolling events to whoever is now under the cursor.
Reported-by: NBenjamin Tissoires <btissoir@redhat.com>
Reported-by: NHans de Goede <hdegoede@redhat.com>

Lenovo X250 has a PnpID of LEN0046, but it does not have the top software
button requirement.

For the record, Lenovo T450s and W541 have a PnpID of LEN200f and LEN004a,
so they are not on the top software button list.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NDaniel Martin <consume.noise@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Lenovo decided to switch back to physical buttons for the trackstick on
their latest series. The PNPId list was provided before they reverted back
to physical buttons, so it contains the new models too.  We can know from
the touchpad capabilities that the touchpad has physical buttons, so
removing the ids from the list is not mandatory. It is still nicer to
remove the wrong ids, so start by removing the X1 Carbon 3rd gen, with the
PNPId of LEN0048.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The 2015 series of the Lenovo thinkpads added back the hardware buttons on
top of the touchpad for the trackstick.

Unfortunately, they are wired to the touchpad, and not the trackstick.
Thus, they are seen as extra buttons from the kernel point of view.

This leads to a problem in user space because extra buttons on synaptics
devices used to be used as scroll up/down buttons. So in the end, the
experience for the user is scroll events for buttons left and right when
using the trackstick. Yay!

Fortunately, the firmware advertises such behavior in the extended
capability $10, and so we can re-route the buttons through the pass-through
interface.
Hallelujah-expressed-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The 2015 series of the Lenovo thinkpads added back the hardware buttons on
top of the touchpad for the trackstick.

Unfortunately, Lenovo used the PNPIDs that are supposed to be "5 buttons"
touchpads, so the new laptops also have the INPUT_PROP_TOPBUTTONPAD. Yay!

Instead of manually removing each of the new ones, or hoping that we know
all the current ones, we can consider that the PNPIDs list that were given
contains touchpads that have the trackstick buttons, either physically
wired to them, or emulated with the top software button property.

Thanks to the extra buttons capability in query $10, we can reliably detect
the physical buttons from the software ones, and so we can remove the
TOPBUTTONPAD property even if it was declared as such.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Newer Synaptics touchpads need to get information from the query $10.
Retrieve it if available.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The board id capability has been added in firmware 7.5.

Cc: stable@vger.kernel.org
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The Fimware 8.1 has a bug in which the extra buttons are only sent when the
ExtBit is 1.  This should be fixed in a future FW update which should have
a bump of the minor version.

Cc: stable@vger.kernel.org
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On the X1 Carbon 3rd gen (with a 2015 broadwell cpu), the physical middle
button of the trackstick (attached to the touchpad serio device, of course)
seems to get lost.

Actually, the touchpads reports 3 extra buttons, which falls in the switch
below to the '2' case. Let's handle the case of odd numbers also, so that
the middle button finds its way back.

Cc: stable@vger.kernel.org
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Post-2013 Lenovo laptops provide correct min/max dimensions, which are
different with the ones currently quirked.  According to
https://bugzilla.kernel.org/show_bug.cgi?id=91541 the following board ids
are assigned in the post-2013 touchpads:

t440p/t440s: LEN0036 -> 2964/2962
t540p:       LEN0034 -> 2964

Using 2961 as the common minimum makes these 3 laptops OK. We may need
to update those values later if other pnp_ids has a lower board_id.

Cc: stable@vger.kernel.org
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add a min/max range for board ids to the min/max coordinates quirk. This
makes it possible to restrict quirks to specific models based upon their
board id. The define ANY_BOARD_ID (0) serves as a wild card.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Martin <daniel.martin@secunet.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The firmware of the X240 (LEN0035, 2013/12) exposes the same values
    x [1232..5710], y [1156..4696]
as the quirk applies.

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Martin <consume.noise@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Query the min dimensions even if the check
SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 7 fails, but we know that the
firmware version 8.1 is safe.

With that we don't need quirks for post-2013 models anymore as they expose
correct min and max dimensions.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Martin <consume.noise@gmail.com>
  re-order the tests to check SYN_CAP_MIN_DIMENSIONS even on FW 8.1
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Logging the dimension values we queried and the values we use from a quirk
to overwrite can be helpful for debugging.

This partly relates to bug:
    https://bugzilla.kernel.org/show_bug.cgi?id=91541

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Martin <consume.noise@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Split the function synaptics_resolution() into synaptics_resolution() and
synaptics_quirks().  synaptics_resolution() will be called before
synaptics_quirks() to query dimensions and resolutions before overwriting
them with quirks.

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Martin <consume.noise@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

According to Synaptics devices with ForcePads use SYN300D and SYN3014 as
PNP IDs, so let's switch from DMI-bases detection scheme to PNP-based
one, which should be more reliable.
Suggested-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of having various protocols provide <protocol>_supported()
functions, let's use IS_ENABLED() macro that works well in "if" statements.
Acked-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When tapping a clickpad with two fingers, there is a chance that the sensor
sees first only one finger, and at the next scan only the second one.  In
this case, the sensors says that there has been only one finger on the
clickpad, which moved really fast between two scans.

We can try to counter this by adding a limit to what an actual finger can
move between 2 scans.  A distance of 1cm between two scans for one finger
seems reasonable.  However, this is not really accurate because the
resolution in X and in Y differs. But heh, that's how the in-kernel
tracking works right now, and its job is quite good, even with this
approximation.

This parameter solves most of the jumps observed, not all of them however.
But this is a hardware defect, and we might not be able to get something
better without much heavier computations.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=76722Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>