`gaze17` touch pad vanishes

[thomas-zimmerman]

• Model: gaze17
• BIOS version: 2022-07-27_00cebe9
• EC version: 2022-07-27_00cebe9

The touch pad will sometime randomly stop responding. The EC toggle Fn+F1 does not bring function back. Power cycling the system or reloading the i2c_hid driver will bring functionality back.

sudo modprobe -r i2c_hid_acpi i2c_hid
sudo modprobe i2c_hid
sudo modprobe i2c_hid_acpi

Steps to reproduce

Customer reports all look pretty random on when it happens. Does not happen on all devices

Expected behavior

Touch pad should not stop responding unless turned off by EC

Additional info

We've seen this on lemp11 and oryp9 systems as well.

[XV-02]

So, I've run into this issue or a closely related one on both currently released and prospective firmware. The behaviour looks slightly different for what I'm seeing described here.

The trackpad stopped reacting to user input, but seemed to be expressing spurious inputs. When I toggled Fn+F1 those spurious inputs ceased continued, but were suppressed as expected.

Rebooting did not clear the issue. However, a complete shutdown and boot did.

I find the spurious inputs in particular curious, as something is communicating junk data to the OS, but it's not long, consistent junk data, as the cursor hardly moves, and click inputs (presumably from small trackpad inputs triggering tap-to-click) are among the false positives with tap-to-click enabled. This suggests lots of short spurious inputs, like tapping a trackpad would generate.

The fact that rebooting fails to resolve this in the short term - which often does not reinitialize various pieces of hardware - but a shutdown and boot does makes me think it's something in the hardware driver getting screwy. The fact that resetting the I2C driver either by killing the system or by actively bouncing the driver resolves the problem in the short term also seems poignant, though my lack of driver expertise makes that pure speculation.

[XV-02]

Extending my research found this shout over at the Manjaro forums.

Looks like this is an issue with this touchpad on these Clevo devices. Of note was that the user was experiencing this with the Insyde firmware as well.

The Touchpad MODALIAS value when running udevadm info -e appears to report as FTCS1000:PNP0C50 twice and once as FTCS1000:00 2808:0102

Doing some searching specifically around those values, I found this Manjaro forum post. When I look at some of the same diagnostic output they tried, I had similar results.

Specifically, capturing the output of libinput debug-events had what I can only call an avalanche of spurious inputs despite the touchpad being disabled. libinput.log

Looking generally, it seems to me that this is a device driver related issue, and not a firmware issue. The fact that this behaviour is present on both our firmware and Insyde's [At least according to other reports of similar issues] is the strongest suggestion of that. Beyond that, it seemed not to exclusively effect the same models we ship, but models with this touchpad device based on my snooping.

It isn't much, but it's a little more defined now, I think.

I would note that shutting down the unit seems to resolve the issue, so for the time being, I'm keeping the afflicted lab unit running pending any other suggested diagnostics.

[XV-02]

As an aside: While investigating this, I noticed that, even with the touchpad toggled "off" with Fn+F1, that Gnome Terminal seemed to react to the spurious mouse inputs in some manner, resulting in the text size changing wildly at times.

[crawfxrd]

Possibly addressed by https://github.com/pop-os/system76-driver/pull/265 until fixed in firmware.

[dni]

digging into the list issues, i found at that disabled PS2 devices inside BIOS fixed the described issue for me permanently.

[crawfxrd]

May be resolved by https://github.com/system76/ec/pull/464.