Huion Kamvas Pro 19

[vod3]

Hi, I'm very close on getting the device to 100% working, after I submitted a pull request to systemd:
systemd/systemd#31918 the pen was working, but the Multi-Touch Gesture abilities are still missing.
I assume it's because the resolution I submitted may be wrong, after all I got the value by trial and error.

In your documentation I read that you can get the exact value my using libinput measure touch-size, but my touchscreen seems to be not supported.

This device does not have the capabilities for size-based touch detection.
Details: Device does not have ABS_MT_TOUCH_MAJOR

Nevertheless the Pen works great (the 2nd and 3rd pen button however not), there is no offset on the screen, but I'm not sure how to debug the Touchpad Issue. The Touchpad seems to only work as a mouse cursor.

Any tips what I can do to get this device to 100%?
Thanks for your time!

---

• Device name:
  Huion Kamvas Pro 19
  https://www.huion.com/pen_display/KamvasPro/Kamvas-Pro-19.html

• Device model identifier:
  GT-1902

• libwacom version:
  1.25.0

• I understand that libwacom does affect whether the device works (see Troubleshooting)

• udevadm info output:
  udevadm.txt

• sysinfo issue in wacom-hid-descriptors:
  Huion Kamvas Pro 19 wacom-hid-descriptors#370

[whot]

This device does not have the capabilities for size-based touch detection.

This just means the device doesn't support touch sizes, i.e. the physical(-ish) size of the finger touch in addition to the usual position data. Most touchpads don't have that and it's only necessary for things like palm and thumb detection so it's not a big deal if it is missing.

libwacom doesn't have an effect on whether the tablet works, and has no effect on the touchpad part of the tablet. Best to file a libinput bug for that.

If your tablet works and it shows up in the control center, you can submit the .tablet file here as a PR and we can get it merged. Fixing the touch is luckily completely independent of that.

[vod3]

libwacom doesn't have an effect on whether the tablet works, and has no effect on the touchpad part of the tablet. Best to file a libinput bug for that.

I will be doing that 👍

If your tablet works and it shows up in the control center, you can submit the .tablet file here as a PR and we can get it merged. Fixing the touch is luckily completely independent of that.

I will but I think there is room for improvement. I studied the libwacom.stylus file in order to get the pen buttons to work, but I don't really understand how to correctly map them into the .tablet file. Huion gives you two pens, a slim one with 2 Buttons + Eraser and a thick one with 3 Buttons + Eraser.

This is a simmilar pen found in the file:

[0x40200]
# Cintiq Pro 2022
Name=Pro Pen 3
Group=cintiqpro2022
Buttons=3
Axes=Tilt;Pressure;Distance;
Type=General

It would be complete I guess with the addition of

PairedStylusIds=0xfffff;
EraserType=Invert

But I don't really know what PairedStylusIDs means and how to integrate it into the .tablet file.
Any documentaion on that?

[whot]

iirc the huion tablets don't have tool ids so you don't need a special stylus, you can use @generic or @generic-no-eraser stylus (depending whether you have an eraser button or not).

The main problem with those generic pens is that we can't detect ahead of time how many buttons they have because they usually don't provide enough information, so we get

might be worth running libinput debug-tablet (in the libinput git repo, not sure it's avaialble/installed by your distro) and check if the pen does send a tool id and/or serial number. If it does then we can add actual styli for this (though note #639 which will be a problem).

a slim one with 2 Buttons + Eraser and a thick one with 3 Buttons + Eraser

To clarify: none of these counted buttons are the eraser button, right? so you have eraser (at the tip? as a button?) and in addition you have 2 or 3 buttons?

[vod3]

This is the pen and the button names I get from libinput debug-tablet

If I use the pen to hover, press the screen, press the first and second button, the Tool IDs I get are pen serial 0, id 0

If I use the 3rd button and the eraser at the end of the pen, I get eraser serial 0, id 0

[whot]

how curious. ftr, this means you have an eraser button and an eraser tip. that's a new one...

the stylus has 2 real buttons but instead of BTN_TOUCH (the "tip is down" signal) this should be BTN_STYLUS2). For the archives: udev-hid-bpf!59 attempts to fix this and turns those into three real buttons and an eraser tip.

Based on the libinput record output in that pr the tool does not send a tool ID which means we cannot identify it reliably.

I think the right solution for libwacom would be to duplicate the 0xfffff and 0xffffe entries in libwacom.stylus with the next available IDs (0xffffc and 0xffffb) and name it General 3 Button Pen with three buttons, etc.). Then refer to @generic-3btn-with-eraser in your .tablet file and that should do the right thing in libwacom-list-local-devices. And then later in gnome once we add the three button generic image.

