|Broken detection of touchpad on Dell Latitude 7370
|Benjamin Hennion (benjamin.hennion)
|benjamin.hennion, bjo, c.h.l, dmitry.torokhov, linux-kernel, masaki.ota, pali
|Revert part of the offending commit
Description Benjamin Hennion 2017-09-13 08:19:34 UTC
Up until 4.12.9, touchpad on Dell Latitude 7370 was detected as input: AlpsPS/2 ALPS DualPoint Stick as devices/platform/i8042/serio1/input/input13 mousedev: PS/2 mouse device common for all mice input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input10 and working (one, two, three fingers tapping, scrolling and all). Since 4.12.10 (and up to 4.12.12), it is detected as sept. 10 13:15:38 flower kernel: input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input9 sept. 10 13:15:38 flower kernel: mousedev: PS/2 mouse device common for all mice and not working properly (one and two fingers still ok. Three fingers are never detected). (Tested on Archlinux, with X server 1.19, same result with either Synaptics and libinput driver).
Comment 1 Dmitry Torokhov 2017-09-13 17:00:04 UTC
The only commit to ALPS driver between 4.12.9 and 4.12.10 is 4a646580f793d19717f7e034c8d473b509c27d49. Does reverting it restore the touchpad behavior?
Comment 2 Benjamin Hennion 2017-09-13 18:55:41 UTC
(In reply to Dmitry Torokhov from comment #1) > The only commit to ALPS driver between 4.12.9 and 4.12.10 is > 4a646580f793d19717f7e034c8d473b509c27d49. Does reverting it restore the > touchpad behavior? Okay. I rebuilt 4.12.12 from scratch, just to level things. The behaviour is the same as with my distro's stock kernel. Reverting that commit 4a646580f793d19717f7e034c8d473b509c27d49 on 4.12.12 works fine. All my three fingers are suitably taken into account and all. journatctl gets me input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input9
Comment 3 Christoph Loehr 2018-01-25 06:02:58 UTC
I have exactly the same problem with my Lenovo L570 laptop. Reverting commit 4a646580f793d19717f7e034c8d473b509c27d49 restores the functionality of the touchpad and as well the trackstick. The commit 4d94e776bd29670f01befa27e12df784fa05fa2e that came now with kernel version 4.14.15 didn't solve the problem. But if I revert the changes made by both commits everything works with kernel 4.14.15. Please let me know if I could provide any help to solve the issue and as well if I should open a new bug. Christoph
Comment 4 Dmitry Torokhov 2018-01-26 01:22:57 UTC
Created attachment 273861 [details]
Revert part of the offending commit
Can you please try this patch and let me know if this restores the correct behavior?
Comment 5 Christoph Loehr 2018-01-26 13:23:30 UTC
On my Lenovo L570 the patch works perfectly. I've tested it with kernel version 4.14.14. and 4.14.15 under two distros (Arch & Gentoo). The trackstick and the touchpad are both recognized correctly and are fully working. Hope, it makes its way into the kernel soon....
Comment 6 Pali Rohár 2018-01-26 13:41:22 UTC
(In reply to Christoph Loehr from comment #3) > I have exactly the same problem with my Lenovo L570 laptop. That is a different problem. (In reply to Dmitry Torokhov from comment #4) > Created attachment 273861 [details] > Revert part of the offending commit That is a wrong patch. Corrent one for Thinkpad L570 was sent by Masaki Ota to mailing list in November 2017, but seems you have not processed it yet. Search for it: "[PATCH] Support TrackStick of Thinkpad L570".
Comment 7 Christoph Loehr 2018-01-26 22:57:34 UTC
(In reply to Pali Rohár from comment #6) I don't know and can't asses whether it's a different problem or not, as I'm rather a user than a developer or programmer. The symptoms of the problem with my L570 are however exactly the same as described in the bug report. Regarding the patch provided by Masaki Ota: I had already tested it, when he sent it last year and it didn't solve the problem. I just tried to test it again but I even couldn't compile the kernel with it, neither older versions (4.13.x) nor actual ones (4.14.x). I am, for my part, happy with the patch from Dmitry Torokhov, as it brings a simple solution for me. (Until now I helped myself by reverting commit 4a646580f793d19717f7e034c8d473b509c27d49 and subsequent commits with changes to alps.c and alps.h. Before this commit, i.e kernel version 4.12.9 the touchpad/trackstick worked without any problems.) Nevertheless, if I could provide any help, by testing other patches or providing useful information, please let me know.
Comment 8 Pali Rohár 2018-01-26 23:11:01 UTC
On linux-input mailing list was already proposed patch with exactly same context as Dmitry uploaded to this bugzilla ticket and Masaki Ota rejected it as it was incorrect. And because you wrote about similar symptoms as in this ticket, but for Thinkpad L570, I just realized that must be a problem about which was discussion on linux-input. Masaki Ota sent patch which was confirmed by 3 owners of Thinkpad L570 machine that it fixes it. So either you hit another (new) problem which other owners of Thinkpad L570 do not have or it is a problem with applying that patch (probably it needs to be reworked/rebased on current HEAD of git repository). I would suggest as a first step to process Masaki Ota patch and then try to debug what is happening with your setup.
Comment 9 Christoph Loehr 2018-01-27 08:07:10 UTC
(In reply to Pali Rohár from comment #8) > I would suggest as a first step to process Masaki Ota patch and then try to > debug what is happening with your setup. In the meantime I have made further tests with the Masaki Ota patch and could finally apply it manually in a way that the kernel compiles. It works! As mentioned I had tested it already some time ago without success. I assume that I did anything wrong by then. The other possibility is a firmware-update that I have made some weeks ago (under the other OS). Sorry, if I should have caused any confusion. Nevertheless, I can confirm that the Masaki Ota patch works (even with the actual kernel version 4.14.15.
Comment 10 Benjamin Hennion 2020-10-04 09:04:39 UTC
Sorry I missed out on a few things happening around this bug I reported then. I can confirm this has been working properly with my distrib's stock kernel for some time now. Closing the bug.