https://bugs.kde.org/show_bug.cgi?id=509613
Chris Le Sueur <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INTENTIONAL |FIXED --- Comment #6 from Chris Le Sueur <[email protected]> --- (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. -- You are receiving this mail because: You are watching all bug changes.
