input-wacom
input-wacom copied to clipboard
linuxwacom
wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
Hi, I have a problem which appears closely related to https://github.com/linuxwacom/input-wacom/issues/262 and https://github.com/linuxwacom/input-wacom/issues/288.
I have an X1 yoga, gen 5, Ubuntu 22.04 (with kernel5.15.0-58-generic), using a Wacom Bamboo Ink-Active Stylus (2nd gen). The stylus worked fine until about a few months ago, presumably due to a kernel update. I get pen skipping issues as in the bug reports above and my log is filled up with entries "wacom_wac_queue_insert: kfifo has filled, starting to drop events". The issue persists if I use a colleague's identical stylus. So I downloaded the latest input-wacom source (0.49) and installed it as instructed. The issue persists, my stylus is unusable but now I get errors "wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out." I also get log entries from Xorg "(II) UnloadModule: "wacom""
The correct wacom module seems to be in use however. E.g. jono$ modinfo wacom | grep version version: v2.00-0.49.0 srcversion: FCBEF11CCBF842A7DD448CE vermagic: 5.15.0-58-generic SMP mod_unload modversions
or for the debug 288 fix which I also tried: version: v2.00-0.42.0.216.g24e94f2 srcversion: F718216190788EA377F92E5 vermagic: 5.15.0-58-generic SMP mod_unload modversions if I use the debug fix for 288 I get:
One issue is that when I compile the drivers, I need to sign the module with my registered MOK key, which I do, but I still get some ssl errors. I compile the modules using
if test -x ./autogen.sh; then ./autogen.sh --with-signing-key=/var/lib/shim-signed/mok/MOK.priv --with-signing-cert=/var/lib/shim-signed/mok/MOK.der ; else ./configure --with-signing-key=/var/lib/shim-signed/mok/MOK.priv --with-signing-cert=/var/lib/shim-signed/mok/MOK.der; fi && make && sudo make install || echo "Build Failed"
but get errors:
Making install in 4.5 make[1]: Entering directory '/home/jono/src/input-wacom-0.49.0/4.5' make -C /lib/modules/5.15.0-58-generic/build M=/home/jono/src/input-wacom-0.49.0/4.5 modules_install mod_sign_cmd='"/lib/modules/5.15.0-58-generic/build/scripts/sign-file" "sha512" "/var/lib/shim-signed/mok/MOK.priv" "/var/lib/shim-signed/mok/MOK.der"' make[2]: Entering directory '/usr/src/linux-headers-5.15.0-58-generic' arch/x86/Makefile:142: CONFIG_X86_X32 enabled but no binutils support INSTALL /lib/modules/5.15.0-58-generic/extra/wacom.ko SIGN /lib/modules/5.15.0-58-generic/extra/wacom.ko At main.c:160:
- SSL error:FFFFFFFF80000002:system library::No such file or directory: ../crypto/bio/bss_file.c:67
- SSL error:10000080:BIO routines::no such file: ../crypto/bio/bss_file.c:75 sign-file: certs/signing_key.pem: No such file or directory INSTALL /lib/modules/5.15.0-58-generic/extra/wacom_i2c.ko SIGN /lib/modules/5.15.0-58-generic/extra/wacom_i2c.ko At main.c:160:
- SSL error:FFFFFFFF80000002:system library::No such file or directory: ../crypto/bio/bss_file.c:67
- SSL error:10000080:BIO routines::no such file: ../crypto/bio/bss_file.c:75 sign-file: certs/signing_key.pem: No such file or directory INSTALL /lib/modules/5.15.0-58-generic/extra/wacom_w8001.ko SIGN /lib/modules/5.15.0-58-generic/extra/wacom_w8001.ko At main.c:160:
- SSL error:FFFFFFFF80000002:system library::No such file or directory: ../crypto/bio/bss_file.c:67
- SSL error:10000080:BIO routines::no such file: ../crypto/bio/bss_file.c:75 sign-file: certs/signing_key.pem: No such file or directory DEPMOD /lib/modules/5.15.0-58-generic Warning: modules_install: missing 'System.map' file. Skipping depmod.
I did manage to successfully enroll the MOK key, and sign the module via sudo kmodsign sha512 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der /lib/modules/$(uname -r)/extra/wacom.ko, but maybe I need to be using a different key pair?
Thanks! Jonathan
I heard issues about kernel 5.15. Can you try another kernel to see if it resolves the issue? This project actually doesn't support Wacom Bamboo Stylus.
I am now using 6.2.0 and am still getting that error thousands of times (which might itself be part of the problem). It used to work just fine.
On Fri, 29 Sept 2023, 06:05 Ping Cheng, @.***> wrote:
I heard issues about kernel 5.15. Can you try another kernel to see if it resolves the issue? This project actually doesn't support Wacom Bamboo Stylus.
— Reply to this email directly, view it on GitHub https://github.com/linuxwacom/input-wacom/issues/342#issuecomment-1740001543, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEB5EBK22ETLLCJ6CPPA6C3X4XQ73ANCNFSM6AAAAAAUC4O46I . You are receiving this because you authored the thread.Message ID: @.***>
$ xinput --list-props 10 Device 'Wacom Pen and multitouch sensor Pen stylus': Device Enabled (188): 1 Coordinate Transformation Matrix (190): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (320): 0 Device Accel Constant Deceleration (321): 1.000000 Device Accel Adaptive Deceleration (322): 1.000000 Device Accel Velocity Scaling (323): 10.000000 Device Node (317): "/dev/input/event8" Wacom Tablet Area (327): 0, 0, 30931, 17399 Wacom Rotation (328): 0 Wacom Pressurecurve (329): 0, 25, 75, 100 Wacom Serial IDs (330): 20922, -2128155530, 17, 0, 0 Wacom Serial ID binding (331): 0 Wacom Proximity Threshold (349): 30 Wacom Pressure Threshold (332): 26 Wacom Sample and Suppress (333): 2, 4 Wacom Enable Touch (334): 0 Wacom Hover Click (350): 1 Wacom Enable Touch Gesture (335): 0 Wacom Touch Gesture Parameters (336): 0, 0, 250 Wacom Tool Type (337): "STYLUS" (345) Wacom button action 0 (338): 1572865 Wacom button action 1 (339): 1572866 Wacom button action 2 (340): 1572867 Wacom button action 3 (341): 1572872 Wacom Button Actions (342): "Wacom button action 0" (338), "Wacom button action 1" (339), "Wacom button action 2" (340), "None" (0), "None" (0), "None" (0), "None" (0), "Wacom button action 3" (341) Wacom Pressure Recalibration (351): 1 Wacom Panscroll Threshold (343): 1300 Device Product ID (318): 1386, 20922 Wacom Debug Levels (344): 0, 0
This issue has been around for a while, but I don't believe that its root cause is a driver issue (meaning that it can be very difficult to "fix" from the driver). There are too many instances of the bug appearing and disappearing without any obvious change to the affected system; let alone changes that I would expect to influence this.
I'll follow-up on some of the wilder possibilities of what could be going wrong, however.
I've made four branches that disable various parts of the driver and am interested in knowing if any of them have any effect on the jumping issue. You'll first need to clone my repository as follows:
$ git clone https://github.com/jigpu/input-wacom.git
$ cd input-wacom
Next you'll need to check out one of the four test branches:
-
$ git checkout stylus-jump-A -
$ git checkout stylus-jump-B -
$ git checkout stylus-jump-C -
$ git checkout stylus-jump-D
Compile and install the code as per the wiki instructions and then reboot. Run cat /sys/module/wacom/version to verify what version of the driver is actually running. It should end with either g7e1c20e for A, g025759f for B, geaeb441 for C, or gd449720 for D. You can now use the modified driver for some time and see if it has any effect on the jumping behavior. If there doesn't seem to be any effect, try checking out the next branch and then repeat these steps again with it.
Thanks so much! I'll do that and report back. One other item which keeps appearing in my logs is "(**) Wacom Pen and multitouch sensor Pen eraser: (accel) acceleration threshold: 4", usually about 60 times. Here are my log entries at startup which mention "wacom".
I am also (only now) getting the following error relating to this bug: https://wayland.freedesktop.org/libinput/doc/1.20.0/touchpad-jumping-cursors.html
(EE) event11 - SYNA8007:00 06CB:CD8C Touchpad: kernel bug: Touch jump detected and discarded.
Okay, so far, stylus-jump-A seems to significantly improve the situation! Thanks! I have gone a few hours without any jumping, and only now it's starting to jump again, but it's milder jumping. I can no longer use the stylus, but at least it doesn't start wrecking havoc over the entire desktop as it was before.
When the jumping happens, I get log entries "(EE) Wacom Co.,Ltd. Pen and multitouch sensor Stylus eraser: usbParse: Ignoring event from invalid serial 0". Does that help indicate where the issue is?
I also noticed another entry in the logs: "libinput error: event21 - Wacom Co.,Ltd. Pen and multitouch sensor Mouse: libinput bug: missing tablet capabilities: pen btn-stylus resolution. Ignoring this device."
And I have older entries in the log (before the switch to stylus-jump-A): (EE) wacom: Wacom Co.,Ltd. Pen and multitouch sensor Mouse: Invalid type '(null)' for this device. (EE) wacom: Wacom Co.,Ltd. Pen and multitouch sensor Mouse: No type specified (EE) wacom: Wacom Co.,Ltd. Pen and multitouch sensor Mouse: No valid type found for this device. (EE) PreInit returned 8 for "Wacom Co.,Ltd. Pen and multitouch sensor"
I don't know if any of them help diagnose the issue. In the meantime, I'll now install stylus-jump-B and report back....
Okay, it seems like the really good behaviour was because the wacom driver had not even been loaded! Since it had been blocked by secure boot. Presumably libinput takes over and for some reason the cursor jumping doesn't happen nearly as much.
I then turned off secure-boot, and tried each of the wacom modules and confirmed that each had been loaded. They all seem to suffer from cursor jumping and so I can't use the stylus. But it seems the errors that get left in the log are different (although this may just be coincidence).
jump-A gives wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out. jump-B gives wacom_wac_queue_insert: kfifo has filled, starting to drop events jump-C gives wacom_wac_queue_insert: kfifo has filled, starting to drop events jump-D gives wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
This is so frustrating. A hard reset doesn't help. Even reverting to an older kernel 5.15 didn't work. Everything worked at some point....
I had the same problem on my ThinkPad L13 Yoga G2 on NixOS. After switching to the Zen Kernel, I still get this error sometimes in dmesg, but can't notice any stuttering in applications like xournalpp.
Okay, it seems like the really good behaviour was because the wacom driver had not even been loaded! Since it had been blocked by secure boot. Presumably libinput takes over and for some reason the cursor jumping doesn't happen nearly as much.
I then turned off secure-boot, and tried each of the wacom modules and confirmed that each had been loaded. They all seem to suffer from cursor jumping and so I can't use the stylus. But it seems the errors that get left in the log are different (although this may just be coincidence).
jump-A gives wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out. jump-B gives wacom_wac_queue_insert: kfifo has filled, starting to drop events jump-C gives wacom_wac_queue_insert: kfifo has filled, starting to drop events jump-D gives wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
This is so frustrating. A hard reset doesn't help. Even reverting to an older kernel 5.15 didn't work. Everything worked at some point....
Thank you @lejono for your testing and feedback. Your effort is greatly appreciated.
All of the branches were failed, which is not particularly surprising since they were all long-shot ideas. What we can tell based on the feedback is that neither "wacom_idleprox_timeout" nor "wacom_wac_pen_serial_enforce" are to blame for the jumping. This reinforces the fact that the AES devices just stopped sending events. The idleprox warning is only indicating the problem is not in the kernel driver.
Sorry for not getting back to you sooner. Jason and I were very busy with many other tasks. But we didn't forget you. Tats, another Wacom developer, came up with a new way to tackle the issue. He will share his patch with you soon. As you know, we do not have the device to work on, which made the troubleshooting and fixing process even more challenging.
Hello @lejono,
Thank you for your check for the patches, I'm afraid to say, but I'd like you to try another change1. This change resets the firmware and turns it into its initial state when "wacom_idleprox_timeout" is called.
Please Git-clone it, compile the source, and install it as the instruction states at 2. You can do the clone as you did for the previous patches. Please aware that the github address and the branch are different. Cloning can also be done like: $ git clone https://github.com/flying-elephant/input-wacom -b workaround_for_unexpected_pen_jumping The version is going to be "2.00-g0eacd1e-input-wacom" for this change. When the change successfully runs to reset, the debug messages are something like described at [3].
Again, thank you for your cooperation.
[3]: Vendor: 0x56a Addr: 0xa wacom_aes_reset succeeded size: 2 data[0]: 0x0 data1: 0x0
Hello @lejono,
Thank you for your check for the patches, I'm afraid to say, but I'd like you to try another change1. This change resets the firmware and turns it into its initial state when "wacom_idleprox_timeout" is called.
Please Git-clone it, compile the source, and install it as the instruction states at 2. You can do the clone as you did for the previous patches. Please aware that the github address and the branch are different. Cloning can also be done like: $ git clone https://github.com/flying-elephant/input-wacom -b workaround_for_unexpected_pen_jumping The version is going to be "2.00-g0eacd1e-input-wacom" for this change. When the change successfully runs to reset, the debug messages are something like described at [3].
Again, thank you for your cooperation.
[3]: Vendor: 0x56a Addr: 0xa wacom_aes_reset succeeded size: 2 data[0]: 0x0 data1: 0x0
Hope that this wouldn't be a problem. I have tested your patch and it is outputting as expected.
[ 49.802504] wacom 0018:056A:5285.0005: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
[ 49.802564] Vendor: 0x56a Addr: 0xa
[ 49.804884] wacom_aes_reset succeeded size: 2
[ 49.804889] data[0]: 0x0
[ 49.804890] data[1]: 0x0
On my end, I am running a Wacom 5285 on a Lenovo ThinkPad X13 Yoga Gen 3. The original behaviour I had was a lot of jumping in xournalapp. The patch does solve most of it, but in some cases the "cursor" still moves to where my hand is touching the display.
There is also a short delay in some occasions when I bring the pen in proximity (which was reported). I am willing to do more tests since I am using my stylus daily. Note that I will start using another AES 2.0 stylus which might be more suitable for writing, but I am current;y using a Lenovo Integrated Pen.
Hi @TipzRickyCheung
It is really thankful for you to have tested the patch and your feedback. Thanks! It sounds like the random jumping issue was almost gone.
The patch does solve most of it, but in some cases the "cursor" still moves to where my hand is touching the display. I assume that the pen moves to where your hand is held while you are in writing/drawing some things on some software application. Is my understanding correct? Also, I have a couple of the questions.
#1. Does the cursor move again to another position randomly after the position of the cursor is at your hand? #2. Would it be possible for you to check your kernel version ? Because we had an issue related to a palm rejection and the modification for it was merged to the latest kernel and the stable kernels.1 Would you like to check if your kernel is the equal or the greater than the theses below?
v6.8-rc1 v6.7.2 v6.6.14 v6.1.75 v5.15.148 v5.10.209 v5.4.268 v4.19.306
Hi @TipzRickyCheung
It is really thankful for you to have tested the patch and your feedback. Thanks! It sounds like the random jumping issue was almost gone.
The patch does solve most of it, but in some cases the "cursor" still moves to where my hand is touching the display. I assume that the pen moves to where your hand is held while you are in writing/drawing some things on some software application. Is my understanding correct? Also, I have a couple of the questions.
#1. Does the cursor move again to another position randomly after the position of the cursor is at your hand? #2. Would it be possible for you to check your kernel version ? Because we had an issue related to a palm rejection and the modification for it was merged to the latest kernel and the stable kernels.1 Would you like to check if your kernel is the equal or the greater than the theses below?
v6.8-rc1 v6.7.2 v6.6.14 v6.1.75 v5.15.148 v5.10.209 v5.4.268 v4.19.306
Hi,
Before I answer any of your questions, I have to note that I was testing with a failing nib. It was drawing without me touching the display. Now that I got it replaced, the issue as stated above was recreated.
- The way that the cursor moves is that when the pen is brought out of proximity in a certain way, it will create a line to where my hands are presently located. If it isn't touching the screen, it may jump up and down and could create random scribbles. However, these issues do not occur if my hands aren't touching the touchscreen.
I might also add that I hold pens in a weird way, and am wondering if that could block the signal from the pen. However, I found that if my hands are touching the screen, the issue always occurs. For that other issue, I would have to try the patch for longer to see what it is.
- I am on 6.8.2. Note that the source here would have to update the usage of strlncpy as it was removed recently.
A note on the jumping issue, it seems to be pen specific. I've got myself a HP Pro Pen with the patch @flying-elephant has sent and it works totally flawless without any of the above issues. The pen I was using was the Lenovo Integrated Pen and it is simply too small too write comfortably. Although this does not explain OP's issue with his Wacom pen.
I guess we need to wait for the OP to confirm whether the patch has solved the issue for him. I will still continue to do testing with the patch and report back. Send more patches for testing and I would try them out as soon as I can.
I might also add that I hold pens in a weird way, and am wondering if that could block the signal from the pen. However, I found that if my hands are touching the screen, the issue always occurs. For that other issue, I would have to try the patch for longer to see what it is.
From your description, it looks like your device supports both pen and touch (If you can move the system cursor by your finger, your system supports touch). I wonder what happens if you disable touch. If your system is on Xorg server, you can use xsetwacom to set touch off. If you are under Wayland, you'll need to go through a few steps to setup the udev rules [1]. It's not a user-friendly approach. But we don't have other ways to do it right now.
[1] https://askubuntu.com/questions/927022/how-can-i-disable-touchscreen-while-using-wayland
I might also add that I hold pens in a weird way, and am wondering if that could block the signal from the pen. However, I found that if my hands are touching the screen, the issue always occurs. For that other issue, I would have to try the patch for longer to see what it is.
From your description, it looks like your device supports both pen and touch (If you can move the system cursor by your finger, your system supports touch). I wonder what happens if you disable touch. If your system is on Xorg server, you can use xsetwacom to set touch off. If you are under Wayland, you'll need to go through a few steps to setup the udev rules [1]. It's not a user-friendly approach. But we don't have other ways to do it right now.
[1] https://askubuntu.com/questions/927022/how-can-i-disable-touchscreen-while-using-wayland
Hi,
Yes, I know about the issue and methods, and I have tried them before without much success.
OP's and my hardware supports touch and pen input too, all Yoga line of Lenovo laptops do.
A note that I have tested this patch on a new hardware: Yoga 7 14IAL7.
The pen will not be recognized when it is directly touching the display. This is the same with the patch provided by @flying-elephant.
Here are the logs in dmesg:
:00
[ 765.618140] wacom 0018:056A:52D3.0001: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
[ 765.618184] Vendor: 0x56a Addr: 0xa
[ 765.619074] wacom_aes_reset succeeded size: 2
[ 765.619079] data[0]: 0x0
[ 765.619081] data[1]: 0x0
[ 766.732987] wacom 0018:056A:52D3.0001: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
[ 766.733020] Vendor: 0x56a Addr: 0xa
[ 766.733853] wacom_aes_reset succeeded size: 2
[ 766.733858] data[0]: 0x0
[ 766.733859] data[1]: 0x0
[ 768.560027] wacom 0018:056A:52D3.0001: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
[ 768.560058] Vendor: 0x56a Addr: 0xa
[ 768.561080] wacom_aes_reset succeeded size: 2
[ 768.561085] data[0]: 0x0
[ 768.561087] data[1]: 0x0
[ 770.546168] wacom 0018:056A:52D3.0001: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
[ 770.546211] Vendor: 0x56a Addr: 0xa
[ 770.547447] wacom_aes_reset succeeded size: 2
[ 770.547465] data[0]: 0x0
[ 770.547471] data[1]: 0x0
[ 772.326983] wacom 0018:056A:52D3.0001: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
[ 772.327272] Vendor: 0x56a Addr: 0xa
[ 772.328165] wacom_aes_reset succeeded size: 2
[ 772.328170] data[0]: 0x0
[ 772.328172] data[1]: 0x0
[ 773.550995] wacom 0018:056A:52D3.0001: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
[ 773.551349] Vendor: 0x56a Addr: 0xa
[ 773.552272] wacom_aes_reset succeeded size: 2
[ 773.552284] data[0]: 0x0
[ 773.552288] data[1]: 0x0
[ 775.381977] wacom 0018:056A:52D3.0001: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
[ 775.382065] Vendor: 0x56a Addr: 0xa
[ 775.383240] wacom_aes_reset succeeded size: 2
[ 775.383246] data[0]: 0x0
[ 775.383247] data[1]: 0x0
[ 776.674090] wacom 0018:056A:52D3.0001: wacom_idleprox_timeout: tool appears to be hung in-prox. forcing it out.
[ 776.674123] Vendor: 0x56a Addr: 0xa
[ 776.675440] wacom_aes_reset succeeded size: 2
[ 776.675446] data[0]: 0x0
[ 776.675448] data[1]: 0x0
Sorry to have missed the last few messages. I just want to report, that in the end, my issue seems to have been a hardware fault. I installed Windows, and the jumping pen/touchscreen issue occurred in that context as well! It wasn't the pen itself (since I'd tried another pen, and the jumping occurred with stylus disabled), but presumably some other hardware issue.
Also, it appears that my device doesn't play well with pens that have that jumping action with the stylus tip. It just doesn't recognize it when it is pressed.
I have ordered Lenovo's Digital Pen 2 to test whether that it the problem fully. I found that by not allowing it to move the pen draws "fine".
@TipzRickyCheung Hi, thanks for sharing your test results. If possible, answering the question below could narrow down the problems.
The pen will not be recognized when it is directly touching the display. This is the same with the patch provided by @flying-elephant. Do you mean no reaction occurs when your pen tip is on the screen (when the tip button is pressed)?
Also, it appears that my device doesn't play well with pens that have that jumping action with the stylus tip. It just doesn't recognize it when it is pressed. It sounds like your pen jumps around while you are using the pen on screen and while it is hovering. So, the result of the patch is that you see a cursor jumping around the screen while your pen is in hovering. Is that correct?
I have ordered Lenovo's Digital Pen 2 to test whether that it the problem fully. I found that by not allowing it to move the pen draws "fine". Could you provide more detail? Is Lenovo's Digital Pen 2 working just fine/good?
Upon your overall testing, it sounds like the jumping issue still occurs even by applying the patch. If you could let us know more details, we might be able to try to see something else.
@TipzRickyCheung Hi, thanks for sharing your test results. If possible, answering the question below could narrow down the problems.
The pen will not be recognized when it is directly touching the display. This is the same with the patch provided by @flying-elephant. Do you mean no reaction occurs when your pen tip is on the screen (when the tip button is pressed)?
Also, it appears that my device doesn't play well with pens that have that jumping action with the stylus tip. It just doesn't recognize it when it is pressed. It sounds like your pen jumps around while you are using the pen on screen and while it is hovering. So, the result of the patch is that you see a cursor jumping around the screen while your pen is in hovering. Is that correct?
I have ordered Lenovo's Digital Pen 2 to test whether that it the problem fully. I found that by not allowing it to move the pen draws "fine". Could you provide more detail? Is Lenovo's Digital Pen 2 working just fine/good?
Upon your overall testing, it sounds like the jumping issue still occurs even by applying the patch. If you could let us know more details, we might be able to try to see something else.
Thanks for the reply. I have since received the Lenovo Digital Pen 2 for my Yoga 7, which solved all of the issue and does not cause this regression. Unfortunately, it seems like these wacom devices require a specific pen to function properly with this driver. I am currently unable to test under Windows to confirm whether this is a input-wacom issue or hardware incompatibility at this stage.
@TipzRickyCheung Thanks for your feedback. Since the device works under your particular situation -with your Lenovo Digital Pen 2- and the other report concluded the issue as a hardware fault, there is nothing we can do in the driver to fix it.
If you find the same problem specifically caused by the driver, please open another issue. Thanks!
@Pinglinux @flying-elephant It seems like the same issue is coming back with the pen after a while of use, especially after resume from sleep.
Unloading the module "wacom" and writing without it makes it work better than with the "wacom" kernel module, however, this disables multi-touch.
I will have t test whether modprobing again would be a temporary fix. If so, maybe a service for reloading the module after resume could be a good temporary fix for my particular system.
Edit 1: The issue appears even after reloading the module. For now, not loading "wacom" while writing with the AES pen is a fix for my system. But that disables multi-touch.
Yea, I am weirdly getting this error again as well, even though I'm now on another machine (Lenovo X1 yoga, gen 8). However, this time, it's very rare (while previously, it was constant).
Yea, I am weirdly getting this error again as well, even though I'm now on another machine (Lenovo X1 yoga, gen 8). However, this time, it's very rare (while previously, it was constant).
Can you confirm the stylus you are using? I am using a Lenovo Digital Pen 2.
Can you also try to rmmod wacom and write with a stylus without this kernel module in a notetaking app? I think it is best for confirming whether it is caused by the kernel module, and/or multitouch functionality of the touchscreen.
I am also having this issue on Lenovo L13 Yoga Gen 4 (intermittent but annoying). Unloading wacom fixes it (in xournal++), reloading breaks it again. Using Lenovo Integrated Pen WG11, brand new tablet and stylus. I haven't tested whether it's correlated with resuming from suspend. I'm going to try testing with a different stylus soon and will try to report back. Assuming it's the stylus I'll probably just buy a new one.
