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>

Some devices are not fast enough to differentiate between a fast-moving
contact and a new contact. This problem cannot be fully resolved because
information is truly missing, but it is possible to safe-guard against
obvious mistakes by restricting movement with a maximum displacement.

The new problem formulation for dmax > 0 cannot benefit from the speedup
for positive definite matrices, but since the convergence is faster, the
result is about the same. For a handful of contacts, the latency difference
is truly negligible.
Suggested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NHenrik Rydberg <rydberg@bitmath.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

LEN0037 found in the Lenovo ThinkPad X1 Carbon 2nd (2014 model)

Cc: stable@vger.kernel.org
Reported-and-tested-by: NBjoern Olausson <bjoern@olausson.de>
Signed-off-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

synaptics_profile_sensor_process() and synaptics_report_mt_data() now
share the exact same code. Remove one implementation and rely on the
other where it was used.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The current code tries to consider all states and transitions to properly
detect which finger is attached to which slot. The code is quite huge
and difficult to read.

If the sensor manages to group the touch points but is not reliable in
giving tracking ids, we can simply use the kernel tracking method. Note
that it is already used by Cr-48 Chromebooks.

Incidentaly, this fixes a bug reported by Peter Hutterer:
"""
on the Lenovo T440, run:
evemu-record /dev/input/event4 | grep BTN_

then put one, two, three, two fingers down
when you go from 3 to 2 fingers the driver sends a spurious BTN_TOUCH 0
event:

E: 0.000000 0001 014a 0001      # EV_KEY / BTN_TOUCH            1
E: 0.000000 0001 0145 0001      # EV_KEY / BTN_TOOL_FINGER      1
E: 0.770008 0001 0145 0000      # EV_KEY / BTN_TOOL_FINGER      0
E: 0.770008 0001 014d 0001      # EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 1.924716 0001 014d 0000      # EV_KEY / BTN_TOOL_DOUBLETAP   0
E: 1.924716 0001 014e 0001      # EV_KEY / BTN_TOOL_TRIPLETAP   1

.. changing from 3 to 2 fingers now

E: 3.152641 0001 014a 0000      # EV_KEY / BTN_TOUCH            0
E: 3.152641 0001 014d 0001      # EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 3.152641 0001 014e 0000      # EV_KEY / BTN_TOOL_TRIPLETAP   0
E: 3.176948 0001 014a 0001      # EV_KEY / BTN_TOUCH            1

quick look in the kernel shows it's caused by hw.z going to 0 for a packet,
so probably a firmware bug. either way, it makes it hard to track BTN_TOUCH
as signal that at least one finger is down.
"""

The in-kernel tracking is enough to remove this spurious BTN_TOUCH 0.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The LEN2006 Synaptics touchpad (as found in Thinkpad E540) returns wrong
min max values.

touchpad-edge-detector output:
>  Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event6
>  Move one finger around the touchpad to detect the actual edges
>  Kernel says:    x [1472..5674], y [1408..4684]
>  Touchpad sends: x [1264..5675], y [1171..4688]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88211
Cc: stable@vger.kernel.org
Signed-off-by: NBinyamin Sagal <bensagal@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The new Lenovo T440s laptop has a different PnP ID "LEN0039", and it
needs the similar min/max quirk to make its clickpad working.

BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=903748Reported-and-tested-by: NJoschi Brauchle <joschibrauchle@gmx.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Unfortunately, ForcePad capability is not actually exported over PS/2, so
we have to resort to DMI checks.

Cc: stable@vger.kernel.org
Reported-by: NNicole Faerber <nicole.faerber@kernelconcepts.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The matches_pnp_id function from the synaptics driver is useful for other
drivers too. Make it a generic psmouse helper function.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

ForcePads are found on HP EliteBook 1040 laptops. They lack any kind of
physical buttons, instead they generate primary button click when user
presses somewhat hard on the surface of the touchpad. Unfortunately they
also report primary button click whenever there are 2 or more contacts
on the pad, messing up all multi-finger gestures (2-finger scrolling,
multi-finger tapping, etc). To cope with this behavior we introduce a
delay (currently 50 msecs) in reporting primary press in case more
contacts appear.

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

The profile sensor clickpad in a Cr-48 Chromebook does a reasonable job
of tracking individual fingers. This tracking isn't perfect, but,
experiments show that it works better than just passing "semi-mt" data
to userspace, and making userspace try to deduce where the fingers are
given a bounding box.

This patch tries to report correct two-finger positions instead of the
{(min_x, min_y), (max_x, max_y)} for profile sensor clickpads on Cr-48
chromebooks. Note that this device's firmware always reports the higher
(smaller y) finger in the "sgm" packet, and the lower (larger y) finger
in the "agm" packet. Thus, when a new finger arrives on the pad, the
kernel driver uses input core's contact tracking facilities to match
contacts with slots.

Inspired by patch by Daniel Kurtz <djkurtz@chromium.org> and Chung-yih
Wang <cywang@chromium.org>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Semi-MT devices are pointers too, so let's tell that to
input_mt_init_slots(), as well as let it set up the devices as semi-MT,
instead of us doing it manually.
Reviewed-by: NDaniel Kurtz <djkurtz@chromium.org>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1114768

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