Pass on the hw button keycodes

[whot]

Fixes #45

This is still work in progress

This patch adds the code to pass on KEY_PROG1 and friends to the X server, to be passed on to the clients from there. Realistically, this doesn't do anything for the other three codes because they're above the 255 keycode limit and will get dropped by the server immediately.

The handling is hardcoded for the 6 buttons we care about, IMO there's little point to make this a fully generic.

I'm not sure if the events can occur on their own without any EV_ABS like we do for the normal buttons. Right now, the code assumes they are not affected by proximity, etc.

cc @jigpu, @Pinglinux, @skomra

[jigpu]

FWIW, I think its probably better to modify the kernel driver to send the proper evdev codes, now that they're available. Back when the buttons debuted with the 24HD, it was hard to say if they would show up on more products. I hooked them up to KEY_PROG* as a temporary solution since it would be hard to get new evdev codes added. The recently introduced KEY_BUTTONCONFIG, KEY_ONSCREEN_KEYBOARD, KEY_CONTROLPANEL, and SW_MUTE_DEVICE should cover the features of the 24HD, 22HD, and 27QHD and we just need to update the kernel.

[whot]

tbh, I doubt you'd get that change through. You'd be breaking userspace by changing the button codes.

[jigpu]

I kinda doubt there's any userspace code to be broken. Definitely not xf86-input-wacom or libinput, and a vanishingly small chance of some custom script or program going to the trouble of watching the evdev device to read the state of these buttons. If its a concern though, we could continue posting the KEY_PROG* events and just post the "proper" events alongside them.

[whot]

Well, from my POV anything you do to make the kernel report saner events is going to be welcomed. I'd be ok with posting both as an emergency case, I can disable/ignore those quite easily.

So if you submit a patch for that, just picture me with pom-poms on the side, cheering you on. Or not, if not picturing that is more helpful ;)

[skomra]

Kernel patch queued for 5.4: https://patchwork.kernel.org/patch/11098125/

[jigpu]

The kernel changes appear to be in place, so so we want to remove the references to KEY_PROG references from this patch and then consider merging it?

[whot]

Well... KEY_PROG were the ones below the 255 keycode limit, if we remove the processing of those keys then we just end up passing events to the server which will immediately drop them. The chances of X ever having 32-bit keycodes are nil at this point, so adding the patch will merely help with keeping the room warm but not add any functionality.

[whot]

Rebased, and I've dropped support for KEY_PROG1-3 now. To make the KEY_BUTTONCONFIG and friends work, I had to remap those to ... KEY_PROG1 and friends. 255 keycode limit and whatnot. Alanis Morisette may have something to say about this.

If merged, we can add an xkeyboard-config option to map those to some keysyms, but for now this here will do.

[jigpu]

@whot main obvious concern is missing support for KEY_INFO (see suggested patch below). Other than that, it looks fine to me. Is there any reason I shouldn't merge this into the release I'm about to make?

diff --git a/src/wcmCommon.c b/src/wcmCommon.c
index a55c956..8f563ac 100644
--- a/src/wcmCommon.c
+++ b/src/wcmCommon.c
@@ -224,6 +224,9 @@ static void wcmSendKeys (InputInfoPtr pInfo, int current, int previous)
 				case IDX_KEY_BUTTONCONFIG:
 					key = KEY_PROG3;
 					break;
+				case IDX_KEY_INFO:
+					key = KEY_PROG4;
+					break;
 				default:
 					break;
 			}
