Bug 204771
| Summary: | Elan Touchpad stopped working on HP Stream x360 11-aa002ng | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Jan Drögehoff (sentrycraft123) |
| Component: | Input Devices | Assignee: | drivers_input-devices |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | benjamin.tissoires, dmitry.torokhov, wsa |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 5.2.11-200 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
0001-Input-elan-also-provide-the-product-ID-from-PS-2-to-.patch
dmesg of the 5.13.0-rc8 kernel with the given patch v2-0001-Input-elan-also-provide-the-product-ID-from-PS-2-.patch dmesg with the given patch 0001-WIP-Input-elan_i2c-disable-all-SMBus-calls-in-probe.patch dmesg firmware_id |
||
|
Description
Jan Drögehoff
2019-09-04 19:55:24 UTC
Hmm, we are trying to set up SMBus access, but communication is failing: elan_i2c 11-0015: failed to get product ID: -71 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. The touchpad is still not functional on kernel 5.3-rc7 and none of the related content in dmesg changed The issue is completly gone on 5.2.13 Created attachment 284907 [details]
0001-Input-elan-also-provide-the-product-ID-from-PS-2-to-.patch
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.
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
reopening because I labeled it as resolved too preemptively Created attachment 284921 [details]
v2-0001-Input-elan-also-provide-the-product-ID-from-PS-2-.patch
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.
Created attachment 284923 [details]
dmesg with the given patch
Created attachment 284935 [details]
0001-WIP-Input-elan_i2c-disable-all-SMBus-calls-in-probe.patch
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).
Created attachment 284939 [details]
dmesg
any news on the matter? 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. Actually: - 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 Created attachment 285077 [details]
firmware_id
bug 205301 is likely a duplicate |