Bug 196929

The only commit to ALPS driver between 4.12.9 and 4.12.10 is 4a646580f793d19717f7e034c8d473b509c27d49. Does reverting it restore the touchpad behavior?

(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

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

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?

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....

(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".

(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.

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.

 (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.

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.