wacom_set_report: ran out of retries (ETIMEDOUT) about input-wacom HOT 6 CLOSED

I had the same frustrating issue with the Wacom stylus integrated into my pc. The stylus disconnected itself after 2 seconds of inactivity and took about 5 seconds of continuous clicking for the pen to work again. When the stylus reconnected, dmesg reported the following error

wacom 0003:056A:50B8.0006: wacom_set_report: ran out of retries (last error = -110)

Doing echo on > /sys/bus/usb/devices/1-10/power/control prevents the pen from disconnecting. However a less brutal solution is to change the autosuspend time (whose default is 2000 ms, too short in my opinion): this can be obtained permanently by adding a configuration file in /etc/udev/rules.d/99-wacom.rules

# Wacom Co., Ltd Pen and multitouch sensor rules (changing default autosuspend to 10 minutes)
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="056a", ATTR{idProduct}=="50b8", TEST=="power/autosuspend_delay_ms", ATTR{power/autosuspend_delay_ms}="600000"

My setup

• ThinkPad X1 Yoga 2nd
• os: Debian GNU/Linux bullseye/sid x86_64
• kernel: 5.7.6-1
• /sys/module/wacom/version: v2.00

from input-wacom.

Do you get multiple messages about wacom_set_report running out of retries? Is a new message logged whenever this issue occurs? I would only expect that message to be logged shortly after the computer starts up or (possibly, but not sure) resumes from suspend. If it shows up whenever the issue occurs, that almost sounds like the hardware is somehow connecting and disconnecting... Perhaps some kind of power management gone awry? That's not too far-fetched given that the sensor is attached to the USB bus, but still might not fully explain your symptoms...

I just found a bug in the code that would prevent the retry logic from working properly (causing wacom_set_report to only be attempted a single time). Its possible that correcting it will fix your issue... I've pushed the code up to a new branch my Github; please run git remote update && git checkout fix-issue-28 from within the copy you made for testing out the fix for issue 25. Once the driver is compiled and loaded, running $ cat /sys/module/wacom/version should print out v2.00-0.40.0.1.g1c228e6.

from input-wacom.

cat /sys/module/wacom/version after installing that branch gives v2.00-0.38.0.73.g1c228e6. Perhaps I'm missing a step in the build process?

Yes, that message is logged each time the delay occurs; sometimes multiple messages per occurrance, e.g.

[55781.645967] wacom 0003:056A:509D.0001: wacom_set_report: ran out of retries (last error = -110)
[55786.766020] wacom 0003:056A:509D.0001: wacom_set_report: ran out of retries (last error = -110)
[55791.885833] wacom 0003:056A:509D.0001: wacom_set_report: ran out of retries (last error = -110)
[55797.005615] wacom 0003:056A:509D.0001: wacom_set_report: ran out of retries (last error = -110)
[55802.125557] wacom 0003:056A:509D.0001: wacom_set_report: ran out of retries (last error = -110)
[55807.245501] wacom 0003:056A:509D.0001: wacom_set_report: ran out of retries (last error = -110)

followed by the stylus input suddenly 'coming to life' and working again.

(the above happening with the fix-issue-28 code, so apparently the problem persists)

from input-wacom.

Looks like I forgot to push the latest version tags to my repository. The difference in the cat output shouldn't matter since the commit ID (the last part) is identical which means that you're using the same version.

Seeing multiple messages per delay is expected with the fix-issue-28 branch since previously the kernel wouldn't bother with a retry and should have only logged the message once. I'm still not sure why its failing in the first place, why retrying doesn't help, and why/how the pen eventually "comes to life" again.

Does this happen even if the computer is not allowed to go to sleep? It could potentially be related to system suspend/resume, or to USB autosuspend.

If you're able to reproduce this issue several times (at least three, ideally four or more) in a single reboot, it would be helpful to have complete system logs to see if there's something that always happens before/after the ETIMEDOUT messages that would explain how or why the device stops/starts working. If you're able to get these multiple reproductions, run sudo journalctl -b0 | gzip > /tmp/log.gz to grab the logs and then upload it for review.

Also, please try using our capture.sh script to gather some information while the pen is working. Before running the script you'll need to install a few dependencies: sudo yum install xorg-11-server-utils evemu hid-replay. Once the dependencies are installed, run the script with sudo and select the pen device. Make a few strokes on screen and then press CTRL+C. The script will let you know where it saved a tarball of the logs; please attach that tarball to this bug for analysis.

from input-wacom.

Attached is the output of journalctl -b0 | gzip > /tmp/log.gz. I was unable to reproduce while capture.sh was running, which makes me think you're right about this being a USB autosuspend issue -- the system was not allowed to suspend during this testing window.

Turns out that echo on > /sys/bus/usb/devices/1-10/power/control prevents this behavior entirely, and as soon as I echo auto > /sys/bus/usb/devices/1-10/power/control it starts lagging again.

Attachment:
log.gz

from input-wacom.

Sorry for the delay in replying. Indeed, I don't see anything particularly strange in that log (other than the "ran out of retries" that you are reporting). It sounds like the hardware has some kind of issue with waking from autosuspend, especially given that changing the power control seems to fix the issue for you. Unfortunately, aside from recommending that you use the modified power control setting, I'm not sure if there's much else that we can do. The hardware is being commanded to switch modes but either isn't doing so, is lying about the failure, or is taking much longer than expected. Regardless, the driver seems to be working properly and I'm not aware of anything that we can do differently that would fix this...

I'm closing this issue for now, but please feel free to re-open it with additional details in the future...

from input-wacom.