Thinkpad X1 Yoga 6 Occasionally Stops Registering Touch Input

[hubblebug]

Occasionally when using a the stylus (Wacom Bamboo Ink or Lenovo Active Pen 2), the touchscreen will stop registering touch input. This appears to happen on either wayland or x11. Running evtest or libinput debug-events shows no activity from the touchscreen device at all, but activity from the stylus appears to be normal. Restarting the kernel module sudo rmmod wacom && sudo modprobe wacom brings back touchscreen functionality up until the stylus is used again. Afterwards the touchscreen will again stop working. Normal function with both the stylus and the touchscreen can only be brought back by restarting my computer.

I've tried running the sysinfo script, but I can't seem to find the output file it generates? Running it in my home directory prints "rebinding devices" as the last output, but no info on the output file, so if I'm missing this, let me know, so I can provide more info on my issue.

Info from /proc/bus/input/devices:

I: Bus=0018 Vendor=056a Product=527a Version=0100
N: Name="Wacom HID 527A Pen"
P: Phys=i2c-WACF2200:00
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-16/i2c-WACF2200:00/0018:056A:527A.0005/input/input37
U: Uniq=
H: Handlers=mouse3 event18
B: PROP=2
B: EV=1b
B: KEY=1c03 0 0 0 0 0
B: ABS=1000d000003
B: MSC=1

I: Bus=0018 Vendor=056a Product=527a Version=0100
N: Name="Wacom HID 527A Finger"
P: Phys=i2c-WACF2200:00
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-16/i2c-WACF2200:00/0018:056A:527A.0005/input/input38
U: Uniq=
H: Handlers=mouse4 event19
B: PROP=2
B: EV=b
B: KEY=400 0 0 0 0 0
B: ABS=260800000000003

uname-a:
Linux tumbleweed 5.16.10-1-default #1 SMP PREEMPT Thu Feb 17 05:36:42 UTC 2022 (fc3f7ab) x86_64 x86_64 x86_64 GNU/Linux

modinfo wacom

filename: /lib/modules/5.16.10-1-default/extra/wacom.ko
license: GPL
description: USB Wacom tablet driver
author: Vojtech Pavlik vojtech@ucw.cz
version: v2.00-0.42.0.216.g24e94f2
suserelease: openSUSE Tumbleweed
srcversion: F718216190788EA377F92E5

Thanks!

[mfs409]

I'm having a similar problem, except that sudo modprobe -r wacom; sudo modprobe wacom seems to re-enable touch and pen for a brief (but nondeterministic) amount of time. Linux Mint 20.3 on a Lenovo Thinkpad Yoga x390. Please DM me if you want me to provide more information.

[jigpu]

How long does it usually take for the touch input to stop working after using the pen? If it is a short enough period of time (e.g. a minute or two or use) we can try to have you record the raw data being sent from the sensor to the kernel. If the time period is longer, it may be a bit more difficult to help diagnose.

I would double-check that you have a complete copy of the sysinfo.sh script. I don't see how the "Rebinding devices" messages could be the last line printed out; it should either print out one additional line with the name of the device being re-bound, or print out the next task if no devices need to be re-bound. If you can get the sysinfo script to run, it would be most useful to run it after the problem occurs since the tarball will contain partial dmesg output that could include helpful error messages.

[throwm8]

I'm also experiencing the same problem, building the module from git temporarily fixed it for me but it then started to happen again(#304). In my case it usually happens after a couple minutes, dmesg contains no errors and reloading the kernel module temporarily fixes it until the stylus gets in and out of range again. I don't know why but touch works after reloading the module if the stylus is close enough to the screen for it to be detected, it stops working again only after the stylus is pulled away from the screen.

I can provide more information if necessary.

[CSEToddG]

To answer Jason's question above, roughly 5 to 10 minutes, but the timing is erratic.

For what it's worth, in testing with mfs409 it was noted that with Linux Mint 20.3, dropping back to kernel 5.4.0.99 in Grub works much better than 5.4.0.100 or 5.4.0.104 in keeping the stylus input functional.

It seems there may be a bug introduced (or possible regression) in the more recent kernel versions, but that's just a gut feel at this point.

[jigpu]

Apologies for the slow response time... I've tried to replicate this with a device from Dell but was unable to get it into a state where the touch stops working. Hopefully a long enough recording will give us the data we need to diagnose the issue further.

To capture a recording, please follow these steps:

