Add an API to retrieve the evdev codes for the HW keys

[whot]

The Cintiqs have had hardware keys for a few generations now. These translate
to KEY_PROG1 and friends in the older tablets, newer tablets have them as
KEY_BUTTONCONFIG, etc.

To make it possible which labeled key sends which event code, add an API to
look this up. Since the HW buttons are of (intended) fixed functionality and
there are only 4 possible options, the type is an enum.

Note: this is incomplete right now, we need to add the newer devices with the correct mappings

[whot]

ping?

[jigpu]

Apologies; super busy with non-community projects at the moment. The patch seems reasonable but I can only give it an Acked-by I'm afraid. If you need additional evemu recordings let me know.

[whot]

yes please, I'll need the various recordings from the other devices, and/or just a list of which devices have the keys and how they are mapped. I guess I could get that from the kernel sources, but... :)

[whot]

just a friendly reminder, I still haven't been able to finish this one, lack of info about the hw.

kernel commit 4eb220cb35a9c4f69a2438b987bb3d509d56cc80 suggests this is the Wacom Cintiq Pro series, so is that all of our cintiq-pro*.tablet files? they look to be the straightforward mappings but should still be added here.

[jigpu]

Code looks good, as does the data for the 22, 24, and 27 with one minor exception. The "menu" button on the 22 (both touch and non-touch) is handled by the firmware to open up the monitor controls and doesn't actually generate an event the kernel can see. The kernel driver claiming all three KEY_PROG events looks like an oversight. The "Menu" button entry for both of the devices can be removed.

Tangentially, with regard to linuxwacom/xf86-input-wacom#46 I'm not sure if we want to cannonize the KEY_PROG* events within libwacom. I'm tempted to have libwacom list the modern events instead (once a patch to add them has been accepted by the kernel) since its going to be a while before userspace will start using the "[Keys]" section. No need to encourage the further use of our past mistakes.

As for other devices with "Hardware Control Buttons" (the name given for them in the manuals), I believe there's just the Cintiq Pro 32/24/16/13. They all have the same buttons and send the same keys, so I believe the following snippet would be correct:

[Keys]
# Display switch button handled in firmware
Wrench=0x240    # KEY_BUTTONCONFIG
Keyboard=0x278  # KEY_ONSCREEN_KEYBOARD
Menu=0x243      # KEY_CONTROLPANEL
# Touch switch button sends SW_MUTE_DEVICE

[Lovewyrm]

I'm a bit of a noob when it comes to these git shenanigans but...if there is a working version somewhere in any of your pull requests or issues or whatever that allows me to bind the hardware buttons -right now- if I download some branch or patch, then I would be highly interested in them.

Even if they're specific, I have tried hacking the kernel driver myself, lol, but I didn't get very far, it does seem to emit some keys but I can't bind them, and even if I set the emitted keys to something like "KEY_A" (which does happen) no actual A (this is for CONTROLPANEL on my cintiq pro 24 btw) gets 'caught' anywhere, not even a terminal.

I think I could modify an already working thing for myself, though, so...yeah, I would be very thankful for a quick explanation where I could get a patch or fork or whatever that allowed me to. Since its just for my personal use I don't really care if it's sane or industrial standard or whatever <<.
I just want to put something useful on those three useless buttons.

Edit:
If this very issue has code that does it, then please point that out (I know how to patch stuff, etc this whole 'interface' to git and whatnot is just new to me), if you do decide to help.
Again, anything that works, I'll gladly take, even if I have to modify it for my specific model.

[whot]

@Lovewyrm there isn't. You'd need support in libwacom, xf86-input-wacom, libinput, the wayland compositor and possibly the toolkits/applications. None of this is in place yet. and this patch set is merely a label that indicates which buttons a device has. libwacom does not affect device functionality directly

[whot]

Updated the PR with @jigpu's comments, just so we have them here.

I'm tempted to have libwacom list the modern events instead

If we're switching the kernel to report the new ones as well, then we don't actually need to add anything in libwacom? maybe if some configuration panel wants to show them but I suspect this will just be handled as the keycode that comes in.

[jigpu]

I was also unsure whether this patch would be necessary if the kernel patches get in. I thought it might still be useful (in conjunction with an update to the layout files) to provide users with information on what the hardcoded buttons on their device do. Explicitly listing the evdev codes that they send might be unnecessary though?

[whot]

we can add it but tbh I'm not sure whether anything would make use of them. I'd vote for leaving it out until there's a distinct need for it.

and yes, I agree, the evdev codes are unnecessary so if anything this would just be a "HWKeys=touch;wrench;" entry and the related API.

[whot]

I'm closing this PR because it was about the evdev codes. Now that the kernel is getting standardised we don't really need it anymore. As above, we could add the hw keys that are available to the file in case someone wants that info but we should a) do this in a separate PR and b) do this when we have an actual consumer.