Re: [BUG] HID: i2c-hid: ELAN 04F3:30FD touchpad reset race causes -EREMOTEIO on HP Pavilion Gaming 15-ec1xxx

One more finding, potentially significant: I found that holding/tapping
F9 at boot (HP's boot menu) repeatedly, or alternatively entering the
UEFI Firmware Settings from GRUB and immediately continuing boot, gives
the touchpad a reliable, working boot on my Ubuntu installation
(tested this handful of times, consistently works).

However, the exact same procedure on my Arch installation (same
hardware, same BIOS, back to back on the same day) does NOT make the
touchpad work - I tried this 2-5 times on Arch, no success. So
whatever this trick does (presumably giving the firmware/EC extra time
before OS handoff), it's not sufficient on its own on Arch, even
though it reliably helps on Ubuntu.

I don't have a clean explanation, but this seems like a meaningful
data point: it suggests there may be something about how Arch's boot
path (systemd-boot, initramfs/mkinitcpio, or something else early in
userspace) interacts with this differently than Ubuntu's (GRUB +
initramfs-tools), on top of whatever the F9/firmware-settings trick is
doing at the hardware level. I'm not sure how to narrow this down
further myself - let me know if there's a specific comparison (e.g.
timing between firmware handoff and first i2c probe attempt, or
something in ACPI _PS0/_PS3 execution) that would help pin this down.

Thanks,
Adam


On Thu, Aug 27, 2026 at 11:44 PM Adam [off-list ref] wrote:

Thanks for the detailed hypothesis - here are the results.

I did 5 warm boots (reboot) and 5 cold boots (shutdown, wait, then
power on), with dyndbg still enabled, and physically tried moving the
touchpad after each one. Subjectively, the touchpad did NOT respond to
touch in any of the 10 boots - I never saw the cursor move.

However, when I went through the logs afterward, I noticed something
odd: in one of the 5 warm boots (boot #4) and one of the 5 cold boots
(boot #4), the log shows the device transitioning from repeated
-121 errors into a long stream of "input: ..." lines with what look
like changing/plausible HID report data - 1353 such lines over about
28 seconds in the warm case, 441 lines in the cold case (that one
kept going intermittently, mixed with more -121 "failed to set a
report" errors, for several minutes based on the timestamps - I let
it sit rather than immediately rebooting).

So the kernel-level input events appear to have been getting
generated in those two runs, but I did not perceive any cursor
movement, and I don't have an explanation for that discrepancy - I
was actively trying to move the touchpad during that window in both
cases. I don't know if this is meaningful (e.g. some kind of
noise/garbage data that happens to look like report data) or if
there's a userspace/libinput layer issue on top of a technically
"working" kernel driver. Attaching both full logs
(warm-boots.txt, cold-boots.txt) in case the raw data is useful -
each file has all 5 boots separated by a blank line.

Overall: no clear cold-vs-warm pattern from this sample (1/5 success
in each category, by the log's definition of "success" - not by my
subjective experience of the touchpad working).

I also ran your unbind/bind commands on the platform driver during a
dead state:

echo AMDI0010:03 | sudo tee /sys/bus/platform/drivers/i2c_designware/unbind
echo AMDI0010:03 | sudo tee /sys/bus/platform/drivers/i2c_designware/bind

This did trigger a fresh probe (dmesg shows "HID probe called for i2c
0x15" right after, and the HID descriptor was fetched successfully
this time), but the reset/power-setting sequence right after still
failed the same way:

  i2c_hid_xfer: cmd=05 00 00 01
  failed to reset device: -121
  i2c_hid_set_power
  i2c_hid_xfer: cmd=05 00 01 08
  [repeats a couple more times, same errors]

So as you suspected, it did not recover functionality - the platform
driver rebind gets further than a cold boot sometimes does (descriptor
fetched right away) but still fails at the reset/power stage. I also
physically tried moving the touchpad afterward - still completely
unresponsive.

Let me know if a larger sample size (more boots) or anything else
would help narrow down the input-events-without-perceived-movement
discrepancy.

Thanks,
Adam