#334 Lenovo X1 Yoga finger touch input stops working after stylus is used

[James Newton]

Hi,

I am seeing some strange behaviour with my Lenovo X1 yoga tablet PC touchscreen. On booting up (or logging out and in again) everything is working fine, but as soon as I use the stylus input on the touchscreen, the finger touch input stops working.

I haven't been able to locate any log messages (in syslog, Xorg.0.log, dmesg) corresponding to when this happens.

When my desktop starts up I get the following message in syslog:

unity-settings-[13467]: Failed to create fallback wacom device for '/dev/input/event13': Device '/dev/input/event13' is not a tablet (2)

and event 13 does correspond to the finger input:

/sys/class/input/event13/device$ cat name
Wacom Co.,Ltd. Pen and multitouch sensor Finger

---

This is the output of xsetwacom --list:

[user@home ~]$ xsetwacom --list
Wacom Co.,Ltd. Pen and multitouch sensor Finger touch id: 9 type: TOUCH
Wacom Co.,Ltd. Pen and multitouch sensor Pen stylus id: 10 type: STYLUS
Wacom Co.,Ltd. Pen and multitouch sensor Pen eraser id: 16 type: ERASER

This behaviour started on upgrade to Ubuntu 17.04 beta (Unity desktop, Linux kernel 4.10, xf86-input-wacom 0.33), there was no problem with Ubuntu 16.10 and kernel 4.8.

Best regards,

James

[Jason Gerecke]

It sounds like the kernel driver is probably working correctly since a logout seems to fix the issue, but to be sure I'd like to to capture some logs for me. You'll need to install the "evemu-tools" and "xinput" packages.

To see if the kernel driver is continuing to send events, run the following command: sudo evemu-record and then select the finger device from the list. If you touch the screen, you should see a number of events scrolling by. Next, bring the pen into and then out of proximity (to reproduce your issue). Finally, touch the screen a second time -- do you see more events scrolling?

To see if the X driver is sending events, run the following command: xinput test-xi2 --root "Wacom Co.,Ltd. Pen and multitouch sensor Finger touch". Ideally you should see events from the finger both before and after bringing the pen into prox, just as with the kernel events. Is this the case?

Once I'm sure which component is causing the trouble, I can help you probe further into its cause.

[James Newton]

Thanks!

The evemu-record command shows events from the finger both before and after the pen is brought into prox, but the xinput command only shows events from the finger before bring the pen into prox.

[Jason Gerecke]

It looks like both 16.04 and 17.04 use the same version of the X driver, so its odd that things are no longer working. I'd like to get some debug logs from the X driver. To do that, reboot to ensure the Xorg log starts out nice and small. Next, copy/paste the following commands into a terminal for me (if you need to move your pointer to do so, please use your touchpad or trackpoint for the moment):

$ xsetwacom list | cut -f1 | while read D; do xsetwacom set "$D" TabletDebugLevel 10; done
$ xsetwacom list | cut -f1 | while read D; do xsetwacom set "$D" ToolDebugLevel 10; done
$ sudo evemu-record > pen.log

Since the last command runs evemu-record, you'll need to select your pen device from the list. With evemu-record running and the X driver's debug logging enabled, we'll now gather a sequence of events. First, make a single drag across the the screen with your finger. Wait two or three seconds and then make a single drag across the screen with your pen. Wait another two or three seconds, and then make a single drag across the screen with your finger again. Use the touchpad/trackpoint to navigate the pointer back into the terminal and run the following commands (they're the same as the first two, only with "0" instead of "10"):

# Press CTRL+C to stop evemu-record
$ xsetwacom list | cut -f1 | while read D; do xsetwacom set "$D" TabletDebugLevel 0; done
$ xsetwacom list | cut -f1 | while read D; do xsetwacom set "$D" ToolDebugLevel 0; done

Once debugging has been disabled you can use the pen and touch freely again. Please attach your Xorg.0.log for review. It may be located at either ~/.local/share/xorg/Xorg.0.log or at /var/log/Xorg.0.log. If both files are present, attach whichever contains lines with the text "usbParseEvent". Additionally, attach the generated pen.log file.

Hopefully this gives me an idea of where in the X driver the events stop flowing and for what reason.

[James Newton]

Logs attached. Thanks for your help.

[Jason Gerecke]

