Linux Wacom Tablet Project / Bugs / #323 wacom resume problem Thinkpad Yoga14

Jason Gerecke - 2016-08-25

The "ran out of retries" errors indicate that something went wrong when the driver was trying to switch the sensor mode. Error "-110" is "timed out", while "-32" is "communication pipe broken". These errors are not generated by our driver, but rather passed up from lower levels hardware transport drivers (USB or I2C) and indicate communication problems with the sensor.

Those kinds of errors also make sense for being related to suspend/resume since its possible the sensor or USB/I2C hardware wasn't suspended/resumed properly. It would be interesting to know if they only show up on suspend/resume or if they also show up at boot. It appears that some Yoga devices never "really" shut off power to the sensor, and I'm not sure if the Yoga 14 is among them.

Also, could you elaborate a bit more on the xinput ids? You should have a "Finger touch", "Pen stylus" and "Pen eraser" listed during normal operation; do you see duplicate entries?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

torwag - 2016-08-26

Hi Jason,

thanks for looking into it. Yes, it seems to happen during boot as well as during resume.
At least thats my belive by looking at the timestamps of dmesg.
xinput shows only three devices. However, I noticed that the IDs changed. This is due to the fact that I have a very simple self made script which puts the laptop in a "presentation mode", playing around with xrandr, rotation, etc. One command I use is

xinput disable 10

which disables usually the touch input to avoid false detection of my handwrist during pen using in tablet mode. This worked out well, until recently, I checked xinput and the touch had suddenly an id 15 iirc.

However, using rmmod and modeprobe I get the wacom working after suspend. And in that case, it seems ids are back to the old values.... sounds strange I know.

What I could think of, with all that fancieness of asyncrounous boot-up and systemd-stuff, maybe the wacom-hardware is simply not ready when the driver starts to initalize. Could be that a few ms-postponing the driver loading already solves this problem. However, I have no idea how to do that in a correct way. Should that be done in the driver or should the driver be called later by the system? Would there be any way to test this theorem?

Last edit: torwag 2016-08-26

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jason Gerecke - 2016-08-26

The numeric IDs shouldn't be used in scripts since they can change depending on the order that the X server detects devices. Although the order should be pretty stable in your case, I would still recommend using the name (e.g. something like xinput disable "Wacom HID 5055 Finger touch"[1]) since its a bit more stable. Having the IDs return to normal after an rmmod/modprobe cycle is pretty normal. The fact that they change when broken is an interesting sign though.

Looking more closely, the driver should be calling 'wacom_set_report' up to five times if it has trouble. The fact that you see fewer than five messages appear makes me wonder if perhaps that it is (eventually) succeeding after all. Please try installing the AUR's hid-replay-git package. Afterwards, run sudo hid-recorder | tee /tmp/pen.working.txt and choose the pen device when prompted. You'll see a bunch of information appear; if you bring the pen into proximity or touch it to the screen, you should see additional output. Press CTRL+C to quit. Next, suspend and resume the system to "break" the pen. Now run sudo hid-recorder | tee /tmp/pen.broken.txt and repeat the above steps. Attach the two files (you may need to place them both in a tarball since I believe SourceForge only allows you to attach one file at a time) for review. They should give me an idea of what kind of data our driver is recieving from the sensor, and specifically whether it was able to correctly change modes after resuming.

[1]: I'm just guessing at the deivice name since I don't appear to have any information about the Yoga 14. Would you mind running the attached script and attaching the generated /tmp/wacom_info.tar.gz file? It will contain information about your system, as well as details of the Wacom sensor and how its physically connected inside.

getinfo.sh

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

torwag - 2016-11-30

Hi,
sorry for the long delay, I was rather busy and the trick with the rmmod, modprobe did help. However, a real fix might be even better.
Thus here are the files you was asking for.
I could not do it for the pen, since I left it in the office, but the symtoms are the same for the touch. hid-recorder asked me to select between two devices. It seems one is for touch and the other for pen.

Unfortunately, as you can see, there is no real info from hid-recorder. It simply does not log any infos after the touch is broken.
That is what I get after it is broken:

dmesg | grep wacom

[ 11.078310] wacom 0003:056A:502B.0001: hidraw0: USB HID v1.11 Device [Wacom Co.,Ltd. Pen and multitouch sensor] on usb-0000:00:14.0-5/input0
[ 11.254660] wacom 0003:056A:502B.0002: hidraw1: USB HID v1.11 Mouse [Wacom Co.,Ltd. Pen and multitouch sensor] on usb-0000:00:14.0-5/input1
[ 3885.086462] wacom 0003:056A:502B.0001: wacom_set_report: ran out of retries (last error = -110)
[ 3885.086735] wacom 0003:056A:502B.0001: wacom_set_report: ran out of retries (last error = -32)
[ 3885.092679] wacom 0003:056A:502B.0002: wacom_set_report: ran out of retries (last error = -32)

Whereas the first two lines are during boot (recognising the wacom units). The last three are after resume from suspend.

After (sudo):
rmmod wacom
modprobe wacom
touch and pen are working again and I get this two extra lines:
[ 6178.122892] wacom 0003:056A:502B.0001: hidraw0: USB HID v1.11 Device [Wacom Co.,Ltd. Pen and multitouch sensor] on usb-0000:00:14.0-5/input0
[ 6178.299681] wacom 0003:056A:502B.0002: hidraw1: USB HID v1.11 Mouse [Wacom Co.,Ltd. Pen and multitouch sensor] on usb-0000:00:14.0-5/input1

This is reproducable for every suspend-resume cycle.

Seems also not very promsing to read anything out of this.

Is there any other debug I could do? A debug mode of the kernel module maybe?

Thanks for looking into this

Last edit: torwag 2016-11-30

debug_yoga14.tar

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jason Gerecke - 2017-01-20

My own apologies for not replying sooner...

I notice that your report sounds very similar to one reported on the freedesktop.org bug tracker. Could you read through https://bugs.freedesktop.org/show_bug.cgi?id=95169 and let me know if it seems like the same thing? If you have the same device, I'd recommend updating the firmware if you can, and even if you have a different device there might be newer firmware to install as well.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jason Gerecke - 2018-01-24

status: new --> closed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jason Gerecke - 2018-01-24

Marking this bug as closed. Please let us know if it still persists even with the latest xf86-input-wacom and input-wacom drivers.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

wacom resume problem Thinkpad Yoga14

Searches

Help

#323 wacom resume problem Thinkpad Yoga14

Discussion