Huion WH1409 v2 stops registering after the pen leaves proximity for the first time
mikesbytes opened this issue · comments
Hello,
Apologies if this is not the relevant place to file this issue but I'm not sure what exactly is causing the problem.
I have a Huion WH1409 v2. I have not used it in quite a while, but last time I used it, it worked fine (definitely less than a year ago).
Now, I am having an issue, where I can put the pen down, but as soon as I bring the pen back out of range of the tablet, it stops working. I can get another stroke out of it by unplugging and plugging it back in.
I can reproduce the behavior on multiple machines with kernel 5.18.15 under both Wayland with Sway and Xorg with LXQt. I have installed the digimend git dkms modules as well but same results. I tried on LTS kernel as well (5.15.something) but no luck.
When I plug in the tablet, I get the following dmesg output:
[Sun Jul 31 23:04:40 2022] input: HUION Huion Tablet as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb1/1-2/1-2:1.0/0003:256C:006E.0018/input/input60
[Sun Jul 31 23:04:40 2022] input: HUION Huion Tablet Pad as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb1/1-2/1-2:1.0/0003:256C:006E.0018/input/input61
[Sun Jul 31 23:04:40 2022] input: HUION Huion Tablet Touch Strip as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb1/1-2/1-2:1.0/0003:256C:006E.0018/input/input62
[Sun Jul 31 23:04:40 2022] input: HUION Huion Tablet Dial as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb1/1-2/1-2:1.0/0003:256C:006E.0018/input/input63
[Sun Jul 31 23:04:40 2022] uclogic 0003:256C:006E.0018: input,hiddev96,hidraw0: USB HID v1.11 Keypad [HUION Huion Tablet] on usb-0000:02:00.0-2/input0
Of note here is that my tablet does not have a dial or touch strip and I definitely did not used to see this come up. Maybe it is being detected as the wrong device?
What's really weird though is if I fire up libinput debug-events after the tablet drops out, it still registers events. If I fire it up before the tablet drops out, it stops registering events until I fire up a new instance of libinput debug-events
Is this a digimend problem? If not, can someone point me in the right direction? I can provide any other diagnostics if needed.
Okay I found a fun workaround for the time being. If I trigger the issue before I start up my WM while still in TTY, I can use the tablet fine. It seems like that first proximity exit triggers something that causes all processes reading the tablet input to stop receiving input. Subsequent processes are able to read fine, and the issue no longer occurs. This is further supported by it showing up again in a second run of libinput debug-events
Maybe that helps narrow down the issue.
Hello! I'm having the same problem, so I'd like to add some info too.
I have a Huion HS64 and have been using it for about a year. It worked correctly in both Ubuntu 18.04 and Xubuntu 20.04. I'm on Fedora now (switched in early July) and have been facing the exact issue described.
libinput debug-events also displays all the pen events, but xinput displays exactly what we see (that is, it stops registering events after I take out the pen). It doesn't show up on xsetwacom list.
I tested it both with the drivers that come with the kernel and digimend/10, which is what I used in Ubuntu. The behavior is the same for both.
I tried adding the 50-tablet.conf to /etc/X11/xorg.conf.d (I'm on Xfce, so using X11), and X11 refused to start while it was there, no matter what configs I put into the file (I tried forcing the tablet to use the wacom/evdev drivers).
However, I installed the 5.4 kernel (which is what Ubuntu 20.04 uses as LTS kernel) and the pen worked correctly! So this may be a kernel-related regression.
Edit: there is a similar bug reported in the kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216106
Update: managed to make it work by using the wacom driver, following this guide: https://blog.simos.info/how-to-setup-the-huion-430p-drawing-tablet-on-ubuntu-20-04/
I also found out the device id for HS64 is 0x006d instead of 0x006e, but I don't know if that's related.
Hi!
This is a kernel regression. That's why even with the same DIGImend version installed, you see this problem in newer kernels.
It was reported 2 weeks ago in the kernel mailing list:
https://lore.kernel.org/linux-input/20220725224841.GA75640@elementary/
We found the code that introduced the issue, and, hopefully, it'll be fixed soon.
Hi again,
The problem is now solved. In case you want to compile your own kernel with the fix, here is the patch that fixes this issue:
https://lore.kernel.org/linux-input/20220822062247.1146141-1-benjamin.tissoires@redhat.com/T/#u
Confirmed working in 5.19. Thanks!
Was it already merged into kernel and released?
@wojpawlik Not sure of an easy way to check but given that this particular issue stopped occurring, I assume it has.
Fixed in 5.19.7: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.7.