Lenovo yoga 7 gen 7 touchscreen will stop working after unknown causes

[amedeo03]

Hello, I recently bought a Lenovo Yoga 7 Gen 7 (the AMD version) I installed Arch Linux and I'm running the kernel 6.0.10-arch2-1. While using the computer in tablet mode with the Lenovo pen, occasionally the touchscreen will stop working altogether. The weird thing is I cannot reliably replicate the bug, it will happen after 5 minutes of work or maybe 50. Unloading and reloading the wacom module will do nothing and I'm forced to reboot the machine.

This issue is extremely similar to some older ones, likes #310 and #304 , but as far as I know, it should have been patched long ago.

Getting the logs from journald will give back this line:
wacom xxxx:xxxx:xxxx.xxxx: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.

I ran "sudo hid-recorder | tee output.log" as you suggested and I'm sorry if it is such a big file, but there is not a clear time window where the bug happens. After it happens though, I noticed it will not output touch data to the log anymore, so the last few lines should help you understanding what is going wrong. I'll attack the log together with the sysinfo.sh script output

Thanks in advance for the help, ask me whatever detail you need.

output.log
sysinfo.P5y1gwtLfk.tar.gz

[EnderMk9]

Hi, I'm having the same issue, have you found something new?

[amedeo03]

Sadly no, I had to switch back to Windows for now since this bug was very annoying, especially during classes.

[EnderMk9]

Just tried to use the pen in the latest commit of input-wacom and this error still happens

[nemuibanila]

I'm having the same issue, even after updating to kernel 6.4.1. I've noticed that the issue mostly happens: a. after a tap of the screen or b. after the pen goes out of proximity for a short moment (when it is on the edge of being detected and slips out).

I have tried:
Downgrading to kernel 6.3.9 (I didnt notice the issue there, but it could just have happened later into a boot)
Using the 6.1 LTS kernel
Compiling an older version of input-wacom directly as a module

I've attached my sysinfo, the prox timeout message is right at the end of dmesg
sysinfo.pCUfikW7w2.tar.gz

[EnderMk9]

I have been experiencing this issue since Linux 6.1 around February of this year

[nemuibanila]

I have collected additional information, I've recorded the raw sensor data as well.

Maybe for this specific device the idleprox handler is not able to recover the touch and pen state. I've tried different approaches at fixing this issue, but at this point I'm not really sure where to continue.. I think I understood the basics of the wacom module, but this seems to be something deeper.

For reference the pen I am using is the "Wacom Bamboo Ink Plus" pen, which is multi-protocol with both AES and MPP. The issue happens both in protocol 1 mode and protocol 2 mode. (and somehow even if I rmmod wacom). It also seems to be common that there is some kind of memory controller failure afterwards. On Windows, the pen works without issues.

I've tried different versions of input-wacom as a module, like without the timestamp averaging changes or removing the confidence checks entirely, but at the core of the issue it seems to be that there are no more hid events from both the stylus and touch. I am not sure which subsystem emits the raw hid events or if its a communication issue.

Weirdly enough, in the attached hid log the touch device goes through the registration procedure after the stylus stops working, but is still not able to create any events.

sysinfo.iT2E7pRmU8.tar.gz
output.log

record_1688550735.tar.gz

Edit: The pen works in the BIOS too

[nemuibanila]

@EnderMk9

I have been experiencing this issue since Linux 6.1 around February of this year

Do you by any chance still know which kernel still worked with the pen? Then I can narrow it down quite a bit.

At this point I think it might be related to changes in the i2c-hid implementation that might not play well with the wacom driver, but I will perform more testing in that direction.

[EnderMk9]

I've been experiencing this issue ever since i bought the laptop, so I couldn't say

[EnderMk9]

I have switched to debian testing, using kernel 6.4.4 and the problem persists, so we can discard a fedora-specific issue

[EnderMk9]

I would like confirmation but I believe that thanks to the patch made for issue 371, this problem has been fixed, or at least occurs much less often, because previously i had been only able to write a few seconds or minutes before the touchscreen crashing and now it's been half an hour writing and it's still working.
#371

[EnderMk9]

tomsom/yoga-linux#27
It seems it's not fixed, it's just very random

[ghost]

Same issue here. But I at least only noticed the issue with Wacom AES 2.0 Pens. The included Pen works without issues, which has no tilt and is AES 1.0. But as soon as i use a AES2.0 Pen, the stylus and touch freeze after some use. I tried the Bamboo Ink Plus and Lenovo Precision Pen 2 (2023). Also i noticed that the freeze, at least until now, only happened if i touch the screen (palm rejection) during writing. Pens work fine on Windows.

[Pinglinux]

There were quite some laptop related stylus issues. Since the laptops were originally run on Windows, we don't have any of those systems to test with. Without seeing the issues, we can't figure out the root cause.

