Sometimes on Dell Latitude laptops psmouse/alps driver receive invalid ALPS
protocol V3 packets with bit7 set in last byte. More often it can be
reproduced on Dell Latitude E6440 or E7440 with closed lid and pushing
cover above touchpad.

If bit7 in last packet byte is set then it is not valid ALPS packet. I was
told that ALPS devices never send these packets. It is not know yet who
send those packets, it could be Dell EC, bug in BIOS and also bug in
touchpad firmware...

With this patch alps driver does not process those invalid packets, but
instead of reporting PSMOUSE_BAD_DATA, getting into out of sync state,
getting back in sync with the next byte and spam dmesg we return
PSMOUSE_FULL_PACKET. If driver is truly out of sync we'll fail the checks
on the next byte and report PSMOUSE_BAD_DATA then.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NPali Rohár <pali.rohar@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On some Dell Latitude laptops ALPS device or Dell EC send one invalid byte
in 6 bytes ALPS packet. In this case psmouse driver enter out of sync
state. It looks like that all other bytes in packets are valid and also
device working properly. So there is no need to do full device reset, just
need to wait for byte which match condition for first byte (start of
packet). Because ALPS packets are bigger (6 or 8 bytes) default limit is
small.

This patch increase number of invalid bytes to size of 2 ALPS packets which
psmouse driver can drop before do full reset.

Resetting ALPS devices take some time and when doing reset on some Dell
laptops touchpad, trackstick and also keyboard do not respond. So it is
better to do it only if really necessary.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NPali Rohár <pali.rohar@gmail.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

5th and 6th byte of ALPS trackstick V3 protocol match condition for first
byte of PS/2 3 bytes packet. When driver enters out of sync state and ALPS
trackstick is sending data then driver match 5th, 6th and next 1st bytes as
PS/2.

It basically means if user is using trackstick when driver is in out of
sync state driver will never resync. Processing these bytes as 3 bytes PS/2
data cause total mess (random cursor movements, random clicks) and make
trackstick unusable until psmouse driver decide to do full device reset.

Lot of users reported problems with ALPS devices on Dell Latitude E6440,
E6540 and E7440 laptops. ALPS device or Dell EC for unknown reason send
some invalid ALPS PS/2 bytes which cause driver out of sync. It looks like
that i8042 and psmouse/alps driver always receive group of 6 bytes packets
so there are no missing bytes and no bytes were inserted between valid
ones.

This patch does not fix root of problem with ALPS devices found in Dell
Latitude laptops but it does not allow to process some (invalid)
subsequence of 6 bytes ALPS packets as 3 bytes PS/2 when driver is out of
sync.

So with this patch trackstick input device does not report bogus data when
also driver is out of sync, so trackstick should be usable on those
machines.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NPali Rohár <pali.rohar@gmail.com>
Cc: stable@vger.kernel.org
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Since the change to struct input_mt_pos some variables are now bitfields
instead of integers. Automatic conversion from integer to bitfield entry
destroys information, therefore enforce boolean interpretation instead.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1114768
Fixes: 02d04254 ("Input: alps - use struct input_mt_pos to track coordinates")
Signed-off-by: NAndreas Bosch <linux@progandy.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

I've not done a full audit of all mouse drivers, I noticed these ones were
missing the POINTER property while working on the POINTING_STICK property.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

It is useful for userspace to know that there not dealing with a regular
mouse but rather with a pointing stick (e.g. a trackpoint) so that
userspace can e.g. automatically enable middle button scrollwheel
emulation.

It is impossible to tell the difference from the evdev info without
resorting to putting a list of device / driver names in userspace, this is
undesirable.

Add a property which allows userspace to see if a device is a pointing
stick, and set it on all the pointing stick drivers.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When we fail to match data returned by E7 and EC reports we state that we
found "Unknown ALPS touchpad" whereas it is most likely it is not ALPS
touchpad at all. Change wording a bit and reduce the message to debug so
that it does not litter users logs and confuse them.
Reported-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add support for querying the physical size from the touchpad for Rushmore
and v7 touchpads, and use that to tell userspace the device resolution.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Such as found on the new Toshiba Portégé Z30-A and Z40-A.
Signed-off-by: NYunkang Tang <yunkang.tang@cn.alps.com>
[hdegoede@redhat.com: Remove softbutton handling, this is done in userspace]
[hdegoede@redhat.com: Report INPUT_PROP_BUTTONPAD]
[hdegoede@redhat.com: Do not report fake PRESSURE, reporting BTN_TOUCH is
 enough]
[hdegoede@redhat.com: Various cleanups / refactoring]
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

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

So that decode functions can return a failure when appropriate.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

If we detect more then 2 fingers report 2 touches, rather then only
reporting the upper left corner of the bounding box.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Move all the semi-mt specific handling shared between the v3 and v4
handling code to a common helper function.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

For v3 protocol devices, use the more accurate single touch data when the
mt data contains only one finger. Note the mt data reporting a finger count
of 1 should never happen, but better safe then sorry.

This brings the v3 bitmap handling in line with what the v4 code does,
allowing to factor out the common bits into a helper function.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When there are 2 fingers on the pad we don't know which one is which, so
use input_mt_assign_slots to make sure the right set of coordinates ends
up in the right slot.

