Open thomas-zimmerman opened 1 year ago
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.
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.
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.
Possibly addressed by https://github.com/pop-os/system76-driver/pull/265 until fixed in firmware.
digging into the list issues, i found at that disabled PS2 devices inside BIOS fixed the described issue for me permanently.
May be resolved by https://github.com/system76/ec/pull/464.
gaze17
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.
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
andoryp9
systems as well.