Can you paste the results of cat /proc/bus/input/devices and ls -l /sys/kernel/debug/hid/* (the second command requires root permission) in live OS? And in the OS where your touchpad doesn’t work, paste the result of ls -l /sys/kernel/debug/hid/*.
Can you also upload the ACPI DSDT table somewhere and share the link with me? The ACPI DSDT can be dumped by running the following commands after installing acpica,
Somehow the I2C master device (HID: AMDI0010, managed by drivers/i2c/busses/i2c-designware-platdrv.c) couldn’t communicate with the touchpad which is an I2C client device. This I2C master device uses IRQ 6 but “cat /proc/interrupts” shows IRQ 6’s counter never increases.
I don’t understand why the touchpad work in live OS because I don’t know the difference between live OS and installed OS. Knowing what the difference is may provide a clue for debugging this touchpad.
I looked at your problem once.
The reason is that the touchpad is not recognized at all.
It could be, that it is deactivated on the hardware side.
Do you have a setting that could cause this to happen when using a normal mouse?
Yes, it has been called but without success. If you look at the code of drivers/hid/i2c/i2c-hid-core.c. i2c-hid won’t warn if it fails to read the HID Descriptor from the touchpad unless you set the module parameter debug=1. I’ve accessed @EternalEntity’s computer to debug this issue so I’m quite sure about what’s happening.
Actually I’ve inserted some pr_alert code into i2c-hid-core.c to find out which line of function call wasn’t unsuccessful. I‘ve also enable I2C tracing and turned on the dynamic debug feature of i2c-designware-platdrv.c to verify it.
Unfortunately I could only tell the I2C controller somehow fails to read HID Descriptor from the touchpad. As for the root cause, my best guess is due to a bug in the i2c-designware.