Huion tablets not working in ublue images, while Fedora's images work

[Potajito]

Hi!
Huion tablets are not working on ublue images:

Bazzite KDE: Not working
Bazzite Gnome: tablet shows up but pen doesn't work, so I'd consider it now working
Aurora: Not working
Kinoite Ublue: Not working (rebased from fedora kinoite, where it was working previously)

While on non ublue images (tested Fedora Workstation Gnome non atomic, Fedora KDE non atomic, Fedora Kinoite) it works out of the box.
All tests on wayland, just plain default out of the box.

There are a couple of things that are puzzling. First we thought this had to do with a not up to date libwacom package, currently bazzite uses 2.11.0, while latest is 2.12.2, and changelog shows some work on Huion tablets, but this was not it, as I downgraded my working arch installation package to 2.11 and it kept working.

Another thing worth mentioning is how KDE shows the Drawing tablet interface. When the tablet is unplugged, but "it's going to work" when plugged, it shows this interface:

Meanwhile, when it's unplugged but "it's not going to work" when plugged, it shows this:

You can find our discussion over here https://discord.com/channels/1072614816579063828/1268470456441110568 tagging @HikariKnight as they have followed the discussion and is aware of the issue.

Possible culprit could be something to do with libinput and its interactions with libwacom/libwacom-data. For example, libinput list-devices doesn't list the tablet in the affected images.

Please also note that this seems to be happening on some tablets (me and another user reported the issue with huion), but Hikari's wacom works fine out of the box.

I'd say those are all our findings. Let me know if you can think of anything else I can test/help with.
Cheers!

[m2Giles]

Did we include the libwacom surface packages on main images? If so I wonder if this is conflicting here.

[safonas]

Happy to help with this. I'm currently using Flatpak version of OpenTabletDriver, but it would be nice if these tablets worked out of the box.
Device info - https://paste.centos.org/view/5697c3a8
Logs when connecting the tablet on Wayland Gnome session - journal.log
Tablet model Huion H950P.
It is recognized by Gnome Settings, but no input is registered

@m2Giles it seems like no, libwacom-surface is included only if kernel flavor is "surface", see https://github.com/search?q=org%3Aublue-os+libwacom-surface&type=code . I'm on bluefin-nvidia generic laptop version.

[EDIT]
Adding previous discussion which led me to use OTD - https://universal-blue.discourse.group/t/my-huion-tablet-is-not-being-detected-on-kinoite-nvidia-custom-image/786/16

Any ideas what may be stopping it working? Input remapper seems suspicious to me

[HikariKnight]

@safonas Ideally we would be using the opentabletdriver flatpak as it will let us avoid having to rely on a distrobox for this.
sadly not all tablets are supported by default by the kernel modules hence why a userspace driver like opentabletdriver is necessary for a lot of them.

@Potajito can you check if the flatpak version of opentabletdriver works with the tablet in question.

PS: sorry for it taking so long for me to get to this issue, been recovering from my hospitalization up until now.

[jfml]

O no, hope you're all better? Taking time off to recover is important ✨

I rebased in to Bazzite again for a hot second, was hoping that it might work out of the box now with the cool new tablet features from Plasma 6.2, but no cake, unfortunately.

Open Tablet Driver (Flatpak, I think) did recognise my tablet now (no idea why), but I could not get it to work. The cursor (sometimes multiple of them) where nowhere near the pen, the mapping is super weird. I rebased to Kinoite for the time being again where it keeps on working out of the box like a charm (fingers crossed) …

Why would you need to use Distrobox for supporting the tablet in Bazzite when it works without it on Kinoite for some reason?

I could rebase to Bazzite again at some point if you want me to try out some things.

[HikariKnight]

we have been installing opentabletdriver inside distrobox since its a userspace driver and covers tablets that the kernel drivers do not cover, that is why.
Bit unsure how we can start figure out where the difference is since i have 0 affected hardware to test with.

PS: much better now, have not wanted to sit down and focus on anything while i was recovering due to lack of energy.

[jfml]

Mmmh, ok, if you can think of something I'd be happy to test stuff out. I'm glad that you're doing better ^__^

[ethanjli]

Not sure if my experience would be directly useful, but I thought I'd share some notes here since I have affected hardware, even if the underlying causes might be different for me:

