Hello,
I'm reporting a reproducible probe failure for an ELAN i2c-hid touchpad
(ACPI ELAN0718:00, VID:PID 04F3:30FD) on an HP Pavilion Gaming 15-ec1033nw
(AMD platform, i2c bus under AMDI0010:03). The touchpad fails to
initialize on nearly every boot on Linux, while the same hardware works
reliably every time under Windows 11 on the same machine (dual context,
same BIOS F.35 rev.A).
Kernel: 7.1.6-arch1-1 (Arch Linux)
Also reported by other users with the same touchpad ID on different
kernels/distros (Arch, Ubuntu, Linux Mint) going back to at least 2022:
- https://bbs.archlinux.org/viewtopic.php?id=277393
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2031061
- https://forums.linuxmint.com/viewtopic.php?t=329212
Symptom (default logging):
i2c_hid_acpi i2c-ELAN0718:00: failed to fetch HID descriptor: -121
i2c_hid_acpi i2c-ELAN0718:00: Failed to fetch the HID Descriptor
i2c_hid_acpi i2c-ELAN0718:00: probe with driver i2c_hid_acpi failed with
error -121
With dynamic_debug enabled for i2c_hid and i2c_hid_acpi:
i2c_hid_start_hwreset
i2c_hid_set_power: cmd=05 00 00 08
i2c_hid_xfer: cmd=05 00 00 01
i2c_hid_finish_hwreset: waiting...
i2c_hid_finish_hwreset: finished.
asking HID report descriptor
i2c_hid_xfer: cmd=02 00
reading report descriptor failed
can't add hid device: -121
probe with driver i2c_hid_acpi failed with error -121
Note the device is already tagged with I2C_HID_QUIRK_BOGUS_IRQ and
I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESET via the USB_VENDOR_ID_ELAN,
HID_ANY_ID entry in i2c_hid_quirks[], but this specific chip still
appears to need additional settle time between the reset-complete IRQ
and the immediately following descriptor read - the two happen back to
back (sub-millisecond apart in the trace) with zero delay.
The i2c bus and controller are not at fault: an ACPI-level PCI
remove/rescan of the SMBus controller (0000:00:14.0, piix4_smbus)
successfully re-enumerates the bus, and once probe *does* succeed
(intermittently - roughly 1 in 10-15 boots in my testing), the touchpad
works completely normally for the rest of the session. This points to a
narrow timing race rather than a persistent hardware/firmware fault.
Windows never exhibits this behavior on the same machine.
I tested a draft workaround patch (attached) attempting to add msleep()
delays after i2c_hid_finish_hwreset() and before descriptor fetch for
devices with I2C_HID_QUIRK_BOGUS_IRQ, but the issue still persists on my
machine. I am attaching the patch and debug logs in hopes that maintainers
can pinpoint the exact timing, sequence, or quirk needed for this ELAN
revision.
Happy to test alternate patches, adjust delay values, or gather any
additional traces (i2cdump, further dynamic_debug, ACPI tables via
acpidump) if useful.
Hardware:
- HP Pavilion Gaming 15-ec1033nw
- AMD Ryzen 5 4600H
- BIOS F.35 rev.A (latest per HP support site)
- Touchpad: ACPI ELAN0718:00, USB VID:PID 04F3:30FD, on i2c-3 /
AMDI0010:03
Let me know if you'd like the full dmesg, acpidump, or anything else.
Thanks,
Adam
Quick correction to my previous message - I found a logic bug in the patch
I attached.
The second hunk (delay before the very first HID descriptor fetch in
probe()) checked `ihid->quirks & I2C_HID_QUIRK_BOGUS_IRQ`, but at that
point in probe() the USB vendor/product ID hasn't been read yet - it's
only populated a few lines later, from the very descriptor fetch the
delay was supposed to precede. So the quirk lookup hadn't happened yet,
the condition was always false, and that delay never actually ran. That
explains why the timing in dmesg was unchanged with the patch applied.
I've fixed this by keying off the ACPI/i2c device name instead
(`dev_name(&client->dev)`, e.g. "i2c-ELAN0718:00"), which is available
from the very start for ACPI-enumerated devices. Updated patch attached
(v2). I haven't been able to fully verify this version end-to-end yet
(ran into some build/test issues on my end), so please treat it as a
starting point rather than a confirmed fix - happy to test further if
useful.
Thanks,
Adam
On Mon, Aug 10, 2026 at 7:31 PM Adam [off-list ref] wrote:
Hello,
I'm reporting a reproducible probe failure for an ELAN i2c-hid touchpad
(ACPI ELAN0718:00, VID:PID 04F3:30FD) on an HP Pavilion Gaming 15-ec1033nw
(AMD platform, i2c bus under AMDI0010:03). The touchpad fails to
initialize on nearly every boot on Linux, while the same hardware works
reliably every time under Windows 11 on the same machine (dual context,
same BIOS F.35 rev.A).
Kernel: 7.1.6-arch1-1 (Arch Linux)
Also reported by other users with the same touchpad ID on different
kernels/distros (Arch, Ubuntu, Linux Mint) going back to at least 2022:
- https://bbs.archlinux.org/viewtopic.php?id=277393
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2031061
- https://forums.linuxmint.com/viewtopic.php?t=329212
Symptom (default logging):
i2c_hid_acpi i2c-ELAN0718:00: failed to fetch HID descriptor: -121
i2c_hid_acpi i2c-ELAN0718:00: Failed to fetch the HID Descriptor
i2c_hid_acpi i2c-ELAN0718:00: probe with driver i2c_hid_acpi failed with
error -121
With dynamic_debug enabled for i2c_hid and i2c_hid_acpi:
i2c_hid_start_hwreset
i2c_hid_set_power: cmd=05 00 00 08
i2c_hid_xfer: cmd=05 00 00 01
i2c_hid_finish_hwreset: waiting...
i2c_hid_finish_hwreset: finished.
asking HID report descriptor
i2c_hid_xfer: cmd=02 00
reading report descriptor failed
can't add hid device: -121
probe with driver i2c_hid_acpi failed with error -121
Note the device is already tagged with I2C_HID_QUIRK_BOGUS_IRQ and
I2C_HID_QUIRK_NO_WAKEUP_AFTER_RESET via the USB_VENDOR_ID_ELAN,
HID_ANY_ID entry in i2c_hid_quirks[], but this specific chip still
appears to need additional settle time between the reset-complete IRQ
and the immediately following descriptor read - the two happen back to
back (sub-millisecond apart in the trace) with zero delay.
The i2c bus and controller are not at fault: an ACPI-level PCI
remove/rescan of the SMBus controller (0000:00:14.0, piix4_smbus)
successfully re-enumerates the bus, and once probe *does* succeed
(intermittently - roughly 1 in 10-15 boots in my testing), the touchpad
works completely normally for the rest of the session. This points to a
narrow timing race rather than a persistent hardware/firmware fault.
Windows never exhibits this behavior on the same machine.
I tested a draft workaround patch (attached) attempting to add msleep()
delays after i2c_hid_finish_hwreset() and before descriptor fetch for
devices with I2C_HID_QUIRK_BOGUS_IRQ, but the issue still persists on my
machine. I am attaching the patch and debug logs in hopes that maintainers
can pinpoint the exact timing, sequence, or quirk needed for this ELAN
revision.
Happy to test alternate patches, adjust delay values, or gather any
additional traces (i2cdump, further dynamic_debug, ACPI tables via
acpidump) if useful.
Hardware:
- HP Pavilion Gaming 15-ec1033nw
- AMD Ryzen 5 4600H
- BIOS F.35 rev.A (latest per HP support site)
- Touchpad: ACPI ELAN0718:00, USB VID:PID 04F3:30FD, on i2c-3 /
AMDI0010:03
Let me know if you'd like the full dmesg, acpidump, or anything else.
Thanks,
Adam
On Mon, Aug 10, 2026 at 07:31:32PM +0200, Adam wrote:
Hello,
I'm reporting a reproducible probe failure for an ELAN i2c-hid touchpad
(ACPI ELAN0718:00, VID:PID 04F3:30FD) on an HP Pavilion Gaming 15-ec1033nw
(AMD platform, i2c bus under AMDI0010:03). The touchpad fails to
initialize on nearly every boot on Linux, while the same hardware works
reliably every time under Windows 11 on the same machine (dual context,
same BIOS F.35 rev.A).
Kernel: 7.1.6-arch1-1 (Arch Linux)
Also reported by other users with the same touchpad ID on different
kernels/distros (Arch, Ubuntu, Linux Mint) going back to at least 2022:
- https://bbs.archlinux.org/viewtopic.php?id=277393
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2031061
- https://forums.linuxmint.com/viewtopic.php?t=329212
Symptom (default logging):
i2c_hid_acpi i2c-ELAN0718:00: failed to fetch HID descriptor: -121
i2c_hid_acpi i2c-ELAN0718:00: Failed to fetch the HID Descriptor
i2c_hid_acpi i2c-ELAN0718:00: probe with driver i2c_hid_acpi failed with
error -121
With dynamic_debug enabled for i2c_hid and i2c_hid_acpi:
i2c_hid_start_hwreset
i2c_hid_set_power: cmd=05 00 00 08
i2c_hid_xfer: cmd=05 00 00 01
i2c_hid_finish_hwreset: waiting...
i2c_hid_finish_hwreset: finished.
asking HID report descriptor
i2c_hid_xfer: cmd=02 00
reading report descriptor failed
can't add hid device: -121
probe with driver i2c_hid_acpi failed with error -121
Could you attach full dmesg with debug enabled, of failing boot and
successfull boot? And also acpidump?
Thanks,
Lovekesh
Thanks for looking into this.
Attached:
- dmesg-failing-boot.txt - full dmesg from a failing boot, with
i2c_hid.dyndbg=+p and i2c_hid_acpi.dyndbg=+p set on the kernel command
line from the start, on the unpatched linux kernel (7.1.8-arch1-3).
- acpidump-output.txt - full acpidump output from the same machine.
Unfortunately I wasn't able to capture a successful boot for comparison
despite several attempts - in my experience the touchpad only initializes
successfully very rarely (I estimated roughly 1 in 10-15 boots when I was
testing before, but going by the last few days of retries it seems to be
even less frequent than that, maybe closer to 1 in 30+). I'm happy to keep
retrying over the coming days and send a successful-boot log if/when I
get one, if that's still useful.
Let me know if there's anything else that would help.
Thanks,
Adam
On Sat, Aug 15, 2026 at 9:33 PM Lovekesh Solanki <
lovekeshsolanki00@gmail.com> wrote:
On Mon, Aug 10, 2026 at 07:31:32PM +0200, Adam wrote:
quoted
Hello,
I'm reporting a reproducible probe failure for an ELAN i2c-hid touchpad
(ACPI ELAN0718:00, VID:PID 04F3:30FD) on an HP Pavilion Gaming
15-ec1033nw
quoted
(AMD platform, i2c bus under AMDI0010:03). The touchpad fails to
initialize on nearly every boot on Linux, while the same hardware works
reliably every time under Windows 11 on the same machine (dual context,
same BIOS F.35 rev.A).
Kernel: 7.1.6-arch1-1 (Arch Linux)
Also reported by other users with the same touchpad ID on different
kernels/distros (Arch, Ubuntu, Linux Mint) going back to at least 2022:
- https://bbs.archlinux.org/viewtopic.php?id=277393
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2031061
- https://forums.linuxmint.com/viewtopic.php?t=329212
Symptom (default logging):
i2c_hid_acpi i2c-ELAN0718:00: failed to fetch HID descriptor: -121
i2c_hid_acpi i2c-ELAN0718:00: Failed to fetch the HID Descriptor
i2c_hid_acpi i2c-ELAN0718:00: probe with driver i2c_hid_acpi failed
with
quoted
error -121
With dynamic_debug enabled for i2c_hid and i2c_hid_acpi:
i2c_hid_start_hwreset
i2c_hid_set_power: cmd=05 00 00 08
i2c_hid_xfer: cmd=05 00 00 01
i2c_hid_finish_hwreset: waiting...
i2c_hid_finish_hwreset: finished.
asking HID report descriptor
i2c_hid_xfer: cmd=02 00
reading report descriptor failed
can't add hid device: -121
probe with driver i2c_hid_acpi failed with error -121
Could you attach full dmesg with debug enabled, of failing boot and
successfull boot? And also acpidump?
Thanks,
Lovekesh
One more data point, in case it's useful.
I also tried a fresh openSUSE Tumbleweed live/install on the same
hardware. On one boot the touchpad did start working - dmesg from that
boot is attached as dmesg-opensuse-working.txt. A few things that stood
out:
- The initial HID descriptor fetch succeeded quickly (~2.3s in), unlike
the usual Arch failure.
- Registration (hid-generic, then hid-multitouch) proceeded normally.
- Every subsequent get/set report transaction still failed with -121
for roughly 35-38 seconds after that (including one "device returned
incorrect report (2 vs 6 expected)"), before apparently
self-resolving - no further errors after that point, and the
touchpad was usable.
I then rebooted the same openSUSE several more times and got
the usual non-working result again, so this doesn't seem to be
something openSUSE fixes - just the same intermittent race showing up
there too. It does suggest the issue may not be limited to the very
first reset/descriptor-fetch step - there may be an ongoing i2c bus
communication problem for a while after boot that intermittently
self-resolves, rather than a single narrow timing window right at
probe.
Happy to keep gathering data if useful.
Thanks,
Adam
On Sun, Aug 16, 2026 at 7:52 PM Adam [off-list ref] wrote:
Thanks for looking into this.
Attached:
- dmesg-failing-boot.txt - full dmesg from a failing boot, with
i2c_hid.dyndbg=+p and i2c_hid_acpi.dyndbg=+p set on the kernel command
line from the start, on the unpatched linux kernel (7.1.8-arch1-3).
- acpidump-output.txt - full acpidump output from the same machine.
Unfortunately I wasn't able to capture a successful boot for comparison
despite several attempts - in my experience the touchpad only initializes
successfully very rarely (I estimated roughly 1 in 10-15 boots when I was
testing before, but going by the last few days of retries it seems to be
even less frequent than that, maybe closer to 1 in 30+). I'm happy to keep
retrying over the coming days and send a successful-boot log if/when I
get one, if that's still useful.
Let me know if there's anything else that would help.
Thanks,
Adam
On Sat, Aug 15, 2026 at 9:33 PM Lovekesh Solanki <
lovekeshsolanki00@gmail.com> wrote:
quoted
On Mon, Aug 10, 2026 at 07:31:32PM +0200, Adam wrote:
quoted
Hello,
I'm reporting a reproducible probe failure for an ELAN i2c-hid touchpad
(ACPI ELAN0718:00, VID:PID 04F3:30FD) on an HP Pavilion Gaming
15-ec1033nw
quoted
(AMD platform, i2c bus under AMDI0010:03). The touchpad fails to
initialize on nearly every boot on Linux, while the same hardware works
reliably every time under Windows 11 on the same machine (dual context,
same BIOS F.35 rev.A).
Kernel: 7.1.6-arch1-1 (Arch Linux)
Also reported by other users with the same touchpad ID on different
kernels/distros (Arch, Ubuntu, Linux Mint) going back to at least 2022:
- https://bbs.archlinux.org/viewtopic.php?id=277393
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2031061
- https://forums.linuxmint.com/viewtopic.php?t=329212
Symptom (default logging):
i2c_hid_acpi i2c-ELAN0718:00: failed to fetch HID descriptor: -121
i2c_hid_acpi i2c-ELAN0718:00: Failed to fetch the HID Descriptor
i2c_hid_acpi i2c-ELAN0718:00: probe with driver i2c_hid_acpi failed
with
quoted
error -121
With dynamic_debug enabled for i2c_hid and i2c_hid_acpi:
i2c_hid_start_hwreset
i2c_hid_set_power: cmd=05 00 00 08
i2c_hid_xfer: cmd=05 00 00 01
i2c_hid_finish_hwreset: waiting...
i2c_hid_finish_hwreset: finished.
asking HID report descriptor
i2c_hid_xfer: cmd=02 00
reading report descriptor failed
can't add hid device: -121
probe with driver i2c_hid_acpi failed with error -121
Could you attach full dmesg with debug enabled, of failing boot and
successfull boot? And also acpidump?
Thanks,
Lovekesh
Sorry for the somewhat scattered updates - let me summarize where
things actually stand now, as clearly as I can.
BIOS timeline:
1. After a firmware update a while back, the live ISO worked reliably
on every boot.
2. I later reset only the BIOS "Security" section to factory defaults
(removing a BIOS password) - after that, the live ISO started
failing intermittently too.
3. I then did a full BIOS factory reset (all sections) - the live ISO
went back to working reliably again, matching point 1.
Current state (BIOS at full factory defaults, F.35 rev.A):
- Live ISO (tested: Arch, Linux Mint 6.14 kernel, CachyOS with a recent
kernel) works reliably, essentially every boot.
- My installed Arch system still fails to initialize the touchpad on
most boots. Occasionally (rarely) it briefly comes alive - I can move
the cursor about a centimeter - before immediately stopping again.
- I also tried fresh installs of NixOS, Fedora, and openSUSE on the
same hardware - touchpad did not work reliably on any of them either,
similar to my Arch experience.
So the live-vs-installed distinction does seem to be real and
reproducible on this hardware, not just a run of lucky/unlucky boots -
sorry for my earlier message suggesting otherwise, that was based on
incomplete testing at the time.
I went through my installed Arch config (udev rules, modprobe
blacklists, kernel cmdline params) looking for anything that might
explain the difference and removed a few custom things (a stale udev
rule doing an i2c reset on device add, i8042/psmouse params) - none of
it changed the behavior on the installed system.
I don't have a good explanation for why live environments are reliably
fine but every installed OS I've tried (across several distros) isn't,
given they're running similar/same kernels. Happy to gather whatever
comparison data would help narrow that down - let me know what would
be most useful (e.g. specific dyndbg output, i2c bus traces, ACPI
power state info at the point of failure, etc).
Attached: dmesg-mint-working.txt - a clean successful boot on Linux
Mint (kernel 6.14.0-37-generic, live environment) on this same
hardware. No -121 errors at all, probe and registration succeeded on
the first try (~2.8s in). Might be a useful reference point against
the failing traces from the installed system.
Thanks for your patience with the back-and-forth,
Adam
Thanks for data collection,
I doubt this is a race condition, your openSUSE boot still shows -121
errors until ~38s after registration. Maybe the firmware has a window
after power up where its unresponsive even in good boots?
I'm thinking if this is a power state issue where it works in cold boots
but fails in warm ones, touchpad might still be in sleep state after
warm reboots.
Could you try performing a few cold boots and warm boots, see if
touchpad works after cold boots?
And when touchpad is dead after boot try running these two commands:
echo AMDI0010:03 | sudo tee /sys/bus/platform/drivers/i2c_designware/unbind
echo AMDI0010:03 | sudo tee /sys/bus/platform/drivers/i2c_designware/bind
See if they recover functionality. I'm hoping they won't.
Thanks,
Lovekesh
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
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