Route KEY_PROG1 and friends through to X

[whot]

The Cintiq 24HD sends KEY_PROG1 through to KEY_PROG3 for the special buttons, but the wacom driver discards them. Let's not do that, let's pass them on and let userspace figure out what to do with them. The default mapping is XF86Launch1 through to XF86Launch3 so they could be assigned.

More recent tablets send KEY_CONTROLPANEL, KEY_ONSCREEN_KEYBOARD, and KEY_BUTTONCONFIG but those have keycodes outside the 255 X keycode range.

[whot]

@jigpu, can you provide me with an evemu recording for the two series of tablets affected? I need to know if we only see KEY_foo on press or other data as well (ABS_MISC, etc.)

[jigpu]

You'll be getting ABS_MISC as well as the KEY event; that's just part-and-parcel of our contract* with xf86-input-wacom. I don't have the muscles to dig out a 27QHD right now, but I've attached HID and evemu recordings of the 24HDT. Fun fact: they show off a bug I hadn't noticed in current kernels that prevents KEY_PROG3 from ever being sent 😨

24hdt-function-keys.evemu.log
24hdt-function-keys.hid.log

*One that we might consider revising at some point now that the pad is its own top-level device in upstream kernels...

[whot]

Closing this one, its'... tricky.

The simple part is that with kernel 5.4 all tablets send the new key codes and we don't need to care about KEY_PROG* anymore.

The difficult part is that the new key codes are outside the X server's 255 keycode range. They would need remapping down to something below 255 and a special XKB option to map them to something actually useful. Whether that is likely to happen is doubtful, I think this is a case where we just have to admit defeat due to ETIME and say that this will work under Wayland where we don't have those restrictions in place.