Fixed the issue that two finger scroll does not work correctly
on V8 protocol. The cause is that V8 protocol X-coordinate decode
is wrong at SS4 PLUS device. I added SS4 PLUS X decode definition.

Mote notes:
the problem manifests itself by the commit e7348396 ("Input: ALPS
- fix V8+ protocol handling (73 03 28)"), where a fix for the V8+
protocol was applied.  Although the culprit must have been present
beforehand, the two-finger scroll worked casually even with the
wrongly reported values by some reason.  It got broken by the commit
above just because it changed x_max value, and this made libinput
correctly figuring the MT events.  Since the X coord is reported as
falsely doubled, the events on the right-half side go outside the
boundary, thus they are no longer handled.  This resulted as a broken
two-finger scroll.

One finger event is decoded differently, and it didn't suffer from
this problem.  The problem was only about MT events. --tiwai

Fixes: e7348396 ("Input: ALPS - fix V8+ protocol handling (73 03 28)")
Signed-off-by: NMasaki Ota <masaki.ota@jp.alps.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Tested-by: NPaul Donohue <linux-kernel@PaulSD.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Alps stick devices always have physical buttons, so we should not check
ALPS_BUTTONPAD flag to decide whether we should report them.

Fixes: 4777ac22 ("Input: ALPS - add touchstick support for SS5 hardware")
Signed-off-by: NMasaki Ota <masaki.ota@jp.alps.com>
Acked-by: NPali Rohar <pali.rohar@gmail.com>
Tested-by: NPaul Donohue <linux-kernel@PaulSD.com>
Tested-by: NNick Fletcher <nick.m.fletcher@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Devices identified as E7="73 03 28" use slightly modified version of V8
protocol, with lower count per electrode, different offsets, and different
feature bits in OTP data.

Fixes: aeaa881f ("Input: ALPS - set DualPoint flag for 74 03 28 devices")
Signed-off-by: NMasaki Ota <masaki.ota@jp.alps.com>
Acked-by: NPali Rohar <pali.rohar@gmail.com>
Tested-by: NPaul Donohue <linux-kernel@PaulSD.com>
Tested-by: NNick Fletcher <nick.m.fletcher@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Sort all devices in alps_model_data by signature and remove
command_mode_resp which is not used anymore.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Support for devices with ALPS_PROTO_V9 is not implemented yet but we can
detect these alps touchpads and warn users about it.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Like for other protocols create alps_v4_protocol_data and use it in
alps_identify() function.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

If a function declares a variable to access a structure element,
use it consistently.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The return value of alps_get_pkt_id_ss4_v2() should really be "enum
SS4_PACKET_ID", not "unsigned char".  Correct this.

Also, most of the Alps SS5 (SS4 v2) packet byte parsing code is implemented
using macros, but there are a few places where bytes are directly
manipulated in alps.c.  For consistency, migrate the rest of these to
macros.
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NPaul Donohue <linux-kernel@PaulSD.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

For consistency and clarity, the input_report_*() functions should be
called by alps_process_packet_ss4_v2() instead of by alps_decode_ss4_v2().
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NPaul Donohue <linux-kernel@PaulSD.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The current Alps SS5 (SS4 v2) code generates bogus TouchPad events when
TrackStick packets are processed.

This causes the xorg synaptics driver to print
"unable to find touch point 0" and
"BUG: triggered 'if (priv->num_active_touches > priv->num_slots)'"
messages.  It also causes unexpected TouchPad button release and re-click
event sequences if the TrackStick is moved while holding a TouchPad
button.

This commit corrects the problem by adjusting alps_process_packet_ss4_v2()
so that it only sends TrackStick reports when processing TrackStick
packets.
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NPaul Donohue <linux-kernel@PaulSD.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Here we introduce logic in alps_identify to set the ALPS_DUALPOINT flag
for touchpad hardware responding to E7 report with 73 03 28, as is found
in the Dell Latitude E7470.
Tested-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NBen Gamari <ben@smart-cactus.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The SS5 hardware can report this.
Tested-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NBen Gamari <ben@smart-cactus.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

While a button is held SS5 hardware will give us single-finger packets
with x, y, and pressure equal to zero. This causes annoying jumps in
pointer position if a touch is released while the button is held. Handle
this by claiming zero contacts to ensure that no position events are
provided to the user.
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NBen Gamari <ben@smart-cactus.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add touchstick support for the so-called SS5 hardware, which uses a
variant of the SS4 protocol.
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NBen Gamari <ben@smart-cactus.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This patch moves v3 pinnacle code for trackstick detection from
alps_hw_init_v3() to alps_set_protocol() so ALPS_DUALPOINT flag can be
cleared before registering trackstick input device in kernel.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This patch adds detection of trackstick for v7 protocol devices. Code in
this patch is used in official Dell touchpad linux drivers for Dell models:
Dell Latitude E5250/5250, E5450/5450, E5550/5550

Detection code and base reg for alps v3 rushmore and v7 devices is exacly
same.

Also user in bug https://bugzilla.kernel.org/show_bug.cgi?id=94801 reported
that Toshiba Sattellite Z30-A-1DG has only alps v7 touchpad device without
trackstick and kernel reports to userspace also redundant trackstick
device.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NAlex Hung <alex.hung@canonical.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

commit 92bac83d ("Input: alps - non interleaved V2 dualpoint has
separate stick button bits") assumes that all alps v2 non-interleaved
dual point setups have the separate stick button bits.

Later we limited this to Dell laptops only because of reports that this
broke things on non Dell laptops. Now it turns out that this breaks things
on the Dell Latitude D600 too. So it seems that only the Dell Latitude
D420/430/620/630, which all share the same touchpad / stick combo,
have these separate bits.

This patch limits the checking of the separate bits to only these models
fixing regressions with other models.
Reported-and-tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: stable@vger.kernel.org
Tested-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-By: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

It turns out that only Dell laptops have the separate button bits for
v2 dualpoint sticks and that commit 92bac83d ("Input: alps - non
interleaved V2 dualpoint has separate stick button bits") causes
regressions on Toshiba laptops.

This commit adds a check for Dell laptops to the code for handling these
extra button bits, fixing this regression.

This patch has been tested on a Dell Latitude D620 to make sure that it
does not reintroduce the original problem.
Reported-and-tested-by: NDouglas Christman <douglaschristman@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On some v7 devices (e.g. Lenovo-E550) the deltas reported are typically
only in the 0-1 range dividing this by 2 results in a range of 0-0.

And even for v7 devices where this does not lead to making the trackstick
entirely unusable, it makes it twice as slow as before we added v7 support
and were using the ps/2 mouse emulation of the dual point setup.

If some kind of generic slowdown is actually necessary for some devices,
then that belongs in userspace, not in the kernel.

Cc: stable@vger.kernel.org
Reported-and-tested-by: NRico Moorman <rico.moorman@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On v7 touchpads sometimes when 2 fingers are moved down on the touchpad
until they "fall of" the touchpad, the second touch will report 0 for y
(max y really since the y axis is inverted) and max x as coordinates,
rather then reporting 0, 0 as is expected for a non touching finger.

This commit detects this and treats these touches as non touching.

See the evemu-recording here:
https://bugzilla.redhat.com/attachment.cgi?id=1025058

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1221200Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Now that the generic process_bitmap function has been improved to offer
accurate coordinates for the first touch we can use it for v5 (dolphin)
touchpads too.

Besides being a nice code cleanup this also fixes the saw tooth pattern
in the coordinates for the second touch the dolphin specific version had.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Rename alps_set_abs_params_mt to alps_set_abs_params_semi_mt,
to make it clear that it is only (to be) used for semi-mt devices.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

With the recent process_bitmap() changes all semi-mt devices always report
the first finger down in slot 0, so stop using input-mt finger tracking
for these.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

All alps semi-mt touchpads give us the following data when 2 (or more)
fingers are touching: 1 more or less accurate touch for the first finger
down, and a bitmap with columns and rows in which 1 or more fingers are
seen resulting in a crude (low res) bounding box.

So far for v3, rushmore and v4 touchpads we've been reporting the
coordinates of 2 opposite corners of the box when 2 fingers are touching.
Ignoring the much better resolution data given in the normal position
packet.

This commit actually uses this data for the first touch, figures out which
corner of the bounding box is closest to the first touch, and reports the
coordinates of the opposite corner for the second touch, resulting in
much better data for the first touch and for the single touch
pointer-emulation events.

This approach is similar to the one in alps_process_bitmap_dolphin, that
function takes the single accurate touch info, calculates the distance to
the center of the bounding box, and then puts the 2nd touch mirrored to
the center. The downside of that approach is that if both touches move
slowly in the same direction, the bounding box will stay the same for a
while (as it is low res) and the second touch will thus been seen moving
in the opposite direction until the bounding box actually changes, and
then the second touch snaps to its new position resulting in a saw tooth
pattern in the coordinates for the second touch, hence this new approach.

This commit fixes 2 finger scrolling being choppy / jumpy on these
touchpads.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

We should decode the position packet before the packet with the bitmap
data.  This way we can use the more accurate position info in
process_bitmap() to get better results.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Pinnacle / Rushmore packets contain either position info, or bitmap info,
never both. So far we've in essence been storing garbage in the position /
bitmap fields of the fields struct when decoding a bitmap / pos packet.

We've been relying on the following sequence to get away with this:

1) Decode bitmap packet
2) Process bitmap packet
3) Decode position packet
4) Use position / button info