[eqkessel]

@vod3 sorry to necro, but I'm trying to get my Kamvas Pro 19 working. Can I get your .tablet file, or some direction on what else I need to do to get the tablet working? Some things I have tried:

• Tried generating sysinfo data and generating a tablet file as described in https://github.com/linuxwacom/wacom-hid-descriptors/blob/master/README.md, using the already open issue. Wasn't able to parse the data.
• Tried generating a .tablet file using https://github.com/JoseExposito/uclogic-libwacom-tablet-descriptions, linked in other Huion .tablet files in the descriptors repo. With tweaks to download the newest drivers it produced an output file, but it didn't work.
• Modified the file produced above to include usb|256c|006b in the DeviceMatch field. This causes the device to now appear to libwacom-list-local-devices, but it still doesn't appear to the xsetwacom driver to be configured.

[whot]

I'm trying to get my Kamvas Pro 19 working

fwiw, libwacom is a static database only, it won't make your device work. You'll probably need to add it to the DIGImend drivers so it's actually handled by the kernel and the rest of the user stack. getting it working in libwacom just gives you niceties like the device showing up in the gnome control center and whatnot.

[eqkessel]

I think it's basically guaranteed that I have some misunderstanding of how this whole driver stack works, but I have another Huion tablet (Kamvas 24 Pro, GT2401, I'm trialing the two to decide which one to keep) that is, presumably, using the linux-wacom driver. It actually worked out-of-the-box on KDE Plasma once detected by the Wacom Tablet Finder utility (which just wraps xsetwacom). The Kamvas 24 Pro is listed in the output of libwacom-list-devices but isn't listed as supported on the Digimend site, so I assume it's working through the Wacom driver. I was guessing from that it was just a matter of adapting the configs for the tablet to detect the Kamvas Pro 19 model and underlying driver code would be there; after all the input-wacom driver itself doesn't seem to have code specific to many different tablets. I could easily be very wrong about that. Maybe there's some good documentation out there that explains how this all works, before this conversation gets too off topic?

[whot]

I think it's basically guaranteed that I have some misunderstanding of how this whole driver stack works

• input-wacom: backports of the kernel driver for wacom devices. not usually needed if you're running a normal distro
• DIGImend: kernel drivers for most of Huion and other devices. Mostly upstreamed, but there are some that haven't been yet. DIGImend is the likely candidate for devices using the shared PIDs such as 006d. DIGImend is in maintenance mode, but will fix existing devices. New devices should most likely go into:
• udev-hid-bpf: repo for future drivers for tablets. Currently only supports the Huion Inspiroy 2S.

Once you have one of the above that handles your kernel, userspace will generally work with

• libinput: input stack for all general purpose Wayland compositors
• xf86-input-wacom: xorg driver for all tablets (ignore the name).
  • xsetwacom only lists devices shown by this driver
• xf86-input-libinput: same but uses libinput underneath, generally recommended to use xf86-input-wacom for tablets for better backwards compat

Other pieces

• libwacom: static information about various devices, mostly used by libinput to configure things like the right capabilities ("does this tool have tilt?") and by e.g. GNOME settings to configure things ("Is this an external or integrated tablet?"). libwacom doesn't make your device work but it may make it show up in various GUIs.

if xsetwacom shows the device that means xf86-input-wacom is handling it which means the kernel is handling it. Anything incorrect (e.g. wrong coords or something) will need a kernel fix (or bpf in the case of udev-hid-bpf).

[vod3]

@eqkessel
Hi, the most important part for the Kamvas 19 is the patch I added for udev hwdb in systemd: systemd/systemd#32096
You can read more about it here: https://wayland.freedesktop.org/libinput/doc/latest/tablet-debugging.html
For the Kamvas the resolution is missing, which the patch adds.

After that, take a look at https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/59 for fixing the button mapping.

With those steps, you get the tablet 100% working

[whot]

For the Kamvas the resolution is missing, which the patch adds.

ftr libinput 1.26 assumes a default resolution for huion devices so this patch is useful but no longer mandatory to make the tablet work. The default resolution is off (since it'll apply to all huion devices without resolution) but it's better than not having the tablet work.

[whot]

@vod3 Going through the tablet files in current master, it looks like the kamvas 19 still has the autogenerated tablet file and it's not using the right PID match (which seems to be 006b). Do you mind sending a PR correcting that file so libwacom DTRT for this device? Thanks.

[whot]

Looks like this is resolved? I think we're still missing the manual update of the tablet file which would be a nice-to-have but meanwhile I think we can close this bug.

/close