* Description My Synaptics Touchpad completly stopped working on 5.2.11 Kernel 5.2.7 on the other hand seems to be working fine * Output dmesg https://gist.githubusercontent.com/Jan200101/8f168eaa1417f86a6e3e5a961b9de753/raw/7d9199e16cbfac4bdf98d353f5d01c55d9507e9c/dmesg /proc/bus/input/devices https://gist.githubusercontent.com/Jan200101/8f168eaa1417f86a6e3e5a961b9de753/raw/7d9199e16cbfac4bdf98d353f5d01c55d9507e9c/proc%2520bus%2520input%2520devices hwinfo https://gist.githubusercontent.com/Jan200101/8f168eaa1417f86a6e3e5a961b9de753/raw/7d9199e16cbfac4bdf98d353f5d01c55d9507e9c/hwinfo lsusb https://gist.githubusercontent.com/Jan200101/8f168eaa1417f86a6e3e5a961b9de753/raw/7d9199e16cbfac4bdf98d353f5d01c55d9507e9c/lsusb libinput list-devices https://gist.githubusercontent.com/Jan200101/8f168eaa1417f86a6e3e5a961b9de753/raw/7d9199e16cbfac4bdf98d353f5d01c55d9507e9c/libinput%2520list-devices libinput list-devices on 5.2.7 https://gist.githubusercontent.com/Jan200101/8f168eaa1417f86a6e3e5a961b9de753/raw/d1acb452e060d4bea36a7c1981217aad5a32e02d/libinput%2520list-devices%2520working
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