How to improve experience with a partially supported pen display

Help
, ,
1

Hi all. I recently purchased a Huion Kamvas 16 gen3. On Fedora with KDE, this pen display is detected without any software needing to be installed. Through the existing settings module, I can map the pen input to the pen display. However, it’s not fully supported: one of the pen’s buttons is not configurable, and though the other two are configurable, changing the settings doesn’t appear to do anything. The unconfigurable button has its default behaviour (selecting the Eraser) working in Krita, while the others do nothing no matter what I select.

The tablet’s buttons and dials are completely unconfigurable; there is no option under “Drawing Tablet” to change them. The buttons are set up by default to send some slightly weird key combinations (wtf is Ctrl+Alt+Z supposed to be for, Huion?) so these can at least be listened for in a specialist app like Krita. The dials however do not do anything, and I would very much like to map them.

Beyond getting the tablet fully working, I would very much like there to be a resource where people like me can go to work out where the problem is, as there are several layers:

  1. At the driver level, the signals the device is sending need to be picked up
  2. Also at the driver level, these need to be made available to user-land software in a manner it can recognise
  3. At the application level, these signals need to be interpreted correctly
  4. At the config level (like in KDE settings) these signals need to be intercepted correctly to enable customisation

The tablet presents itself as 4 separate devices, which complicates matters. Listening to each of these with evtest reveals that at some level the raw input of all of the functionality of the device is making it to the OS: the dials send events, as do all the buttons on the tablet and the pen. The dials are under a different device than the buttons.

Clearly this is not enough for Krita to understand the inputs; I wonder if it simply doesn’t know to monitor the dial device. And the evtest testing indicates that at least one of the pen button presses is sent in a strange way: it registers as a BTN_TOUCH event with the same values as if I had tapped the pen on the tablet, but preceded by an MSC_SCAN event with a different value.

I tried to work around all of this using input-remapper but with no real success. I was able to remap one of the non-working pen buttons, but not the MSC_SCAN, BTN_TOUCH one. And input-remapper receives no events at all when I try to record stuff with the dials, so that’s a non-starter. I suspect something is going wrong at step 2 above - the information is there in the driver and raw data, but not presented in a way that anything knows to listen for it.

There are two other possibilities to look at: there is a proprietary driver from Huion. I tried it, but for some reason it didn’t correctly map the tablet surface: the bottom right of the tablet mapped to its centre. Changing the remapping settings resulted in slightly different breakage, but nothing made it usable, so that was a non-starter

Then there is OpenTabletDriver. Unfortunately it does not have support for this recent model of tablet, and in any case there is a years-old PR on their github to add support for wheels/dials that doesn’t seem to be going anywhere fast.

I can code so can try to contribute somewhere, but I don’t know where the problem lies so I don’t know where to target my efforts. What I’m really looking for is advice on how to work out where these events are getting lost so I can target that point for support, workarounds, or coding work. Thanks!

2

Hello! Let me try to reply to this in pieces:

There is no plan to support at any level devices in this “compatibility” mode. Devices like HUION do this because there’s no host driver running on your machine, it’s basically a fallback. And as you correctly figured out, it splits itself into numerous devices of which the most interesting ones send keyboard events. We don’t plan to support this (nor can I give support) because it’s super complex and devices already do weird thing even when they work normally. If our keyboard KCM ever supports arbitrary keyboard remapping, I guess you could do it there.

The KCM is only going to support tablet devices that report themselves as such, and in order to do that you either:

  • Need support in the kernel
  • Need a user-space driver

And unfortunately it looks like you already exhausted your options :frowning:

When you tried this, did you have multiple screens? If you do, make sure to change our remapping settings in our KCM to span all screens otherwise the driver malfunctions like yours did. If this isn’t applicable though, please ignore!

Krita only understands two kinds of inputs on desktop: key presses and mouse buttons. If it isn’t either of those two things, I’m afraid you’re out of luck.

3

OK, that’s very interesting. With the tablet almost working, I was expecting to basically be able to get to full functionality running just with built-in HID drivers. I’m wondering if there is a way to detect such compatibility-mode and warn about it.

When you tried this, did you have multiple screens? If you do, make sure to change our remapping settings in our KCM to span all screens otherwise the driver malfunctions like yours did. If this isn’t applicable though, please ignore!

I did… assuming I reinstall the driver I’ll check that out. I don’t remember a way to span all screens though, only options for a specific screen or the “current screen”.

Krita only understands two kinds of inputs on desktop: key presses and mouse buttons. If it isn’t either of those two things, I’m afraid you’re out of luck.

I mean dial events should be the same as mouse wheel events, right?

From some discussion elsewhere it seems that there are two layers to look at in the first instance:

  1. Kernel level: udev and such. This may be where we can get the dial and button devices to be interpreted by libinput as part of the tablet?
  2. Driver level, but in order to work, a userland driver like OTD still needs to ultimately create libinput devices. I don’t know if a kernel land driver needs to do this as well or not.

Thanks for the answers you have given - they may well be practical.

I’m wondering, in this fragmented world where things happen in: udev, uinput, evdev, libinput, one of three different drivers (usbhid, proprietary, OTD), and one of any number of compositors, how we can make it easier for people with a bit of knowledge to get themselves to the appropriate place to get help or to make their skills useful.

1 Like
4

It’s on my todo list to improve the KCM experience in that way yes. I don’t think there’s an easy way to detect said mode, but it should be smarter e.g. not hiding the Pad tab completely.

Correct, libinput is a very small part in making a tablet work. It basically makes it easier for applications like KWin to parse events, in short. (It does some post-processing and other quirks for devices, but that depends on the device.)

Libinput exposes already existent devices, there isn’t a “libinput device” without a real, kernel device. All user-space drivers go through the uinput system for virtual devices, for example.

It’s not as fragmented as you might think, these technologies aren’t “competing”. udev tells us what devices are, evdev is the actual event stream, and libinput is an abstraction on those concepts (because kernel APIs are frightening :smiley: ) you are correct that it’s daunting at first though!

5

I guess I’d talk about vertical and horizontal fragmentation. Both complicate the life of someone wanting to get help or contribute, but probably only horizontal really constitutes fragmentation per se.

By these I mean, respectively, the many layers involved - where the difficulty is in knowing to which forum to go; and the different options as far as drivers and compositors go - where the difficulty is in knowing which option is best and that any contribution has less impact because not everyone will be using it.