FocalTech I2C Touchpad drops out on soft reboot from Linux (Clevo NLx0MU)

tahaspc

tahaspc

Hello again,

First of all, thank you! Installing xf86-input-libinput-evdev solved the touchpad issue completely. The touchpad now works correctly under Xfce.

However, while testing, I noticed another strange behavior that I can reproduce consistently.

If I perform a cold boot (the laptop is completely powered off, then I press the power button), the touchpad works perfectly every time.

However, if I boot Linux Mint first, then choose Restart, let GRUB appear, and boot into FreeBSD without removing power, the touchpad becomes completely unresponsive. No movement or click events are detected.

If I then shut the laptop down completely and power it back on, the touchpad immediately starts working again.

So the behavior is:

  • Cold boot → FreeBSD → Touchpad works ✔
  • Linux Mint → Reboot → GRUB → FreeBSD → Touchpad does not work ✘
  • Shutdown → Power on → FreeBSD → Touchpad works again ✔

This makes me wonder whether the touchpad or the Intel I²C controller is being left in a state by Linux that FreeBSD does not fully reinitialize during boot.

Has anyone seen similar behavior with I²C HID touchpads? Is there a way to force FreeBSD to completely reset or reinitialize the FTCS1000 device (or the Intel Tiger Lake I²C controller) during startup?

My laptop is still the same Clevo NLx0MU with the FocalTech FTCS1000 (2808:0101) touchpad.

Any ideas or suggestions would be greatly appreciated.
 
In the world of device drivers, there is often a huge difference between cold boot (power cycle) and reset/warm boot. Cold boot means registers are in a specific known state, warm boot they are typically in "last known state". The software (device driver) typically makes assumptions about the state of the registers (often can't reliably determine cold/warm) so may not initialize everything the same way between the two.

That's why what covacat suggests is a reasonable idea/datapoint.
 
covacat said:
you may try to reset the controller with i2c(8)
Click to expand...
Thanks covacat and mer! Here are the exact test results from the i2c(8) and driver configuration attempts:

1. i2c(8) Reset Test
  • Identified that my Intel Tiger Lake controllers are mapped to iicbus14 (ig4iic0), iicbus15 (ig4iic1), and iicbus16 (ig4iic2).
  • Ran sudo i2c -r -f /dev/iic14 (as well as iic15/iic16) followed by reloading iichid. The bus accepted the reset command, but the touchpad remained unresponsive after a warm reboot from Linux.

2. Driver & Bus State
  • dmesg shows that iichid0 attaches fine during a warm boot, but falls back to sampling mode:
    Code: 
    ig4iic0: <Intel Tiger Lake-LP I2C Controller-4> at device 21.0 on pci0
iicbus14: <Philips I2C bus (ACPI-hinted)> on ig4iic0
iichid0: <FTCS1000:00 2808:0101 I2C HID device> at addr 0x38 on iicbus14
iichid0: Using sampling mode
hidbus1: <HID bus> on iichid0
iic14: <I2C generic I/O> on iicbus14
  • Adding hw.iichid.sampling_core="0" and hw.ig4.ign_acpi="1" to /boot/loader.conf did not restore input functionality.

It seems iichid0 detects the FocalTech device on iicbus14, but the GPIO/PCI interrupt line left behind by Linux prevents input reports from being processed by FreeBSD.

Is there a way to force a PCI-level reset on ig4iic0 (device 21.0 on pci0) during boot, or properly re-initialize the G
PIO interrupt routing?
 
try setting iichid debug to someting > 0 and see if kernel messages can tell you something in the working and not working case
looks like you need to build the kernel with IICID_DEBUG for it to be available
 
You must log in or register to reply here.
Back
Top