If libinput list-devices does *not* list the tablet buttons there's nothing we can do, sorry. If the tablet is showing up as a keyboard device, then it's a keyboard and we only deal with properly exposed pad buttons.

(In reply to Joshua Goins from comment #1)
> If libinput list-devices does *not* list the tablet buttons there's nothing
> we can do, sorry. If the tablet is showing up as a keyboard device, then
> it's a keyboard and we only deal with properly exposed pad buttons.

I'm not sure of the distinction; should the ideal tablet show up as a *single* libinput device? I (naively?) expected at least the pen and the pad buttons to be distinct devices. To be clear in case of misreading, the device that sends events in response to the pad's buttons *does* show up in libinput list-devices (it's just one of four with "Huion" in the name).

If this is an intended restriction in how the module works, is there anywhere that I could focus on to amalgamating the separate devices into a single one so that the tablet can work with KDE's paradigm?

> I'm not sure of the distinction; should the ideal tablet show up as a *single* libinput device? I (naively?) expected at least the pen and the pad buttons to be distinct devices. To be clear in case of misreading, the device that sends events in response to the pad's buttons *does* show up in libinput list-devices (it's just one of four with "Huion" in the name).

No, there's no limitation in that aspect - because KWin will group it as a single device for us. The problem is that your device is not truly a tablet pad device, it's a keyboard :-) (Aka, it's emulating a keyboard.) For Huion there's a tool somewhere I believe that switches it from keyboard-emulation mode to something we can actually use, but that's something you'll have to figure out for your model of tablet.

> If this is an intended restriction in how the module works, is there anywhere that I could focus on to amalgamating the separate devices into a single one so that the tablet can work with KDE's paradigm?

See above.

OK, I still don't completely understand. I hope you don't mind my continuing to ask questions here - with the fragmentation of Wayland vs Xorg and different Wayland compositors and the various drivers (libinput, proprietary, OTD, digimend, ...) it's hard to find anyone with a similar setup. Let me know if you're happier to talk elsewhere.

To see if I can follow this Huion tool route, it would be useful to know more precisely what it should actually change. In `libinput list-devices`, the name of the device is suffixed with "Keyboard" but I assume this is just a name. The capabilities are listed as "keyboard, pointer" - is it this presentation from libinput that we are looking for, or something else?

I am also trying to find somewhere to get information about the dials (which are not even recognised by libinput) so while I'm abusing the issue tracker, if you know somewhere good to discuss that, let me know...

> OK, I still don't completely understand. I hope you don't mind my continuing to ask questions here - with the fragmentation of Wayland vs Xorg and different Wayland compositors and the various drivers (libinput, proprietary, OTD, digimend, ...) it's hard to find anyone with a similar setup. Let me know if you're happier to talk elsewhere.

No I'm totally fine with you asking questions in here! Actually, it may be better than a chatroom because these bug reports are public and more easily searchable :-)

> To see if I can follow this Huion tool route, it would be useful to know more precisely what it should actually change. In `libinput list-devices`, the name of the device is suffixed with "Keyboard" but I assume this is just a name. The capabilities are listed as "keyboard, pointer" - is it this presentation from libinput that we are looking for, or something else?

Correct, the name is made up by somebody (probably libinput?) and indeed it's the representation that has to change in order for our KCM to work. But libinput's capability field is *descriptive* not *prescriptive*, this is where my knowledge gets fuzzier - as libinput is quite complex - but the one who is actually in charge of determining what is a tablet pad vs a keyboard is actually udev. For example, I had to fix a bug where my tablet pad was erroneously being assigned as a joystick, however in your case there is no bug - for all intents and purposes it *is* a keyboard. (I'm assuming there is also keybinds for CTRL+Z and whatever.)

> I am also trying to find somewhere to get information about the dials (which are not even recognised by libinput) so while I'm abusing the issue tracker, if you know somewhere good to discuss that, let me know...

We do have complete support for dials, I added that in libinput. You won't be able to configure them until Plasma 6.5, and with your up-to-date Fedora install it should be recent enough to detect them in libinput list-devices. However the reason why they don't show up is the same reason as your tablet pad: it's probably in some "compatibility mode" where instead of regular dial events it's pretending to be a keyboard or something. If you try "libinput debug-events" what do they emit?

(In reply to Joshua Goins from comment #5)

> Correct, the name is made up by somebody (probably libinput?) and indeed
> it's the representation that has to change in order for our KCM to work. But
> libinput's capability field is *descriptive* not *prescriptive*, this is
> where my knowledge gets fuzzier - as libinput is quite complex - but the one
> who is actually in charge of determining what is a tablet pad vs a keyboard
> is actually udev. For example, I had to fix a bug where my tablet pad was
> erroneously being assigned as a joystick, however in your case there is no
> bug - for all intents and purposes it *is* a keyboard. (I'm assuming there
> is also keybinds for CTRL+Z and whatever.)

OK, I guess it's pretty plausible that udev is not getting it right as the tablet is pretty new. In its default state, the tablet emits a decidedly weird collection of keys and combinations from the buttons; CTRL+Z is not among them - Ctrl+Alt+Z is, for some reason.

I am examining the various devices with `udevadm test ...` and the one named "... Keyboard" has some related things from udev:

  ID_INPUT=1
  ID_INPUT_KEY=1
  ID_INPUT_KEYBOARD=1
  ...
  .INPUT_CLASS=kbd

If I understand what I'm reading, these are attributes that udev is *applying* to the device as presented to downstream components, not inherent properties udev is parsing from it - though the USB vendor and model is among this information.

I was trying to dig through the KWin source to understand how it determines what devices get the `tabletTool` and `tabletPad` properties, but failed to find what I was looking for - if you could point me on a path there, it might help find what I'm looking for (i.e. how the device ought to be presented to work properly. I'm wondering here if the keyboard device just needs to have some attributes added by udev, but I dunno - maybe it also needs to be emitting different events for this to work) I note that the pen device gets tagged `ID_INPUT_TABLET=1` and also `.INPUT_CLASS=mouse`.

> We do have complete support for dials, I added that in libinput. You won't
> be able to configure them until Plasma 6.5, and with your up-to-date Fedora
> install it should be recent enough to detect them in libinput list-devices.
> However the reason why they don't show up is the same reason as your tablet
> pad: it's probably in some "compatibility mode" where instead of regular
> dial events it's pretending to be a keyboard or something. If you try
> "libinput debug-events" what do they emit?

libinput debug-events doesn't see anything from the dials. evtest does, however:

Event: time 1758223196.369503, type 2 (EV_REL), code 7 (REL_DIAL), value -1
Event: time 1758223196.810836, type 2 (EV_REL), code 7 (REL_DIAL), value 1
Event: time 1758223199.206796, type 2 (EV_REL), code 7 (REL_DIAL), value -1
Event: time 1758223199.613508, type 2 (EV_REL), code 7 (REL_DIAL), value 1

(clicking it back and forth a couple of times). The value is larger in magnitude if I spin the wheel faster, also. Since you said that the device suffixes are being added by something in the software stack, the suffix of this device is "System Multi Axis", whatever that means :) The evtest output does not have any distinction between the actions of the two wheels; I wonder if this will be problematic down the line. But maybe evtest isn't showing all the info.

I noticed something interesting, that the dial device reports only a few supported events (visible in evtest):

Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 256 (BTN_0)
    Event code 330 (BTN_TOUCH)
  Event type 2 (EV_REL)
    Event code 7 (REL_DIAL)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)

The keyboard-type device on the other hand supports an entire keyboard's worth, but interestingly includes:

  Event type 2 (EV_REL)
    Event code 6 (REL_HWHEEL)
    Event code 12 (REL_HWHEEL_HI_RES)

It may be nothing though.

I can see that the dial device is not getting any of the udev attributes the working devices get.