Bug 204771 - Elan Touchpad stopped working on HP Stream x360 11-aa002ng
Summary: Elan Touchpad stopped working on HP Stream x360 11-aa002ng
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: drivers_input-devices
Depends on:
Reported: 2019-09-04 19:55 UTC by Jan Drögehoff
Modified: 2020-03-22 12:20 UTC (History)
3 users (show)

See Also:
Kernel Version: 5.2.11-200
Tree: Mainline
Regression: No

0001-Input-elan-also-provide-the-product-ID-from-PS-2-to-.patch (3.14 KB, patch)
2019-09-10 13:25 UTC, Benjamin Tissoires
Details | Diff
dmesg of the 5.13.0-rc8 kernel with the given patch (58.42 KB, text/plain)
2019-09-10 21:26 UTC, Jan Drögehoff
v2-0001-Input-elan-also-provide-the-product-ID-from-PS-2-.patch (3.41 KB, patch)
2019-09-11 11:11 UTC, Benjamin Tissoires
Details | Diff
dmesg with the given patch (58.10 KB, text/plain)
2019-09-11 12:34 UTC, Jan Drögehoff
0001-WIP-Input-elan_i2c-disable-all-SMBus-calls-in-probe.patch (1.52 KB, patch)
2019-09-12 09:35 UTC, Benjamin Tissoires
Details | Diff
dmesg (58.66 KB, text/plain)
2019-09-12 12:57 UTC, Jan Drögehoff
firmware_id (21 bytes, text/plain)
2019-09-21 09:27 UTC, Jan Drögehoff

Comment 1 Dmitry Torokhov 2019-09-04 21:28:31 UTC
Hmm, we are trying to set up SMBus access, but communication is failing:

elan_i2c 11-0015: failed to get product ID: -71
Comment 2 Benjamin Tissoires 2019-09-06 08:37:42 UTC
Unfortunately, a patch has been backported from v5.3 (60956b018bfe23b879405a7d88103d0a8f06a5e3) that depends on an other series (https://patchwork.kernel.org/project/linux-input/list/?series=122327&state=%2A&archive=both) which means that we can not really trust the information from a v5.2.11 kernel.

I am about to send a revert for the commit above, which should restore the v5.2.7 behavior.

Meanwhile, can you test a v5.3-rc kernel to see if we have the same error?
I must confess I believe we will, and we likely need to also carry this information from the PS/2 node.
Comment 3 Jan Drögehoff 2019-09-06 12:39:53 UTC
The touchpad is still not functional on kernel 5.3-rc7 and none of the related content in dmesg changed
Comment 4 Jan Drögehoff 2019-09-08 14:16:43 UTC
The issue is completly gone on 5.2.13
Comment 5 Benjamin Tissoires 2019-09-10 13:25:44 UTC
Created attachment 284907 [details]

Thanks for confirming we "fixed" your touchpad on stable. However, we just reverted to the previous PS/2 mode, and 5.3 will switch your touchpad once again over SMBus.

Can you try the attached patch? It should allow us to go one more step further, and retrieve the missing SMBus information from PS/2.
Comment 6 Jan Drögehoff 2019-09-10 21:26:24 UTC
Created attachment 284915 [details]
dmesg of the 5.13.0-rc8 kernel with the given patch

I applied the patch and uploaded the dmesg contents
Comment 7 Jan Drögehoff 2019-09-11 11:01:25 UTC
reopening because I labeled it as resolved too preemptively
Comment 8 Benjamin Tissoires 2019-09-11 11:11:26 UTC
Created attachment 284921 [details]

Right, of course the second command it tries to send is the exact same with a different name...

Can you try the new patch now? This should entirely remove any calls to function 0xA3, which is problematic here.
Comment 9 Jan Drögehoff 2019-09-11 12:34:04 UTC
Created attachment 284923 [details]
dmesg with the given patch
Comment 10 Benjamin Tissoires 2019-09-12 09:35:52 UTC
Created attachment 284935 [details]

Well, this is not good. I would have expected the retrieval of the FW parameters to also work.

Can you try the new patch on top of the previous one?
This is a non upstream-able patch that would allow us to bypass the retrieval of the FW information without compromising the touchpad.

If this patch doesn't work, then that means we would have to force PS/2 on your model (not a big deal for you, but more worrying for me).
Comment 11 Jan Drögehoff 2019-09-12 12:57:51 UTC
Created attachment 284939 [details]
Comment 12 Jan Drögehoff 2019-09-19 04:13:00 UTC
any news on the matter?
Comment 13 Benjamin Tissoires 2019-09-20 16:12:26 UTC
Apologies for the delay. Unfortunately I haven't had much time to dedicate to this problem.

The logs are weird: now we are failing earlier than previously, or we are calling it a second time and failing where we passed previously.

I guess this is the typical situation where I need to have the machine in front of me and it would be simpler to blacklist your system.

I'll try to come up with a patch soon.
Comment 14 Benjamin Tissoires 2019-09-20 16:16:41 UTC
- can you give me the content of `cat /sys/bus/serio/devices/serio1/firmware_id`
- you can force the touchpad on PS/2 by temporary booting with `psmouse.elantech_smbus=0` until I provide you the correct patch
Comment 15 Jan Drögehoff 2019-09-21 09:27:38 UTC
Created attachment 285077 [details]
Comment 16 Wolfram Sang 2020-03-22 12:20:59 UTC
bug 205301 is likely a duplicate

Note You need to log in before you can comment on or make changes to this bug.