• I have a Huion Kamvas 13 which I use with a laptop running a custom image based on aurora-dx:stable (which as of right now is on F40 with KDE Plasma 6.2).
• I used to use it with OpenTabletDriver installed via rpm-ostree in a custom image. I had to set some very wild numbers in the OpenTabletDriver manual calibration/remapping of the stylus's input range to the display in order to make it usable.
• Around 10 days ago, I did a reboot of my laptop and I stopped being able to get OpenTabletDriver to correctly detect my tablet - when I tried to make OTD detect the tablet, the tablet would go into a several-cycle reset loop and OTD would report permissions errors accessing /dev/hidraw* (even though, after following OTD's troubleshooting instructions, all those devices show up with +rw perms for owner & group & other). I tried replacing the rpm-ostree package with the Flatpak, but both had the same problem. I eventually gave up on trying to make OTD work again, and instead decided to try to make KDE Plasma's tablet support work.
• I was able to get KDE Plasma to detect my tablet by 1) ensuring that the wacom and uclogic kernel modules were loaded and not blacklisted; 2) adding a .tablet file in /usr/share/libwacom based on https://github.com/linuxwacom/libwacom/blob/master/data/huion-kamvas-13.tablet , since the version of that file provided by libwacom in F40 is older and not comprehensive enough to detect my tablet; and then 3) adding a udev rule in /etc/udev/rules.d to override the OTD-related udev rules (at /usr/lib/udev/rules.d/71-opentabletdriver-ublue.rules, which normally sets LIBINPUT_IGNORE_DEVICE to 1) to instead set LIBINPUT_IGNORE_DEVICE to 0 so that libinput would stop ignoring my model of tablet. I am sure that step 3 was necessary; I'm not sure if step 1 was necessary, but I tried it first in order to completely undo the things needed for OpenTabletDriver which I suspected might interfere with KDE Plasma's tablet support; and I'm not sure if step 2 was necessary, but making my tablet show up in libwacom-list-local-devices was at least useful for troubleshooting.
• The UX on KDE Plasma is much better than with OTD - everything "Just works" without any manual calibration/remapping needed, and now I can even have the stylus move the cursor in whichever display currently has the cursor (which is something I could not achieve on OTD).

[jfml]

@ethanjli Oh, that's so interesting! I'll give that a try if I can find the time. I'm not sure I understand step one: sudo rmmod wacom hid_uclogic from the OTD wiki you linked removes the kernel module (or am I mistaken?), how do you check that they are present / loaded?

(I also prefer Plasma's tablet settings over OTD, it would be cool if it worked with that on Bazzite).

[ethanjli]

To check whether those two kernel modules are loaded, you can do something like lsmod | grep hid_uclogic (or the equivalent for wacom). I believe the two ways to disable them (to make OTD work) are 1) to add some kernel arguments (e.g. via sudo rpm-ostree kargs --editor) or 2) to blacklist them via drop-in config files in /etc/modprobe.d - so if you had previously disabled them somehow and you want to un-disable them, then you would need to undo any changes made in either of those two ways for hid_uclogic and wacom.

Note: I just ran lsmod to check the state of the wacom and hid_uclogic kernel modules (with my Huion tablet connected and working), and it appears that the wacom kernel module is not loaded for me, while the hid_uclogic kernel module is loaded for me. So the wacom kernel module might not be necessary for you.

[HikariKnight]

Not sure if my experience would be directly useful, but I thought I'd share some notes here since I have affected hardware, even if the underlying causes might be different for me:

• I have a Huion Kamvas 13 which I use with a laptop running a custom image based on aurora-dx:stable (which as of right now is on F40 with KDE Plasma 6.2).
• I used to use it with OpenTabletDriver installed via rpm-ostree in a custom image. I had to set some very wild numbers in the OpenTabletDriver manual calibration/remapping of the stylus's input range to the display in order to make it usable.
• Around 10 days ago, I did a reboot of my laptop and I stopped being able to get OpenTabletDriver to correctly detect my tablet - when I tried to make OTD detect the tablet, the tablet would go into a several-cycle reset loop and OTD would report permissions errors accessing /dev/hidraw* (even though, after following OTD's troubleshooting instructions, all those devices show up with +rw perms for owner & group & other). I tried replacing the rpm-ostree package with the Flatpak, but both had the same problem. I eventually gave up on trying to make OTD work again, and instead decided to try to make KDE Plasma's tablet support work.
• I was able to get KDE Plasma to detect my tablet by 1) ensuring that the wacom and uclogic kernel modules were loaded and not blacklisted; 2) adding a .tablet file in /usr/share/libwacom based on https://github.com/linuxwacom/libwacom/blob/master/data/huion-kamvas-13.tablet , since the version of that file provided by libwacom in F40 is older and not comprehensive enough to detect my tablet; and then 3) adding a udev rule in /etc/udev/rules.d to override the OTD-related udev rules (at /usr/lib/udev/rules.d/71-opentabletdriver-ublue.rules, which normally sets LIBINPUT_IGNORE_DEVICE to 1) to instead set LIBINPUT_IGNORE_DEVICE to 0 so that libinput would stop ignoring my model of tablet. I am sure that step 3 was necessary; I'm not sure if step 1 was necessary, but I tried it first in order to completely undo the things needed for OpenTabletDriver which I suspected might interfere with KDE Plasma's tablet support; and I'm not sure if step 2 was necessary, but making my tablet show up in libwacom-list-local-devices was at least useful for troubleshooting.
• The UX on KDE Plasma is much better than with OTD - everything "Just works" without any manual calibration/remapping needed, and now I can even have the stylus move the cursor in whichever display currently has the cursor (which is something I could not achieve on OTD).

This is lots of useful information and i believe all of this can be tested using sudo rpm-ostree usroverlay
which will make /usr writable until reboot and then once you reboot the changes to /usr will be removed