cat ~/notes/touchpad-dead-after-suspend.md
ngidupin touchpad i2c setelah suspend tanpa reboot
[en]ngidupin touchpad i2c setelah suspend tanpa reboot
Setiap laptop gw bangun dari suspend, layar, keyboard, dan semua aplikasi balik normal. Touchpad-nya engga.
Device-nya masih keliatan di Linux, tapi ga ngirim input sama sekali. Mouse Bluetooth tetap jalan, jadi masalahnya cuma kena satu jalur device.
Reboot bikin touchpad hidup lagi. Unbind lalu rebind satu driver ternyata ngasih hasil yg sama dalam beberapa detik.
Touchpad-nya lewat jalur mana?
Langkah pertama adalah nyari bus sama driver di belakang input device ini:
grep -iE "touchpad|i2c" /proc/bus/input/devices
Output yg relevan:
N: Name="GXTP5100:00 27C6:01E0 Touchpad"
S: Sysfs=.../i2c_designware.0/i2c-0/i2c-GXTP5100:00/...
Ini touchpad Goodix GXTP5100 yg terhubung lewat I2C, bukan USB.
Jalur hardware-nya lewat controller i2c-designware punya Intel, sementara touchpad-nya sendiri di-handle i2c_hid_acpi.
Module yg harusnya ada memang udah ke-load:
lsmod | grep -iE "i2c_hid|hid_multitouch"
# i2c_hid_acpi ...
# i2c_hid ...
# hid_multitouch ...
Ga ada module yg hilang. Justru itu masalahnya: Linux masih nganggep device udah siap walaupun komunikasinya berhenti.
Apa yg rusak pas resume?
Suspend matiin controller I2C buat hemat daya. Pas resume, sistem harus nyalain lagi controller-nya, reset touchpad, lalu baca ulang HID descriptor.
Kalo urutan power sama reset-nya salah, driver bisa tetap bound ke device yg udah ga tukeran data. Touchpad masih muncul di sysfs dan semua module keliatan normal, tapi ga ada input event yg masuk.
Mouse Bluetooth jadi control case yg berguna. Dia lewat hardware dan driver path yg beda total, makanya tetap hidup setelah suspend yg sama.
Biasanya penyebabnya salah satu dari dua ini:
- regresi di jalur suspend dan resume
i2c-designwareataui2c-hid - firmware laptop dengan power sequencing yg ga konsisten pas resume
Gw lagi pakai kernel 6.17, jadi regresi kernel masih masuk akal. Target awalnya bukan buktiin layer mana yg salah. Gw cuma perlu nemuin reset paling kecil yg bisa balikin device.
Reset driver touchpad doang
Device-nya ga butuh reboot penuh.
i2c_hid_acpi cuma perlu lepas lalu inisialisasi ulang.
echo -n 'i2c-GXTP5100:00' | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/unbind
echo -n 'i2c-GXTP5100:00' | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind
Identifier ini spesifik buat laptop gw. Sebelum copy command-nya, cek dulu device yg terpasang ke driver:
ls /sys/bus/i2c/drivers/i2c_hid_acpi/
Rebind maksa driver ngulang jalur inisialisasinya. Touchpad langsung responsif lagi.
Tanpa reboot…
Kalo rebind device belum cukup, jalur controller I2C mungkin butuh reset yg lebih luas. Step berikutnya adalah reload module:
sudo modprobe -r i2c_hid_acpi i2c_hid && sudo modprobe i2c_hid_acpi
Jalanin rebind setiap resume
Command manual udah buktiin recovery mechanism-nya, tapi laptop belum enak dipakai. Touchpad tetap mati setiap habis suspend.
Script di /usr/lib/systemd/system-sleep/ dijalanin systemd sebelum suspend dan setelah resume.
Tiap script dapet argumen pertama pre atau post.
Gw taro rebind di jalur post:
sudo tee /usr/lib/systemd/system-sleep/fix-touchpad.sh > /dev/null <<'EOF'
#!/bin/sh
case "$1/$2" in
post/*)
D=i2c-GXTP5100:00
echo -n "$D" > /sys/bus/i2c/drivers/i2c_hid_acpi/unbind 2>/dev/null
sleep 1
echo -n "$D" > /sys/bus/i2c/drivers/i2c_hid_acpi/bind 2>/dev/null
;;
esac
EOF
sudo chmod +x /usr/lib/systemd/system-sleep/fix-touchpad.sh
Sekarang tiap resume ngejalanin reset yg sama dengan tes manual. Bagian sistem lain ga perlu disentuh.
Workaround dengan batas yg jelas
Cara ini ga memperbaiki resume sequence di kernel atau BIOS. Dia cuma benerin state driver setelah failure-nya terjadi.
Perbedaan itu penting buat kasus sejenis. Kalo mouse eksternal aman, touchpad masih keliatan, dan driver rebind bisa balikin input, kemungkinan besar desktop session bukan layer yg rusak. Masalahnya ada lebih bawah di jalur device I2C.
Selama kernel atau firmware belum benerin jalur itu, reset ke device paling kecil yg kena udah cukup buat menghindari reboot.