This patch allows us to change this sequence, which will allow using the
position info when processing the bitmap for more accurate results.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Change alps_decode_rushmore to do all decoding itself, rather then relying
on alps_decode_pinnacle and then overriding some fields + or-ing in some
bits.

This is a preparation patch for modifying the decode functions to properly
differentiate between position and bitmap packets.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Non interleaved V2 dualpoint touchpad / stick combos have separate stick
button bits in the touchpad packets, if we do not check these then the
trackpoint buttons will not work when using the touchpad, and when pressed
when the user starts using the touchpad will report a release event even
though the button is still pressed.

This commit fixes this by checking the separate bits, note that we simply
combine the buttons, since the hardware does the same when using the touchpad
buttons with the trackpoint, so we do not have enough information to properly
separate them.
Reported-by: NHans de Bruin <jmdebruin@xmsnet.nl>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When the left touchpad button gets pressed, and then the trackpoint is
moved, and then the button is released, the following happens:

1) touchpad packet is received, touchpad evdev node reports BTN_LEFT 1

2) pointing stick packet is received, the hw will report a BTN_LEFT 1 in
   this packet because when the trackstick is active it communicates the
   combined touchpad + pointing stick buttons in the trackstick packet,
   since alps_report_bare_ps2_packet passes NULL (*) for the dev2 parameter
   to alps_report_buttons the combining is not detected and the
   pointing stick evdev node will also report BTN_LEFT 1