Besides ensuring things end up in the right slot, this also results in a
nice cleanup, since sync_frame also handles non mt position and btn_touch
reporting.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This is a preparation patch for switching the DIY mt handling to using
input_mt_assign_slots && input_mt_sync_frame.

struct alps_fields is quite large, so while making changes to almost all uses
of it lets put it in our priv data instead of on the stack.

Having it in our priv data also allows using it directly for storing values
which need to be cached, rather then having separate x, y, z, fingers, etc.
copies in our priv data.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This fixes 2 fingers at the same height or width on the touchpad getting
reported at different y / x coordinates.

Note num_bits is always at least 1.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

alps_process_bitmap was resetting the point bit-count as soon as it saw
2 0 bits in a row. This means that unless the high point actually is at
the end of the bitmap, it would always get its num_bits set to 0.

Instead reset num_bits to 0 on a 0->1 transition, so that with > 2 fingers
we only count the number of bits occupied by the highest finger.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Factor out the identical code for getting the bitmap points for x and y into
a helper function.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Rushmore models don't have the Y-axis data in the bitmap inverted. Since
we now have 2 different Y orientations, make the Y bitmap data processing
use a forward loop like the X bitmap data processing, unifying the 2,
and invert the data later, except on Rushmore.

So far no-one has noticed this because the synaptics driver only uses the
non mt coordinates (except on clickpads, and there are no alps clickpads
using process_bitmap).
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

V3 models only report mt bitmap data when there are 2 or more fingers on
the touchpad. So always generate 2 positions in alps_process_bitmap, and
for v3 models only fall back to st data when there was no mt data in a
mt packet (which should never happen).

This fixes 2 finger scrolling not working when using 2 fingers close to
each other.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: NYunkang Tang <yunkang.tang@cn.alps.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This adds support for another flavor of ALPS protocol used in newer
"Dolphin" devices.
Signed-off-by: NYunkang Tang <yunkang.tang@cn.alps.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The device uses special MPU controller that necessitates the new
initialization sequence for the device. We also define a new protocol for
the trackpad that allows reporting better resolution than older V2
protocol.
Signed-off-by: NYunkang Tang <yunkang.tang@cn.alps.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This reverts commit 5beea882 as it
breaks trackpoint operation on XT2.

This patch adds support for touchpad found on Dell XT2. It's a dual device
with device ID: 73, 00, 14, that comply with "ALPS_PROTO_V2".
Signed-off-by: NYunkang Tang <yunkang.tang@cn.alps.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Change the dev2's name from "PS/2 Mouse" to "ALPS PS/2 Device".
Signed-off-by: NYunkang Tang <yunkang.tang@cn.alps.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This form is more concise.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

These touchpads use a different protocol; they have been seen on Dell
N5110, Dell 17R SE, and others.

The official ALPS driver identifies them by looking for an exact match
on the E7 report: 73 03 50.  Dolphin V1 returns an EC report of
73 01 xx (02 and 0d have been seen); Dolphin V2 returns an EC report of
73 02 xx (02 has been seen).

Dolphin V2 probably needs a different initialization sequence and/or
report parser, so it is left for a future commit.
Signed-off-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Now that alps_identify() explicitly issues an EC report using
alps_rpt_cmd(), we no longer need to look at the magic numbers returned
by alps_enter_command_mode().
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Separate out the common trackstick probe/setup sequences, then call them
from each of the v3 init functions.

Credits: Emmanual Thome furnished the information on the trackstick init
and how it affected the report format.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Tested-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Rushmore touchpads are found on Dell E6230/E6430/E6530.  They use the V3
protocol with slightly tweaked init sequences and report formats.

The E7 report is 73 03 0a, and the EC report is 88 08 1d

Credits: Emmanuel Thome reported the MT bitmap changes.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Tested-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

A number of different ALPS touchpad protocols can reuse
alps_process_touchpad_packet_v3() with small tweaks to the bitfield
decoding.  Create a new priv->decode_fields() callback that handles the
per-model differences.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Tested-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Newer touchpads use different constants, so make them runtime-
configurable.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Tested-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Pinnacle class devices should return "88 07 xx" or "88 08 xx" when
entering command mode.  If either the first byte or the second byte is
invalid, return an error.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Tested-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The official ALPS driver uses the EC report, not the E7 report, to detect
these devices.  Also, they check for a range of values; the original
table-based code only checked for two specific ones.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Tested-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This allows alps_identify() to override these settings based on the
device characteristics, if it is ever necessary.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Tested-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

In anticipation of adding more ALPS protocols and more per-device quirks,
use function pointers instead of switch statements to call functions that
differ from one device to the next.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Tested-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

If the E6 report test passes, get the E7 and EC reports right away and
then try to match an entry in the table.

Pass in the alps_data struct, so that the detection code will be able to
set operating parameters based on information found during detection.

Change the version (psmouse->model) to report the protocol version only,
in preparation for supporting models that do not show up in the ID table.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Tested-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Several ALPS driver init sequences repeat a command three times, then
issue PSMOUSE_CMD_GETINFO to read the result.  Move this into a helper
function to simplify the code.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Tested-by: NDave Turvene <dturvene@dahetral.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>