[EnderMk9]

Can't we provide you with some information or log from our systems to help you determine the cause?

[Pinglinux]

The system specific issues are hard to trace even with the hardware in hand. Basically we don't know what specific setting/function may have considered when it was configured under Windows. The question may be better answered by OEM/ODM vendors. But, they only know their settings under Windows...

[EnderMk9]

If we can't find the root cause, can we at least make the drivers reload without rebooting the system? Currently, when it crashes you can't restart the drivers with kmod, is there a way to bring them back without rebooting the whole system? It would greatly mitigate the effects of this bug.

[Pinglinux]

Do you mean issuing "rmmod wacom" and "modprobe wacom" would not bring the tablet back? What do you see from dmesg after issuing those commands?

[EnderMk9]

[sáb sep 30 20:02:00 2023] wacom 0018:056A:52D1.0003: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.

It always says this line when it crashes

[sáb sep 30 20:02:28 2023] input: WACF2200:00 056A:52D1 Touchscreen as /devices/platform/AMDI0010:01/i2c-1/i2c-WACF2200:00/0018:056A:52D1.0003/input/input28
[sáb sep 30 20:02:28 2023] input: WACF2200:00 056A:52D1 as /devices/platform/AMDI0010:01/i2c-1/i2c-WACF2200:00/0018:056A:52D1.0003/input/input29
[sáb sep 30 20:02:28 2023] input: WACF2200:00 056A:52D1 Stylus as /devices/platform/AMDI0010:01/i2c-1/i2c-WACF2200:00/0018:056A:52D1.0003/input/input30
[sáb sep 30 20:02:28 2023] input: WACF2200:00 056A:52D1 as /devices/platform/AMDI0010:01/i2c-1/i2c-WACF2200:00/0018:056A:52D1.0003/input/input31
[sáb sep 30 20:02:28 2023] input: WACF2200:00 056A:52D1 Mouse as /devices/platform/AMDI0010:01/i2c-1/i2c-WACF2200:00/0018:056A:52D1.0003/input/input32
[sáb sep 30 20:02:28 2023] hid-generic 0018:056A:52D1.0003: input,hidraw1: I2C HID v1.00 Mouse [WACF2200:00 056A:52D1] on i2c-WACF2200:00

This is the output when I use rmmod

[sáb sep 30 20:03:53 2023] input: Wacom HID 52D1 Pen as /devices/platform/AMDI0010:01/i2c-1/i2c-WACF2200:00/0018:056A:52D1.0003/input/input33
[sáb sep 30 20:03:53 2023] input: Wacom HID 52D1 Finger as /devices/platform/AMDI0010:01/i2c-1/i2c-WACF2200:00/0018:056A:52D1.0003/input/input34
[sáb sep 30 20:03:53 2023] wacom 0018:056A:52D1.0003: hidraw1: I2C HID v1.00 Mouse [WACF2200:00 056A:52D1] on i2c-WACF2200:00

And this is the output when I use modprobe. Still does not work, not even the normal touchscreen

[nemuibanila]

I've made a discovery.

If I rmmod i2c_hid_acpi && modprobe i2c_hid_acpi after the pen froze, then it works again without issue. I have also been able to use it for an extended amount of time.

[EnderMk9]

Are you saying that after you rmod and modprobe i2c_hid_acpi (It's a miracle that we can get it at least working again without rebooting, thanks!) the pen worked for longer periods of time, or am I understanding it wrong?

[nemuibanila]

Yes, after booting it breaks after a few seconds of usage, but after I do that I can use it - so far I'm 10 minutes in - and it works fine.

[EnderMk9]

Thanks a lot! I'm gonna see if I can implement some script to automate it when it breaks. And we also know that what breaks is i2c_hid_acpi, not the wacom driver, @Pinglinux, is there any log we can share to see if there is any chance to fix it, or do we need to report it to the i2c_hid_acpi module developers?

[EnderMk9]

I've made this script that detects in real time the line that always appears in dmesg when it crashes and resets the i2c_hid_acpi driver automatically.

#!/usr/bin/env bash

dmesg -W | while read -r line; do
    if [[ $line == wacom_idleprox_timeout:\ tool\ appears\ to\ be\ hung\ in-prox.\ forcing\ it\ out. ]]; then
        rmmod i2c_hid_acpi && modprobe i2c_hid_acpi
        echo "i2c_hid_acpi RESET" + $(date +%s)
    fi
done

[sisxph]

here is a working version of the script.
Thanks EnderMk9 for the base idea.

#!/usr/bin/env bash
dmesg -W | while read -r line; do
	if [[ $line == *wacom_idleprox_timeout* ]]; then 
	 	modprobe -r --wait=100000 i2c_hid_acpi
	 	modprobe i2c_hid_acpi   
	fi
done