3) on release of the button a pointing stick packet with BTN_LEFT 0 is
   received and the pointing stick evdev node will report BTN_LEFT 0

Note how because of the passing as NULL for dev2 the touchpad evdev node
will never send BTN_LEFT 0 in this scenario leading to a stuck mouse button.

This is a regression in 4.0 introduced by commit 04aae283
("Input: ALPS - do not mix trackstick and external PS/2 mouse data")

This commit fixes this by passing in the touchpad evdev as dev2 parameter
when calling alps_report_buttons for the pointingstick on alps v2 devices,
so that alps_report_buttons correctly detect that we're already reporting
the button as pressed via the touchpad evdev node, and will also send the
release event there.

Cc: stable@vger.kernel.org # 4.0
Reported-by: NHans de Bruin <jmdebruin@xmsnet.nl>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: NMasaki Ota <masaki.ota@jp.alps.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This change adds support for SS4 touchpad devices as ALPS_PROTO_V8
protocol.  They are real multi-touch devices and can be found in TOSHIBA
Tecra C50.
Signed-off-by: NMasaki Ota <masaki.ota@jp.alps.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

In preparation for adding support for SS4 touchpads, let's split
alps_set_abs_params_mt into common, v7-specific, and other protocols
portions.
Signed-off-by: NMasaki Ota <masaki.ota@jp.alps.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On V2 devices the DualPoint Stick reports bare packets, these should be
reported via the "AlpsPS/2 ALPS DualPoint Stick" dev2 evdev node, which also
has the INPUT_PROP_POINTING_STICK propbit set.

Note that since there is no way to distinguish these packets from an external
PS/2 mouse (insofar as these laptops have an external PS/2 port) this means
that we will be reporting PS/2 mouse events via this evdev node too, as we've
been doing in kernel 3.19 and older.

This has been tested on a Dell Latitude D620 and a Dell Latitude E6400,
which both have a V2 touchpad + a DualPoint Stick which reports bare packets.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Bare packets should be reported via the same evdev device independent on
whether they are detected on the beginning of a packet or in the middle
of a packet.

This has been tested on a Dell Latitude E6400, where the DualPoint Stick
reports bare packets, which get reported via dev3 when the touchpad is
idle, and via dev2 when the touchpad and stick are used simultaneously.

This commit fixes this inconsistency by always reporting bare packets via
dev3. Note that since the come from a DualPoint Stick they really should be
reported via dev2, this gets fixed in a later commit.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Commit 3296f71c ("Input: ALPS - consolidate
setting protocol parameters") inadvertently moved call to
alps_dolphin_get_device_area() from v5 to v7 protocol, causing both
protocols report incorrect maximum values for X and Y axes which resulted
in crash in Synaptics X driver.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94801Reported-by: NSantiago Gala <sgala@apache.org>
Reported-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This fixes memory leak introduced by commit
a09221e8Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This patch move all packet info from driver source code to documentation
and adds info about v6 packet format (from driver source code).
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The comment about suspicions entry 0x20, 0x02, 0x0e has over time drifted
away and it become hard to figure out what it meant. Let's move it back so
it is clear.
Reported-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Previously dev2 device was used for both external PS/2 mouse and internal
trackstick device (if available). This change introduces dev3 device which
is used for external PS/2 mouse data and dev2 is now used only for
trackstick.

In case that trackstick is not present dev2 is not created, so userspace
does not see non existent device in system.

Because laptops with ALPS devices often do not use i8042 active
multiplexing all data (from touchpad, trackstick and external PS/2 mouse)
come to one port.  So it is not possible to know if external PS/2 mouse is
connected or not. In most cases external PS/2 mouse is not connected so
driver will create dev3 input device after first bare PS/2 packet will be
received. So there will not be "ghost" input device.

This change also helps in identifying possible problems in future if driver
decides to report 6-bytes trackstick packets as 3-bytes bare PS/2 (data
will be reported to dev3 instead dev2).
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>