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

[Tenchrio]

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).

You sir are a life saver.
Some details to make it easier to follow for people in the future (I am new to Bazzite but not Linux, but detailed instructions never hurt). To uninstall the Open Tablet driver (at least in Bazzite):

1. Run sudo systemctl stop arch-opentabletdriver.service to be sure it has stopped
2. distrobox enter arch
3. distrobox-export --app otd-gui --delete
4. paru --remove opentablet driver
   Then exit to exit the distrobox.

Ensure hid_uclogic is running lsmod | grep uclogic, if that returns nothing sudo modprobe hid_uclogic.
Also if that returns nothing check 'ls /etc/modprobe.d/ if it has a file with a name containing hid_uclogic, if so delete that specific file with rm. Not sure if that undoes --append=modprobe.blacklist=hid_uclogic as it wouldn't work for me with rmmod so if necessary/possible someone correct me on this.

Now to overwrite the opentablet udev rules.

1. find the vendor:device id by running lsusb (for my Kamvas 16 and it seems a lot of other Kamvas models this was 256c:006d)
2. Copy the udev rules file to /etc/udev/rules.d with
   sudo cp /usr/lib/udev/rules.d/71-opentabletdriver-ublue.rules /etc/udev/rules.d/
3. Edit with sudo vim /etc/udev/rules.d/71-opentabletdriver-ublue.rules and look for your vendor id, you can use / followed by your vendorid then the 2 characters .* followed by the deviceid to search for it in vim, for example for the Kamvas 16 I would use /265c.*006d, the combinations are shared across multiple devices so the comment above might not directly reference your device but it will be using those rules (for me it said "HUION RTM-500" but way further up it mentions the Kamvas 16).
4. Change the ENV{LIBINPUT_IGNORE_DEVICE}="1" to ENV{LIBINPUT_IGNORE_DEVICE}="0"
5. Restart your system and watch the Huion tablet and pen now be listed in the System Settings > Drawing Tablet

Someone on the discord managed to get it running under the opentablet driver by blacklisting hid_uclogic with rmmod, but that didn't seem to work for me. However it is possible they used the flatpak version instead of the distrobox one that is installed by Bazzite when using bazzite-portal. Regardless I agree with @ethanjli in that I have a preference for the regular KDE settings integration and would argue in favor of the udev rules to be set up so it works in this manner by default.

[ethanjli]

Last week I had to install my custom OS image onto a new SSD because my previous SSD suddenly failed, and through that process I confirmed that on F41 all I needed to do on a fresh OS install for my Kamvas 13 tablet to show up in the Plasma Settings was override the opentablet udev rules. It is now part of my custom image build workflow:

• Containerfile: https://github.com/ethanjli/lutho-os/blob/638921fd5463ceaabf2d6e3ce11cce40b336b0f6/Containerfile#L11
• udev rule override: https://github.com/ethanjli/lutho-os/blob/638921fd5463ceaabf2d6e3ce11cce40b336b0f6/72-opentabletdriver-disable.rules (strictly speaking, I probably only need to include the last line of the file)

[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).

You sir are a life saver. Some details to make it easier to follow for people in the future (I am new to Bazzite but not Linux, but detailed instructions never hurt). To uninstall the Open Tablet driver (at least in Bazzite):

1. Run sudo systemctl stop arch-opentabletdriver.service to be sure it has stopped
2. distrobox enter arch
3. distrobox-export --app otd-gui --delete
4. paru --remove opentablet driver
   Then exit to exit the distrobox.

Ensure hid_uclogic is running lsmod | grep uclogic, if that returns nothing sudo modprobe hid_uclogic. Also if that returns nothing check 'ls /etc/modprobe.d/ if it has a file with a name containing hid_uclogic, if so delete that specific file with rm. Not sure if that undoes --append=modprobe.blacklist=hid_uclogic as it wouldn't work for me with rmmod so if necessary/possible someone correct me on this.

Now to overwrite the opentablet udev rules.

1. find the vendor:device id by running lsusb (for my Kamvas 16 and it seems a lot of other Kamvas models this was 256c:006d)
2. Copy the udev rules file to /etc/udev/rules.d with
   sudo cp /usr/lib/udev/rules.d/71-opentabletdriver-ublue.rules /etc/udev/rules.d/
3. Edit with sudo vim /etc/udev/rules.d/71-opentabletdriver-ublue.rules and look for your vendor id, you can use / followed by your vendorid then the 2 characters .* followed by the deviceid to search for it in vim, for example for the Kamvas 16 I would use /265c.*006d, the combinations are shared across multiple devices so the comment above might not directly reference your device but it will be using those rules (for me it said "HUION RTM-500" but way further up it mentions the Kamvas 16).
4. Change the ENV{LIBINPUT_IGNORE_DEVICE}="1" to ENV{LIBINPUT_IGNORE_DEVICE}="0"
5. Restart your system and watch the Huion tablet and pen now be listed in the System Settings > Drawing Tablet

Someone on the discord managed to get it running under the opentablet driver by blacklisting hid_uclogic with rmmod, but that didn't seem to work for me. However it is possible they used the flatpak version instead of the distrobox one that is installed by Bazzite when using bazzite-portal. Regardless I agree with @ethanjli in that I have a preference for the regular KDE settings integration and would argue in favor of the udev rules to be set up so it works in this manner by default.

The reason its set up with the OTD driver rules is because originally the kde and gnome settings did not support the tablet (there is still many they do not support)
Hence the need for OTD.

the change needed to the udev rules (for tablets that no longer need OTD) however can be PRed into the repository, not quite sure which one. im sure @KyleGospo would know which as i couldnt find it at first glance with a search before going to work.