I went through all the comments of this bug, and I don't think that the touchpad is using i2c-hid. The DSDT apparently shows a lot of i2c-hid devices, and so does the /sys dir, but that does not means that all the declared devices are used/included in the laptop. I have already seen this in an Asus laptop. The OEM just add all of the available touchpads in the market in their DSDT table, so that they do not have to edit the table when using various touchpads/touchscreens.
Anyway, the various /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C3:00/*/status files should return 0 for all of the touchpads whether or not the physical touchpad is working. If one returns 1, i2c-hid should pick it, so I doubt this is the case.
I am trying to understand why the touchpad does not initialize correctly when we poke him, but IMO, the root of the problem lies in the PS/2 code.
I went through all the comments of this bug, and I don't think that the touchpad is using i2c-hid. The DSDT apparently shows a lot of i2c-hid devices, and so does the /sys dir, but that does not means that all the declared devices are used/included in the laptop. I have already seen this in an Asus laptop. The OEM just add all of the available touchpads in the market in their DSDT table, so that they do not have to edit the table when using various touchpads/ touchscreens.
Anyway, the various /sys/devices/ LNXSYSTM: 00/LNXSYBUS: 00/PNP0A08: 00/INT33C3: 00/*/status files should return 0 for all of the touchpads whether or not the physical touchpad is working. If one returns 1, i2c-hid should pick it, so I doubt this is the case.
I am trying to understand why the touchpad does not initialize correctly when we poke him, but IMO, the root of the problem lies in the PS/2 code.