You are not logged in.
Hello Arch community,
I'm documenting a persistent touchpad issue on my AVITA AM15A2IN laptop that requires resolution. The SYNA3602 touchpad was fully functional on Arch Linux, but stopped working entirely after a system update performed in November 2025. I will resolve this issue, but wanted to share technical details for community insight.
Hardware and current setup:
Laptop: AVITA AM15A2IN
Touchpad: SYNA3602 (identified from previous dmesg logs)
BIOS: EM_IDL819_S_SUB26_V1.0.5 (07/24/2023)
Current OS: CachyOS (kernel 6.18.2-2-cachyos) - I prefer to remain on CachyOS due to its Arch compatibility and performance benefits
Environment: Wayland only (GNOME and Hyprland), no Xorg
Issue timeline:
Touchpad worked perfectly on clean Arch Linux installation
In November 2025, I performed a routine system update (`pacman -Syu`)
Immediately after the November update, the touchpad completely disappeared from system detection
Both LTS kernel and latest kernels exhibit the same failure
Complete Arch reinstall did not resolve the issue
Migration to CachyOS also fails to detect the touchpad
Both GNOME and Hyprland environments show identical behavior
Critical system logs show multiple failures:
[ 8.220253] intel-hid INTC1070:00: failed to enable HID power button
[ 8.220984] irq 27: nobody cared (try booting with the "irqpoll" option)
[ 8.221050] Disabling IRQ #27
[ 8.256627] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.LPCB.HEC.TSR1], AE_NOT_FOUND
[ 8.256637] ACPI Error: Aborting method \_SB.PC00.LPCB.H_EC.SEN1._TMP due to previous error (AE_NOT_FOUND)Device detection status:
`libinput list-devices` shows no touchpad device at all. The system detects standard input devices (keyboard, power buttons, lid switch, Bluetooth mouse) but completely fails to recognize the touchpad hardware.
What works:
The touchpad functions perfectly when booted from an MX Linux live USB environment, confirming this is not a hardware failure but a software/driver issue specific to Arch-based systems.
Troubleshooting performed:
Tested kernel parameters: `i2c_hid.acpi_quirks=1`, `module_blacklist=i2c_hid_acpi`, `acpi_osi=Linux` with `acpi_enforce_resources=lax` and `irqpoll`
Blacklisted problematic modules (`i2c_hid_acpi`, `intel_ishtp_hid`) in modprobe configuration
Verified all firmware packages are properly installed
This appears to be a regression introduced specifically in the November 2025 update that affects touchpad detection for this hardware configuration. The contrast between working MX Linux live environment and failing installed Arch/CachyOS systems suggests differences in driver loading sequence, module dependencies, or ACPI handling.
I will continue working toward a solution and will document the resolution once found. Full system logs and diagnostic outputs are available upon request.
Last edited by ng-link (Today 13:58:33)
Offline
Good report, thanks for the detailed logs.
Given that the touchpad works on MX Linux and also works after a manual
modprobe i2c_hid, this points to a likely upstream regression in I²C-HID / ACPI initialization order, rather than a firmware or hardware failure.
A few points that may help narrow this down:
The
irq 27: nobody caredmessage followed by the IRQ being disabled is significant. Once that IRQ is disabled, the touchpad can no longer generate events. This strongly suggests a regression in IRQ routing or ACPI resource handling.
The intel-hid driver has been known to interfere with I²C devices on some systems. It may be worth testing with the following kernel parameter (while leaving i2c_hid_acpi enabled):
module_blacklist=intel-hid,intel_ishtp_hidSince manually reloading the module works, another useful test is forcing early module loading via initramfs. Add the following to your mkinitcpio.conf:
MODULES=(i2c_hid i2c_hid_acpi hid_multitouch)Then rebuild the initramfs:
mkinitcpio -PFor testing purposes only, it may also be useful to try booting with one of the following kernel parameters:
pci=nomsior
acpi=noirqIf either of these restores the touchpad consistently, that would further point toward an IRQ / ACPI-related issue.
MX Linux may be carrying downstream ACPI quirks that Arch does not. If you can identify the last known working kernel prior to November 2025, this would be a good candidate for an upstream report (ACPI / i2c-hid).
If possible, sharing an acpidump output and the MX Linux kernel version could help narrow this down further.
Last edited by 5hridhyan (Today 16:07:58)
Offline
This is a support forum, new threads are expected to be [unsolved] , please remove it from the title (edit first post).
Current OS: CachyOS (kernel 6.18.2-2-cachyos) - I prefer to remain on CachyOS due to its Arch compatibility and performance benefits
If you stick to that, this thread will be dustbinned as we can only help with troubleshooting archlinux systems.
What was the kernel version used before that november update ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
https://pastebin.com/c4eDtrjz DMESG LOGS
https://pastebin.com/qWFfhirB JOURNALCTL LOGS
Offline
This is a support forum, new threads are expected to be [unsolved] , please remove it from the title (edit first post).
removed.
If you stick to that, this thread will be dustbinned as we can only help with troubleshooting archlinux systems.
i meant that i don't want to use distros that aren't based on arch
What was the kernel version used before that november update ?
the laptop was not updated for a long time (about six months), I don’t remember the exact version on which it worked
Offline
Good report, thanks for the detailed logs.
Given that the touchpad works on MX Linux and also works after a manual modprobe i2c_hid, this suggests a possible upstream regression in I²C-HID / ACPI initialization order rather than a firmware or hardware failure.
A few points that may help narrow it down:
The irq 27: nobody cared message followed by IRQ disable looks significant. Once that IRQ is disabled, the touchpad would no longer be able to generate events, which could indicate a regression in IRQ routing or ACPI resource handling.
intel-hid has been known to interfere with I²C devices on some systems. It may be worth testing with:
module_blacklist=intel-hid,intel_ishtp_hid
while leaving i2c_hid_acpi enabled.
Since manual module reload works, another thing to test is forcing early loading via initramfs:
MODULES=(i2c_hid i2c_hid_acpi hid_multitouch)
followed by mkinitcpio -P.
For testing purposes only, it might also be useful to try:
pci=nomsi
or
acpi=noirq
If either restores the touchpad consistently, that would further point toward an IRQ/ACPI-related issue.
MX Linux may be carrying downstream ACPI quirks that Arch does not. If the last known-working kernel prior to Nov 2025 can be identified, this may be a good candidate for upstream reporting (ACPI / i2c-hid).
If you’re able to share acpidump output and the MX Linux kernel version, it could help narrow this down further.
Sorry for misleading you, there used to be a problem with the touchpad turning off and reloading the kernel modules helped. i'll fix post.
also i will try everything you suggest
Offline
@ng-link Thank you for sharing the dmesg and journalctl logs.
I just realized this is the Arch Linux forum, so I won’t be able to help troubleshoot CachyOS directly.
If you can reproduce the issue on Arch Linux itself and share the corresponding logs, I (or others here) can help debug further.
Offline
@ng-link Thank you for sharing the dmesg and journalctl logs.
I just realized this is the Arch Linux forum, so I won’t be able to help troubleshoot CachyOS directly.
If you can reproduce the issue on Arch Linux itself and share the corresponding logs, I (or others here) can help debug further.
I had the same problem on Arch Linux, I tried changing it to Cachy Os, but it didn't help. I'll try to get logs from Arch Linux.
Offline