commit fb4f8f568a9def02240ef9bf7aabd246dc63a081 upstream. The touchpad on the GIGABYTE U2442 not only stops communicating when we try to set bit 3 (enable real hardware resolution) of reg_10, but on some BIOS versions also when we set bit 1 (enable two finger mode auto correct). I've asked the original reporter of: https://bugzilla.kernel.org/show_bug.cgi?id=61151 To check that not setting bit 1 does not lead to any adverse effects on his model / BIOS revision, and it does not, so this commit fixes the touchpad not working on these versions by simply never setting bit 1 for laptop models with the no_hw_res quirk. Reported-and-tested-by: James Lademann <jwlademann@gmail.com> Tested-by: Philipp Wolfer <ph.wolfer@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cd9e83e2754465856097f31c7ab933ce74c473f8 upstream. At least the Dell Vostro 5470 elantech *clickpad* reports right button clicks when clicked in the right bottom area: https://bugzilla.redhat.com/show_bug.cgi?id=1103528 This is different from how (elantech) clickpads normally operate, normally no matter where the user clicks on the pad the pad always reports a left button event, since there is only 1 hardware button beneath the path. It looks like Dell has put 2 buttons under the pad, one under each bottom corner, causing this. Since this however still clearly is a real clickpad hardware-wise, we still want to report it as such to userspace, so that things like finger movement in the bottom area can be properly ignored as it should be on clickpads. So deal with this weirdness by simply mapping a right click to a left click on elantech clickpads. As an added advantage this is something which we can simply do on all elantech clickpads, so no need to add special quirks for this weird model. Reported-and-tested-by: Elder Marco <eldermarco@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d49cb7aeebb974713f9f7ab2991352d3050b095b upstream. commit 421e08c41fda 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull input subsystem fixes from Dmitry Torokhov: "A couple of driver/build fixups and also redone quirk for Synaptics touchpads on Lenovo boxes (now using PNP IDs instead of DMI data to limit number of quirks)" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: synaptics - change min/max quirk table to pnp-id matching Input: synaptics - add a matches_pnp_id helper function Input: synaptics - T540p - unify with other LEN0034 models Input: synaptics - add min/max quirk for the ThinkPad W540 Input: ambakmi - request a shared interrupt for AMBA KMI devices Input: pxa27x-keypad - fix generating scancode Input: atmel-wm97xx - only build for AVR32 Input: fix ps2/serio module dependency
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>
https://bugzilla.redhat.com/show_bug.cgi?id=1096436 Cc: stable@vger.kernel.org Tested-and-reported-by: ajayr@bigfoot.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Recent ARM boards have the KMI devices share one interrupt line rather than having dedicated IRQs. Update the driver to take that into account. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The number of columns of pxa27x-keypad used by various boards is not fixed.
When building keymap with call to:
matrix_keypad_build_keymap(keymap_data, NULL,
pdata->matrix_key_rows,
pdata->matrix_key_cols,
keypad->keycodes, input_dev);
it will internally calculate needed row shift and use it to fill the
keymap. Therefore when calculating the "scancode" we should no longer use
constant row shift but also calculate it from number of columns.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>