1. Download our capture-multi.sh script and mark it as executable
2. Run sudo ./capture-multi.sh. If it prints an error message about missing requirements, install them and try again.
3. You should see the pen and touch device both listed under a single hidraw node. Type in the hidraw ID number when prompted and press
4. The script will begin recording. Try to reproduce the issue.
5. When you notice that touch input is no longer working, go back to the script and press CTRL+C to terminate the recording.
6. The script will zip up the logs into a single tarball and tell you where it can be found. Attach the file to this issue by dragging + dropping onto the comment box here.

Hopefully the log file isn't too big to attach... 5 to 10 minutes is an awful lot of data to be recorded...

[blepabyte]

I encountered the same problem (same device as well).

record_1651366054.tar.gz

The recording starts after running sudo rmmod wacom && sudo modprobe wacom so that the touchscreen is in a working state. The pen is moved close to the screen and then touch input appears to stop working. Hope this helps.

[Pinglinux]

@blepabyte Was pen in proximity when touch stopped working? Did touch work after moving the pen away from the surface?

[blepabyte]

I'm not sure of the exact moment that touch input stops working but it occurs sometime between when the pen enters proximity and when it leaves proximity.

Touch does not work afterwards until either the rmmod command is run again or the laptop enters/wakes up from suspend.

Also something I noticed is that while pen input works in that state, latency seems noticeably increased.

[jigpu]

Thanks for the recording! It looks like the issue is caused by the pen never sending an "out of prox" event. Our driver has a feature called "touch arbitration" which tries to prevent pen and touch input from conflicting with each other, with priority given to the pen (since you're likely to be resting your hand on the touchscreen whenever the pen is in use). If we never get the "out of prox" event, the driver has no way of knowing that it is safe to re-enable touch.

The simplest workaround would be to try to bring the pen back in and out of proximity again. This should give the pen another chance to send the missing event, which would re-enable touch. Does this seem to help at all?

Another workaround might be to disable the arbitration feature. It can be disabled temporarily (until the system is rebooted) by running echo "0" | sudo tee /sys/module/wacom/parameters/touch_arbitration, or permanently by adding wacom.touch_arbitration=0 to the kernel's command-line in grub. This should have an effect for users in a Wayland-based environment, though I'm not sure how reliable it will be. Users of X11-based environments will not see a difference unless they also change drivers to xf86-input-libinput (see this wiki page for instructions).

[blepabyte]

bring the pen back in and out of proximity again

Thanks for looking into this. Tried doing this with both the onboard pen stored in the device and another pen (HP Active Pen G3) but when touch arbitration is enabled, doesn't help.

Only when touch arbitration is disabled, moving the pen out of proximity slowly seems to get touch working about 50% of the time - with the weird quirk that touch events originating to the left of where the pen cursor last was get ignored (palm rejection?). The other 50% of the time, when the pen gets back into proximity it seems to replay a bunch of "missed events".
record_1652336376.tar.gz

[jigpu]

I think I've been able to come up with a solution to this problem. Please test it out and report back! 😃

First, clone the branch I've been doing development on: git clone https://github.com/jigpu/input-wacom.git -b wip-idleprox-timeout. Navigate to the newly-created "input-wacom" directory and then follow the instructions at https://github.com/linuxwacom/input-wacom/wiki/Installing-input-wacom-from-source to build and install the driver from that directory.

[blepabyte]

Just tried it and it works!

• Starting from a state where touch is nonfunctional, unloading the old driver and then loading the new one, the touchscreen consistently works again after a ~1s delay from when the pen is moved out of proximity.

• If I start dragging something with the mouse between pen leaving proximity and the timeout, the timeout seems to "release" the mouse, depending on application

Are there any downsides to reducing the timeout interval?

[jigpu]

That's great news! I arbitrarily set the timeout to a 1 second delay, but I don't think there would be a problem if we reduced it. The mouse release you mention in the second bullet point is likely just a result of some X driver confusion (you're basically using the pen and mouse simultaneously because of the timeout), so reducing the timeout should make that harder to experience.

The hid-letsketch driver uses a 100ms delay for the exact same issue, so it seems reasonable to try that out. I've just pushed an update to reduce the timeout in our driver -- please run git pull from inside your input-wacom directory and then rebuild / reinstall the driver.

[blepabyte]

Been using it for a while and works flawlessly. Thank you!

[jigpu]

Patch has been accepted by the HID subsystem maintainer as commit 94b179052f95c294d83e9c9c34f7833cf3cd4305. It should be part of the upcoming 5.19 kernel release. I've merged it back into the input-wacom master branch as well, so you can swap to using that instead of my personal branch. It should be part of input-wacom 0.49.0 whenever that gets released.