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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Dmitry 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Newer Synaptics touchpads need to get information from the query $10.
Retrieve it if available.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The board id capability has been added in firmware 7.5.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Daniel Martin <daniel.martin@secunet.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Daniel Martin <consume.noise@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Daniel Martin <consume.noise@gmail.com>
re-order the tests to check SYN_CAP_MIN_DIMENSIONS even on FW 8.1
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Daniel Martin <consume.noise@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Daniel Martin <consume.noise@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Hans de Goede <hdegoede@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry 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: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry 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=76722
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Henrik Rydberg <rydberg@bitmath.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUsuDQAAoJEHm+PkMAQRiGnecH/0RO9UKnEduOTRPaZGXAjGI8
N0FvNia8qn7f+XnvN62pG/YZZqi2uvuy37vwAXMtS6KXEgaDG9Wq4fVrhOaJ5VgL
QOmPdVGUa+1PuPcMYj/QLIFRfIHvIY/XVZWXrcIyYfQdBAAoJ2q23qx/yFmdyTwf
+enAv+PV4ZVNMEANyN9KS7xX5gPbSDl36AOhm6lXDvrlem4mbnhRuUtYez9R8KTK
VNfkKZQRDOgl4/ns0ndzpAUhaDj1JJGoLRgMXKna33XgtzSEL4XijvImdnoIXp5N
Z98Jc1N5Vg5OcUFeGJC3bRR27m39xoOHQk2ufY43uAIfB3Ez/C7m/r7b50ZVWfs=
=J7TO
-----END PGP SIGNATURE-----
Merge tag 'v3.19-rc4' into next
Merge with mainline to bring in the latest thermal and other changes.
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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry 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: Binyamin Sagal <bensagal@gmail.com>
Signed-off-by: Dmitry 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=903748
Reported-and-tested-by: Joschi Brauchle <joschibrauchle@gmx.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dmitry 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: Nicole Faerber <nicole.faerber@kernelconcepts.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUMZqoAAoJEHm+PkMAQRiGFC4H/i0b9vxCwe6VCXonpaDW03fI
JKE7v/zwDfhDngKSYfBWRSf3jXwfSHLvAvCgIvqTw5qBW3XSWF8xB7kJpWptQxIi
M6ePfaETt2mPYhEWWWxJK8boykiOXObDrFJVhfjHGsjbvmKiLPMaGYwXTSwZJ32V
fQDaA9Piugjc9wEY0d+6cjqUUEwlb4+GFz4Wv2oJgbpzxwgJS/XjQYk+3PrcdAXz
lmwPXQ+6ntJaducVu3JM2YYvaJLzTw+T+MPsWiTvaE4ILmuiw492VNY5XdyQQtb2
DSActOKCF2hIwnG+DMg63XV5FH81HqczwORDygBuxko0cURxupxMnaLPkVRpksk=
=+PRQ
-----END PGP SIGNATURE-----
Merge tag 'v3.17' into next
Synchronize with mainline to bring in changes to Synaptics and i8042
drivers.
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry 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: Henrik Rydberg <rydberg@euromail.se>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Dmitry 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: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
commit 421e08c41f fixed the reported min/max for the X and Y axis,
but unfortunately, it broke the resolution of those same axis.
On the t540p, the resolution is the same regarding X and Y. It is not
a problem for xf86-input-synaptics because this driver is only interested
in the ratio between X and Y.
Unfortunately, xf86-input-cmt uses directly the resolution, and having a
null resolution leads to some divide by 0 errors, which are translated by
-infinity in the resulting coordinates.
Reported-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Most of the affected models share pnp-ids for the touchpad. So switching
to pnp-ids give us 2 advantages:
1) It shrinks the quirk list
2) It will lower the new quirk addition frequency, ie the recently added W540
quirk would not have been necessary since it uses the same LEN0034 pnp ids
as other models already added before it
As an added bonus it actually puts the quirk on the actual psmouse, rather
then on the machine, which is technically more correct.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This is a preparation patch for simplifying the min/max quirk table.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The T540p has a touchpad with pnp-id LEN0034, all the models with this
pnp-id have the same min/max values, except the T540p where the values are
slightly off. Fix them to be identical.
This is a preparation patch for simplifying the quirk table.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We expect that all the Haswell series will need such quirks, sigh.
The T431s seems to be T430 hardware in a T440s case, using the T440s touchpad,
with the same min/max issue.
The X1 Carbon 3rd generation name says 2nd while it is a 3rd generation.
The X1 and T431s share a PnPID with the T540p, but the reported ranges are
closer to those of the T440s.
HdG: Squashed 5 quirk patches into one. T431s + L440 + L540 are written by me,
S1 Yoga and X1 are written by Benjamin Tissoires.
Hdg: Standardized S1 Yoga and X1 values, Yoga uses the same touchpad as the
X240, X1 uses the same touchpad as the T440.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD
property for for touchpads with top button areas.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This extends Benjamin Tissoires manual min/max quirk table with support for
the ThinkPad X240.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad.
However, these new Synaptics devices report bad axis ranges.
Under Windows, it is not a problem because the Windows driver uses RMI4
over SMBus to talk to the device. Under Linux, we are using the PS/2
fallback interface and it occurs the reported ranges are wrong.
Of course, it would be too easy to have only one range for the whole
series, each touchpad seems to be calibrated in a different way.
We can not use SMBus to get the actual range because I suspect the firmware
will switch into the SMBus mode and stop talking through PS/2 (this is the
case for hybrid HID over I2C / PS/2 Synaptics touchpads).
So as a temporary solution (until RMI4 land into upstream), start a new
list of quirks with the min/max manually set.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
CC: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
__initconst should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
In summary, the symptom is intermittent key events lost after resume
on some machines with synaptics touchpad (seems this is synaptics _only_),
and key events loss is due to serio port reconnect after psmouse sync lost.
Removing psmouse and inserting it back during the suspend/resume process
is able to work around the issue, so the difference between psmouse_connect()
and psmouse_reconnect() is the key to the root cause of this problem.
After comparing the two different paths, synaptics driver has its own
implementation of synaptics_reconnect(), and the missing psmouse_probe()
seems significant, the patch below added psmouse_probe() to the reconnect
process, and has been verified many times that the issue could not be reliably
reproduced.
There are two PS/2 commands in psmouse_probe():
1. PSMOUSE_CMD_GETID
2. PSMOUSE_CMD_RESET_DIS
Only the PSMOUSE_CMD_GETID seems to be significant. The
PSMOUSE_CMD_RESET_DIS is irrelevant to this issue after trying
several times. So we have only implemented this patch to issue
the PSMOUSE_CMD_GETID so far.
Tested-by: Daniel Manrique <daniel.manrique@canonical.com>
Signed-off-by: James M Leddy <james.leddy@canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To properly setup event parameters for emulated events, pass
the appropriate flag to the slot initialization function. Also,
all MT-related events should be setup before initialization.
Incidentally, this solves the issue of doubly filtered pointer
events.
Reported-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Investigating the following gesture highlighted two slight implementation
errors with choosing which slots to report in which slot when multiple
contacts are present:
Action SGM AGM (MTB slot:Contact)
1. Touch contact 0 (0:0)
2. Touch contact 1 (0:0, 1:1)
3. Lift contact 0 (1:1)
4. Touch contacts 2,3 (0:2, 1:3)
In step 4, slot 1 was not being cleared first, which means the same
tracking ID was being used for reporting both the old contact 1 and the
new contact 3. This could result in "drumroll", where the old contact 1
would appear to suddenly jump to new finger 3 position.
Similarly, if contacts 2 & 3 are not detected at the same sample, step 4
is split into two:
Action SGM AGM (MTB slot:contact)
1. Touch contact 0 (0:0)
2. Touch contact 1 (0:0, 1:1)
3. Lift contact 0 (1:1)
4. Touch contact 2 (0:2, 1:1)
5. Touch contact 3 (0:2, 1:3)
In this case, there was also a bug. In step 4, when contact 1 moves from
SGM to AGM and contact 2 is first reported in SGM, slot 0 was actually
empty. So slot 0 can be used to report the new SGM (contact 0),
immediately. Since it was empty, contact 2 in slot 0 will get a new
tracking ID.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Pull input updates from Dmitry Torokhov:
"A few drivers were updated with device tree bindings and others got a
few small cleanups and fixes."
Fix trivial conflict in drivers/input/keyboard/omap-keypad.c due to
changes clashing with a whitespace cleanup.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (28 commits)
Input: wacom - mark Intuos5 pad as in-prox when touching buttons
Input: synaptics - adjust threshold for treating position values as negative
Input: hgpk - use %*ph to dump small buffer
Input: gpio_keys_polled - fix dt pdata->nbuttons
Input: Add KD[GS]KBDIACRUC ioctls to the compatible list
Input: omap-keypad - fixed formatting
Input: tegra - move platform data header
Input: wacom - add support for EMR on Cintiq 24HD touch
Input: s3c2410_ts - make s3c_ts_pmops const
Input: samsung-keypad - use of_get_child_count() helper
Input: samsung-keypad - use of_match_ptr()
Input: uinput - fix formatting
Input: uinput - specify exact bit sizes on userspace APIs
Input: uinput - mark failed submission requests as free
Input: uinput - fix race that can block nonblocking read
Input: uinput - return -EINVAL when read buffer size is too small
Input: uinput - take event lock when fetching events from buffer
Input: get rid of MATCH_BIT() macro
Input: rotary-encoder - add DT bindings
Input: rotary-encoder - constify platform data pointers
...
Commit c039450 (Input: synaptics - handle out of bounds values from the
hardware) caused any hardware reported values over 7167 to be treated as
a wrapped-around negative value. It turns out that some firmware uses
the value 8176 to indicate a finger near the edge of the touchpad whose
actual position cannot be determined. This value now gets treated as
negative, which can cause pointer jumps and broken edge scrolling on
these machines.
I only know of one touchpad which reports negative values, and this
hardware never reports any value lower than -8 (i.e. 8184). Moving the
threshold for treating a value as negative up to 8176 should work fine
then for any hardware we currently know about, and since we're dealing
with unspecified behavior it's probably the best we can do. The special
8176 value is also likely to result in sudden jumps in position, so
let's also clamp this to the maximum specified value for the axis.
BugLink: http://bugs.launchpad.net/bugs/1046512https://bugzilla.kernel.org/show_bug.cgi?id=46371
Cc: stable@vger.kernel.org
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Alan Swanson <swanson@ukfsn.org>
Tested-by: Arteom <arutemus@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Preparing to move more repeated code into the mt core, add a flags
argument to the input_mt_slots_init() function.
Reviewed-and-tested-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Tested-by: Ping Cheng <pingc@wacom.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
The touchpad on the Acer Aspire One D250 will report out of range values
in the extreme lower portion of the touchpad. These appear as abrupt
changes in the values reported by the hardware from very low values to
very high values, which can cause unexpected vertical jumps in the
position of the mouse pointer.
What seems to be happening is that the value is wrapping to a two's
compliment negative value of higher resolution than the 13-bit value
reported by the hardware, with the high-order bits being truncated. This
patch adds handling for these values by converting them to the
appropriate negative values.
The only tricky part about this is deciding when to treat a number as
negative. It stands to reason that if out of range values can be
reported on the low end then it could also happen on the high end, so
not all out of range values should be treated as negative. The approach
taken here is to split the difference between the maximum legitimate
value for the axis and the maximum possible value that the hardware can
report, treating values greater than this number as negative and all
other values as positive. This can be tweaked later if hardware is found
that operates outside of these parameters.
BugLink: http://bugs.launchpad.net/bugs/1001251
Cc: stable@vger.kernel.org
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Read the Firmware ID and Board Number from a synaptics device at init
and display them in the system log.
Device behavior is very board and firmware dependent.
It may prove useful for users to include this information when providing
bug reports or other feedback.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Move synaptics_invert_y() inside CONFIG_MOUSE_PS2_SYNAPTICS to get rid of
a compile warning when we don't select synaptics support.
drivers/input/mouse/synaptics.c:53:12: warning: ‘synaptics_invert_y’ defined but not used [-Wunused-function]
Signed-off-by: JJ Ding <dgdunix@gmail.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
commit 7968a5dd49
Input: synaptics - add support for Relative mode
Accidentally broke support for advanced gestures (multitouch)
on some trackpads such as the one in my ThinkPad X220 by
incorretly changing the condition for enabling them. This
restores it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: stable@kernel.org [3.3]
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Synaptics touchpads on several Dell laptops, particularly Vostro V13
systems, may not respond properly to PS/2 commands and queries immediately
after resuming from suspend to RAM. This leads to unresponsive touchpad
after suspend/resume cycle.
Adding a 1-second delay after resetting the device allows touchpad to
finish initializing (calibrating?) and start reacting properly.
Reported-by: Daniel Manrique <daniel.manrique@canonical.com>
Tested-by: Daniel Manrique <daniel.manrique@canonical.com>
Cc: stable@kernel.org
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
We have determined that the jumpiness previously seen when using
the synaptics kernel mouse driver on OLPC XO was due to not using
the synaptics X11 userspace driver - the xf86-input-evdev driver was
interpreting 'finger near pad' signals as movements. Newer versions
of xf86-input-evdev fix this issue.
Additionally, the synaptics kernel driver is now usable on this
platform, but only when run in relative mode.
Update the comment and refine the check to allow the synaptics driver
to run on OLPC XO in relative mode.
We will continue investigating the EC issue as time becomes available.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Currently, the synaptics driver puts the device into Absolute mode.
As explained in the synaptics documentation section 3.2, in this mode,
the device sends a continuous stream of packets at the maximum rate
to the host when the user's fingers are near or on the pad or
pressing buttons, and continues streaming for 1 second afterwards.
These packets are even sent when there is no new information to report,
even when they are duplicates of the previous packet.
For embedded systems this is a bit much - it results in a huge
and uninterrupted stream of interrupts at high rate.
This patch adds support for Relative mode, which can be selected as
a new psmouse protocol. In this mode, the device does not send duplicate
packets and acts like a standard PS/2 mouse. However, synaptics-specific
functionality is still available, such as the ability to set the packet
rate, and rather than disabling gestures and taps at the hardware level
unconditionally, a 'synaptics_disable_gesture' sysfs attribute has
been added to allow control of this functionality.
This solves a long standing OLPC issue: synaptics hardware enables
tap to click by default (even in the default relative mode), but we
have found this to be inappropriate for young children and first
time computer users. Enabling the synaptics driver disables tap-to-click,
but we have previously been unable to use this because it also enables
Absolute mode, which is too "spammy" for our desires and actually
overloads our EC with its continuous stream of packets. Now we can enable
the synaptics driver, disabling tap to click while retaining the less
noisy Relative mode.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This will ensure our reporting is consistent with the rest of the system
and we do not refer to obsolete source file names.
Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Reviewed-by: JJ Ding <dgdunix@gmail.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Synaptics image sensor touchpads track up to 5 fingers, but only report 2.
They use a special "TYPE=2" (AGM-CONTACT) packet type that reports
the number of tracked fingers and which finger is reported in the SGM
and AGM packets.
With this new packet type, it is possible to tell userspace when 4 or 5
fingers are touching.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Synaptics image sensor touchpads track 5 fingers, but only report 2.
This patch attempts to deal with some idiosyncrasies of these touchpads:
* When there are 3 or more fingers, only two are reported.
* The touchpad tracks the 5 fingers in slot[0] through slot[4].
* It always reports the lowest and highest valid slots in SGM and AGM
packets, respectively.
* The number of fingers is only reported in the SGM packet. However,
the number of fingers can change either before or after an AGM
packet.
* Thus, if an SGM reports a different number of fingers than the last
SGM, it is impossible to tell whether the intervening AGM corresponds
to the old number of fingers or the new number of fingers.
* For example, when going from 2->3 fingers, it is not possible to tell
whether tell AGM contains slot[1] (old 2nd finger) or slot[2] (new
3rd finger).
* When fingers are added one at at time, from 1->2->3, it is possible to
track which slots are contained in the SGM and AGM packets:
1 finger: SGM = slot[0], no AGM
2 fingers: SGM = slot[0], AGM = slot[1]
3 fingers: SGM = slot[0], AGM = slot[2]
* It is also possible to track which slot is contained in the SGM when 1
of 2 fingers is removed. This is because the touchpad sends a special
(0,0,0) AGM packet whenever all fingers are removed except slot[0]:
Last AGM == (0,0,0): SGM contains slot[1]
Else: SGM contains slot[0]
* However, once there are 3 fingers, if exactly 1 finger is removed, it
is impossible to tell which 2 slots are contained in SGM and AGM.
The (SGM,AGM) could be (0,1), (0,2), or (1,2). There is no way to know.
* Similarly, if two fingers are simultaneously removed (3->1), then it
is only possible to know if SGM still contains slot[0].
* Since it is not possible to reliably track which slot is being
reported, we invalidate the tracking_id every time the number of
fingers changes until this ambiguity is resolved when:
a) All fingers are removed.
b) 4 or 5 fingers are touched, generates an AGM-CONTACT packet.
c) All fingers are removed except slot[0]. In this special case, the
ambiguity is resolved since by the (0,0,0) AGM packet.
Behavior of the driver:
When 2 or more fingers are present on the touchpad, the kernel reports
up to two MT-B slots containing the position data for two of the fingers
reported by the touchpad. If the identity of a finger cannot be tracked
when the number-of-fingers changes, the corresponding MT-B slot will be
invalidated (track_id set to -1), and a new track_id will be assigned in
a subsequent input event report.
The driver always reports the total number of fingers using one of the
EV_KEY/BTN_TOOL_*TAP events. This could differ from the number of valid
MT-B slots for two reasons:
a) There are more than 2 fingers on the pad.
b) During ambiguous number-of-fingers transitions, the correct track_id
for one or both of the slots cannot be determined, so the slots are
invalidated.
Thus, this is a hybrid singletouch/MT-B scheme. Userspace can detect
this behavior by noting that the driver supports more EV_KEY/BTN_TOOL_*TAP
events than its maximum EV_ABS/ABS_MT_SLOT.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
A Synaptics image sensor tracks 5 fingers, but can only report 2.
The algorithm for choosing which 2 fingers to report and in which packet:
Touchpad maintains 5 slots, numbered 0 to 4
Initially all slots are empty
As new fingers are detected, assign them to the lowest available slots
The touchpad always reports:
SGM: lowest numbered non-empty slot
AGM: highest numbered non-empty slot, if there is one
In addition, these touchpads have a special AGM packet type which reports
the number of fingers currently being tracked, and which finger is in
each of the two slots. Unfortunately, these "TYPE=2" packets are only used
when more than 3 fingers are being tracked. When less than 4 fingers
are present, the 'w' value must be used to track how many fingers are
present, and knowing which fingers are being reported is much more
difficult, if not impossible.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Synaptics makes (at least) two kinds of touchpad sensors:
* Older pads use a profile sensor that could only infer the location
of individual fingers based on the projection of their profiles
onto row and column sensors.
* Newer pads use an image sensor that can track true finger position
using a two-dimensional sensor grid.
Both sensor types support an "Advanced Gesture Mode":
When multiple fingers are detected, the touchpad sends alternating
"Advanced Gesture Mode" (AGM) and "Simple Gesture Mode" (SGM)
packets.
The AGM packets have w=2, and contain reduced resolution finger data
The SGM packets have w={0,1} and contain full resolution finger data
Profile sensors try to report the "upper" (larger y value) finger in
the SGM packet, and the lower (smaller y value) in the AGM packet.
However, due to the nature of the profile sensor, they easily get
confused when fingers cross, and can start reporting the x-coordinate
of one with the y-coordinate of the other. Thus, for profile
sensors, "semi-mt" was created, which reports a "bounding box"
created by pairing min and max coordinates of the two pairs of
reported fingers.
Image sensors can report the actual coordinates of two of the fingers
present. This patch detects if the touchpad is an image sensor and
reports finger data using the MT-B protocol.
NOTE: This patch only adds partial support for 2-finger gestures.
The proper interpretation of the slot contents when more than
two fingers are present is left to later patches. Also,
handling of 'number of fingers' transitions is incomplete.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
When a Synaptics touchpad is in "AGM" mode, and multiple fingers are
detected, the touchpad sends alternating "Advanced Gesture Mode" (AGM) and
"Simple Gesture Mode" (SGM) packets.
The AGM packets have w=2, and contain reduced resolution finger data.
The SGM packets have w={0,1} and contain full resolution finger data.
Refactor the parsing of agm packets to its own function, and rename the
synaptics_data.mt field to .agm to indicate that it contains the contents of
the last agm packet.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Synaptics touchpads report increasing y from bottom to top.
This is inverted from normal userspace "top of screen is 0" coordinates.
Thus, the kernel driver reports inverted y coordinates to userspace.
This patch refactors this inversion.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Newer Synaptics firmware allows to query minimum coordinates reported by
the device, let's use this data.
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
AGM packets contain valid button bits, too.
This patch refactors packet processing to parse button bits in AGM packets.
However, they aren't actually used or reported.
The point is to more completely process AGM packets,
and prepare for future patches that may actually use AGM packet button bits.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Synaptics touchpads indicate via a capability bit when they perform reduced
filtering on position data. In such a case, use a non-zero fuzz value.
Fuzz = 8 was chosen empirically by observing the raw position data
reported by a clickpad indicating it had reduced filtering.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Set resolution for MT_POSITION_X and MT_POSITION_Y to match ABS_X and
ABS_Y, respectively.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
'struct dmi_system_id' arrays must always have a terminator to keep
dmi_check_system() from looking at data (and possibly crashing) it
isn't supposed to look at.
The issue went unnoticed until ef8313bb1a,
but was introduced about a year earlier with
7705d548cb (which also similarly changed
lifebook.c, but the problem there got eliminated shortly afterwards).
The first hunk therefore is a stable candidate back to 2.6.33, while
the full change is needed only on 2.6.38.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: stable@kernel.org
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
On some machines, like Dell Studio XPS 16 (1640), touchpad fails to
respond to the standard query after first reset but may start
responding later, so let's repeat reset sequence several (3) times.
Signed-off-by: Alexandre Peixoto Ferreira <alexandref75@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
synaptics_set_advanced_gesture_mode() affect capabilities bits we should
perform comparison after calling this function, otherwise they will never
match and we will be forced to perform full reconnect.
Signed-off-by: Alexandre Peixoto Ferreira <alexandref75@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
OLPC has switched to a Synaptics touchpad. It turns out that it's
pretty useless in absolute mode. This patch looks for an OLPC
system (via DMI tables), and refuses to init Synaptics mode in
that scenario (falling back to relative mode).
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Minor comment fixup for typos and grammar. Noticed while adding a
separate workaround.
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
In multitouch mode, at least one device (fw: 7.4 id: 0x1c0b1) sometimes
sends a final main packet with x == 1. Since the normal values are above
1472, this is clearly bogus. At the same time, a two-finger touch is
signaled, even though only one finger was on the pad to begin with. This
patch ignores the packet altogether, removing the problem.
Acked-by: Chris Bagwell <chris@cnpbagwell.com>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
The Synaptics 2.7 series of touchpads support a mode for reporting two
sets of X/Y/Pressure data (advanced gesture mode). By default, these
devices report only single finger data, depriving userspace of the
nowadays ubiquitous two-finger scroll gesture.
Enabling advanced gesture mode also enables the multi-finger report,
although the device does not claim that capability. Up to three
fingers can be reported this way.
While two or three fingers are touching, the normal packet is
prepended by a reduced finger packet of lower resolution. From the two
packets (which do not represent the actual fingers), the bounding
rectangle of the individual contacts can be extracted. This
information is sufficient to perform scaling gestures and a limited
form of rotation gesture. The behavior has been coined semi-mt
capability, and is signaled to userspace via the INPUT_PROP_SEMI_MT
device property.
Work to decode the advanced gesture packet: Takashi Iwai.
Cleanup and testing of the original patch: Chase Douglas.
Minor cleanup and testing: Chris Bagwell.
Finalization and semi-mt support: Henrik Rydberg.
Reported-by: Tobyn Bertram
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
With the new input property interface, it is possible to report the
special quirks of a device using ioctl/sysfs. This patch sets up the
device as a pointer, and reports the clickpad functionality via the
INPUT_PROP_BUTTONPAD property.
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Change all call sites in drivers/input to not access the ABS axis
information directly anymore. Make them use the access helpers instead.
Also use input_set_abs_params() when possible.
Did some code refactoring as I was on it.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Older firmwares fixed the middle byte of the Synaptics capabilities
query to 0x47, but starting with firmware 7.5 the middle byte
represents submodel ID, sometimes also called "dash number".
Reported-and-tested-by: Miroslav Šulc <fordfrog@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Reporting this will allow GUI config apps to correctly scale
width sensitive config values (such as palm detect) to correct
range. Current user apps are detecting kernels min/max=0/0 and
making an assumption that it means 0/16 or 0/15.
Synaptics touchpad interface guides show 4/15 are correct values
but driver forces to 0 when no fingers on touchpad.
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Synaptics devices report fixed value of 5 for finger/palm widths
on devices that do not support capability and driver further
hardcodes to 5. Stop reporting this fixed value when its not
supported since its not useful.
This will aid applications so they can better auto-enable support
for multi-touch emulation and palm detection logic using finger
width only for devices that support width detection.
I can find no applications that currently require existence on
ABS_TOOL_WIDTH. Since only synaptics and bcm input devices
currently support this tool, it seems they must handle it
gracefully.
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The commit 83ba9ea8a0 ommitted the return
line for the old synaptics model accidentally. This resulted in a wrong
check, namely, the dimensions are checked for the old devices that don't
support the query properly.
This patch adds the return line back.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: joydev - allow binding to button-only devices
Input: elantech - ignore high bits in the position coordinates
Input: elantech - allow forcing Elantech protocol
Input: elantech - fix firmware version check
Input: ati_remote - add some missing devices from lirc_atiusb
Input: eeti_ts - cancel pending work when going to suspend
Input: Add support of Synaptics Clickpad device
Revert "Input: ALPS - add signature for HP Pavilion dm3 laptops"
Input: psmouse - ignore parity error for basic protocols
The new type of touchpads can be detected via a new query command
0x0c. The clickpad flags are in cap[0]:4 and cap[1]:0 bits.
When the device is detected, the driver now reports only the left
button as the supported buttons so that X11 driver can detect that
the device is Clickpad. A Clickpad device gives the button events
only as the middle button. The kernel driver morphs to the left
button. The real handling of Clickpad is done rather in X driver
side.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
For configurations where Synaptics hardware is present but the Synaptics
extensions support is not compiled in, the mouse is reprobed and a new
device is allocated on every suspend/resume.
During probe, psmouse_switch_protocol() calls psmouse_extensions() with
set_properties=1. This calls the dummy synaptics_init() which returns an
error code, instructing us not to use the synaptics extensions.
During resume, psmouse_reconnect() calls psmouse_extensions() with
set_properties=0, in which case call to synaptics_init() is bypassed and
PSMOUSE_SYNAPTICS is returned. Since the result is different from previous
attempt psmouse_reconnect() fails and full re-probe happens.
Fix this by tweaking the set_properties=0 codepath in psmouse_extensions()
to be more careful about offering PSMOUSE_SYNAPTICS extensions.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The driver does not reference identification strings in DMI tables and
since these strings are no longer required by DMI core we can safely
remove them and save some memory.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
DMI tables use considerable amount of memory. Mark them as __initconst
so they will be discarded once module is loaded.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Apparently some of Toshiba Protege M300 identify themselves as
"Portable PC" in DMI so we need to add that to the DMI table as
well. We need DMI data so we can automatically lower Synaptics
reporting rate from 80 to 40 pps to avoid over-taxing their
keyboard controllers.
Tested-by: Rod Davison <roddavison@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Benjamin Tissoires