diff --git a/src/wcmUSB.c b/src/wcmUSB.c
index 25e2897..d0220af 100644
--- a/src/wcmUSB.c
+++ b/src/wcmUSB.c
@@ -1647,6 +1647,9 @@ static void usbParseBTNEvent(WacomCommonPtr common,
 		case KEY_BUTTONCONFIG:
 			ds->keys = mod_buttons(ds->keys, IDX_KEY_BUTTONCONFIG, event->value);
 			break;
+		case KEY_INFO:
+			ds->keys = mod_buttons(ds->keys, IDX_KEY_INFO, event->value);
+			break;
 		default:
 			for (nkeys = 0; nkeys < usbdata->npadkeys; nkeys++)
 			{
diff --git a/src/xf86WacomDefs.h b/src/xf86WacomDefs.h
index 6b1744f..164509a 100644
--- a/src/xf86WacomDefs.h
+++ b/src/xf86WacomDefs.h
@@ -213,6 +213,7 @@ struct _WacomModel
 #define IDX_KEY_CONTROLPANEL		1
 #define IDX_KEY_ONSCREEN_KEYBOARD	2
 #define IDX_KEY_BUTTONCONFIG		3
+#define IDX_KEY_INFO			4
 
 /******************************************************************************
  * WacomDeviceState

[whot]

Thanks, I've squashed that diff in (together with a few minor changes to the existing code etc). I think it's ready to merge but I haven't tested this since the last attempt (Sep. If you can fit a test in please do merge, otherwise better to hold off until I find time to do that.

[jigpu]

Quick test with xinput test-xi2 showed the scancodes coming through as expected, so I've gone ahead and merged.

[Lovewyrm]

Just to ask, as a layman.
Does this mean it's possible to soon/now bind actions to these keys?

[whot]

Yes, they should have keycodes 156, 157 and 210 (xev will verify this). These should be mapped into keycodes XF86Launch1 and so on so you can work from that.

[Bracket-H]

I have a cintiq pro 24 and the only way I can even see the wacom devices is by running evemu as root.

xev, for me, does not show anything when pressing these keys, either.
My kernel is 5.15.16

How do I practically use this?

[whot]

I have a cintiq pro 24 and the only way I can even see the wacom devices is by running evemu as root.

that is expected, input devices cannot usually be opened by the user as this leads to keyloggers. What events do you see when you press the buttons?

[Bracket-H]

I have a cintiq pro 24 and the only way I can even see the wacom devices is by running evemu as root.

that is expected, input devices cannot usually be opened by the user as this leads to keyloggers. What events do you see when you press the buttons?

I see the EV_ABS and EV_MISC things when I use evemu as root.
I see the events like IDX_KEY_CONTROLPANEL, virtual keyboard, etc.

I get nothing using xev as a regular user, that's why I'm confused on how to actually, practically use this, in conjunction with something like xbindkeys and the like.

No XF86Launch things either, even though I tested it with a keyboard that has media keys, which do work.

So yeah, I have no idea how to use this apparently solved problem, lol.

[whot]

could be that your desktop environment grabs those calls to launch the matching program but then doesn't actually launch anything (maybe because there is nothing configured). Or could be that the driver has a bug, but a quick check shows that the code to convert those into KEY_PROG1 etc is still there and that those are mapped into XF86Launch1 in xkeyboard-config.

The former can be ruled out if you start a plain X session (see xinit) and then run xev -root - if that doesn't show any events either the issue is within the driver or the server (though the server shouldn't care about this at all).

[Bracket-H]

Thank you for providing these elaborations, and your time.

I cannot for sure say how 'plain' my x session is, but I think it's basically an xinit script that loads xmonad.

As for the root window test from xev... I have to, sadly, report that no events are registered there, either.

I have the following wacom related packages installed

libwacom-2.6.0
wacomtablet-20220124_dd28b27
xf86-input-wacom-1.1.0

My guess is that wacomtablet is the driver? If so then ...perhaps that needs updating.
If it's not, then I guess the others do, or all of them, hahaha...ah, ignorance.

Edit: Ignorance indeed, wacomtablet is a kde frontend. So, nevermind for that.

modinfo wacom:

filename:       /lib/modules/5.15.16/kernel/drivers/hid/wacom.ko
license:        GPL
description:    USB Wacom tablet driver
author:         Vojtech Pavlik <vojtech@ucw.cz>
version:        v2.00
srcversion:     AE3E70B1972773856016D65
alias:          hid:b0003g*v000017EFp00006004
alias:          hid:b0003g0101v0000056Ap00005002
alias:          hid:b0003g0101v0000056Ap00005000
alias:          hid:b0003g0101v0000056Ap00004004
alias:          hid:b0003g0101v0000056Ap00004001
alias:          hid:b0005g0101v0000056Ap000003C8
alias:                       ... ... ... (bunch of them in sequential digits)
alias:          hid:b0003g0101v0000056Ap00000000
alias:          hid:b0005g0101v0000056Ap000000BD (this one has a 5, though)
depends:        hid,usbhid
retpoline:      Y
intree:         Y
name:           wacom
vermagic:       5.15.16 SMP preempt mod_unload 
parm:           touch_arbitration: on (Y) off (N) (bool)