Looks like the issue is that the pen is reporting a serial number of 0 (which isn't valid) for its final out-of-prox event. The X driver sees that the serial is invalid and ignores the event before passing it further up the stack. Because the event is discarded, the driver never realizes the pen has left proximity. When you next touch the screen, the driver refuses to do anything since normally any touches that occur with the pen in prox are unintentional. Since the prox state is never reset, touch is effectively disabled until the driver restarts.

So the question is: why does the pen now send a serial number of 0 in its out-of-prox report? I'll take a look at the changes betwen the 4.8 kernel and the 4.10 kernel to see if I can pinpoint the cause.

[Jason Gerecke]

I've looked through the kernel code to see if I could figure out why we're now getting a serial number of 0, but although I found some suspicious code it appears to work correctly on the tablet PC I have here.

Could you please follow the instructions at https://bentiss.github.io/hid-replay-docs/ to install the "hid-replay" suite of tools? Once it has been installed, run sudo hid-recorder > bug.hid.log and choose the Wacom device. Next, repeat the testing steps I outlined above: make a single drag with your finger, a single drag with your pen, and then a single drag with your finger. Press CTRL+C to stop recording and upload the log.

This log will contain the hardware events that the kernel driver is translating into pen/touch events that userspace understands. I should be able to replay the sequence of events locally to see exactly how the kernel driver (both old and new) reacts.

[James Newton]

OK I will go ahead and do this. I'm on vacation without my laptop right now, so it'll be next week.

[James Newton]

Logs attached from hid-recorder. There were two Wacom devices listed with the same description (/dev/hidraw0 and /dev/hidraw1) so I recorded with both options.

[BrianC]

I am having the same problem on Lenovo Thinkpad P40 Yoga on Arch 4.10.6-1

I want to acknowledge that the latest Arch 4.10.8-1 xorg and nvidia does not work. For that reason, I remain on 4.10.6-1 version.

DE is GNOME.

The finger touch does not work after the pen touches the screen wacom. I typed,

  xinut set-prop wacom co. LLtd Pen and multitouch sensor Finger touch device enabled 1

The finger touch still does not work.

The wacom pen stylus was moved to another section in the xinput. However we couldn't log this case because it occured after I ran the script to turn on the finger touch.

xinut set-prop wacom co. LLtd Pen and multitouch sensor Finger touch device enabled 1

I also want to include that the gnome shell extension finger touch script does not work at all.

Here are the logs.

[Jason Gerecke]

BrianC, thanks for the additional logs. I'm reviewing everything right now to see if I can determine the cause.

Tangentially, it doesn't look like we have any information about the Lenovo Thinkpad P40 Yoga aside from the logs you've posted here. Would you mind running our sysinfo.sh script and attaching its results? This gives us a bit more information about the systems and sensor hardware that's out there...

[BrianC]

Here are my sysinfo logs.

I tried your latest solution, I couldn't get it working at all. I tried to install it, and look at the version, it is still at v.2.0.0. . I compiled it, and run the scripts, but I have not seen new events that was created.

[Ping Cheng]

Brian, you are not running the updated kernel driver. Please follow the steps given by Jason and make sure the wacom.ko under /lib/modules//$(uname -r)/kernel/drivers/hid is the same as in input-wacom

[Jason Gerecke]

Okay, I think I've tracked down the source of this issue. Please follow the input-wacom instructions, except replacing the instructions in the "Download" section with the following (you may need to install 'git' from your package manager):

$ git clone https://github.com/jigpu/input-wacom -b fix/generic-serial
$ cd input-wacom

Follow the rest of the instructions for configuring/compiling/installing/loading the driver as normal. Let me know if the updated driver seems to work properly. If not, please ensure that the output of cat /sys/module/wacom*/version contains the following output: v2.00-0.35.0.1.g8313ac6 -- if not, it means that the replacement driver has not loaded for some reason.

[James Newton]

The replacement driver has fixed the problem. Thanks!!

[Jason Gerecke]

Fix accepted into (upstream) Jiri's for-4.11/upstream-fixes branch as commit 4e7b9b3. Expected release: Linux 4.11.

Fix accepted into input-wacom's jiri/for-4.11 branch as commit 47da93b. Expected release: input-wacom 0.36.0

Fix accepted into input-wacom's jiri/for-4.12 branch as part of merge commit 1d4fe8a. Expected release: input-wacom 0.36.0

Fix backported into input-wacom's master branch as commit 8cfac44. Expected release: input-wacom 0.36.0

[BrianC]

The bug has resolved. Thank you!

I do have a minor problem, finger script will not initate during gnome-session. I have to manually to turn on by typing out xinput set-prop 'Wacom Co.,Ltd. Pen and multitouch sensor Finger touch' 'Device Enabled' 1

Is there a way to hook it prior to login screen?

Thanks again.

[Jason Gerecke]

Linux 4.11 released with bug fix.
Linux 4.10.13 released with bug fix (commit eff2486).
Still pending input-wacom release.

[Jason Gerecke]

Fix contained in input-wacom release 0.36.0