HP Active Pen G2 top button is recognized as XF86AudioMicMute about input-wacom HOT 11 CLOSED

How are you determining that the button is XF86AudioMicMute?

I assume you are referring to the Bluetooth button that is where the eraser would normally be. As far as I'm aware, all of the Bluetooth buttons act identically, appearing to the system as a keyboard device which sends the SUPER+F20 keyboard shortcut when pressed (or other shortcuts for other actions). I don't know why the system's keyboard driver would be interpreting such a keyboard shortcut as XF86AudioMicMute...

from input-wacom.

How are you determining that the button is XF86AudioMicMute?

Via xev output. Here is sequence of press-release event, press and hold, and double press:

KeyRelease event, serial 37, synthetic NO, window 0x2600001,
    root 0x2af, subw 0x0, time 2243767, (104,74), root:(3204,238),
    state 0x10, keycode 198 (keysym 0x1008ffb2, XF86AudioMicMute), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x2600001,
    root 0x2af, subw 0x0, time 2247487, (104,74), root:(3204,238),
    state 0x50, keycode 196 (keysym 0x1008ff49, XF86Launch9), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x2600001,
    root 0x2af, subw 0x0, time 2247554, (104,74), root:(3204,238),
    state 0x10, keycode 196 (keysym 0x1008ff49, XF86Launch9), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x2600001,
    root 0x2af, subw 0x0, time 2250398, (104,74), root:(3204,238),
    state 0x50, keycode 197 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x2600001,
    root 0x2af, subw 0x0, time 2250464, (104,74), root:(3204,238),
    state 0x10, keycode 197 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Same sequence in evtest:

Event: time 1541765848.281019, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e3
Event: time 1541765848.281019, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time 1541765848.281019, -------------- SYN_REPORT ------------
Event: time 1541765848.309869, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7006f
Event: time 1541765848.309869, type 1 (EV_KEY), code 190 (KEY_F20), value 1
Event: time 1541765848.309869, -------------- SYN_REPORT ------------
Event: time 1541765848.369825, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e3
Event: time 1541765848.369825, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
Event: time 1541765848.369825, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7006f
Event: time 1541765848.369825, type 1 (EV_KEY), code 190 (KEY_F20), value 0
Event: time 1541765848.369825, -------------- SYN_REPORT ------------
Event: time 1541765858.273159, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e3
Event: time 1541765858.273159, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time 1541765858.273159, -------------- SYN_REPORT ------------
Event: time 1541765858.300203, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7006d
Event: time 1541765858.300203, type 1 (EV_KEY), code 188 (KEY_F18), value 1
Event: time 1541765858.300203, -------------- SYN_REPORT ------------
Event: time 1541765858.360130, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e3
Event: time 1541765858.360130, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
Event: time 1541765858.360130, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7006d
Event: time 1541765858.360130, type 1 (EV_KEY), code 188 (KEY_F18), value 0
Event: time 1541765858.360130, -------------- SYN_REPORT ------------
Event: time 1541765866.701038, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e3
Event: time 1541765866.701038, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time 1541765866.701038, -------------- SYN_REPORT ------------
Event: time 1541765866.730406, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7006e
Event: time 1541765866.730406, type 1 (EV_KEY), code 189 (KEY_F19), value 1
Event: time 1541765866.730406, -------------- SYN_REPORT ------------
Event: time 1541765866.790776, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e3
Event: time 1541765866.790776, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
Event: time 1541765866.790776, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7006e
Event: time 1541765866.790776, type 1 (EV_KEY), code 189 (KEY_F19), value 0
Event: time 1541765866.790776, -------------- SYN_REPORT ------------

I assume you are referring to the Bluetooth button that is where the eraser would normally be.

Seems like that the case, according to evtest. Should I forward this issue to libinput or mutter then? (It's Gnome Shell Wayland session.)

from input-wacom.

Its unlikely that libinput is responsible, but since you're using xev under Wayland it could be an issue in xwayland or elsewhere in the X stack. I suppose it could also be Mutter, but I'm not sure.

I found this Mutter commit after a little searching which makes it sound like F20 used to be sent when the microphone mute button was pressed. Its possible that there's some compatibility layer is still assuming F20 should be translated into XF86AudioMicMute. That particular commit seems to be removing Mutter's F20 = XF86AudioMicMute assumption though, which is why I'm not very suspicious of that component.

@whot knows more X11 input arcana than anyone else... Maybe he'll stop by with a clue :)

from input-wacom.

yeah, libinput doesn't do anything with key events, certainly no remapping. The issue is... complicated.

X (the protocol) has a limitation of 255 for key codes, but keycodes are offset by 8 for historical reasons. So the evdev to keycode mapping is literally "evdev keycode + 8". KEY_ESC is thus X key code 9.

Next layer is the xkb model which maps that number to a symbolic key:

keycodes/evdev: <FK20> = 198;

i.e. keycode 198 is mapped to FK20 and that is mapped to the symbol:

symbols/inet:    key <FK20>   {      [ XF86AudioMicMute      ]       };

So this is where your 198 -> microphone mapping comes from.

Note that FK20 is not F20. FK20 is an internal lookup symbol. The actual mapping applied is "198 -> XF86AudioMicMute". F20 mapped to F20 would look like this:

symbols/inet:    key <FK20>   {      [ F20      ]       };

If that were the case, xev would show F20 as Keysym.

Why do we map FK20 to micmute? Because we can't use this one:

#define KEY_MICMUTE             248     /* Mute / unmute the microphone */

The keycode is 248 + 8 = 256, outside of what X can deal with. ftr Wayland has 32bits so all this should work fine there.

As for the mutter commit: this is the opposite of what we need. Previously, gnome would assume that both XF86AudioMicMute and F20 trigger the microphone. With that commit, only the former does so which means you could configure your XKB layout to have anything send XF86AudioMicMute. The latter would now just be interpreted as F20.

But the pen itself sends keycode 190 (KEY_F20) and because of historical reasons that is mapped to micmute in XKB. So we do get the XF86AudioMicMute symbol, GNOME mutes the microphone, etc.

If all the pens send F20 for those keys then we're in an amount of fecal matter of reasonable depth because I'm not aware of any workarounds to really get F20 working. Adding an XKB option would be doable but it would need manual applying (or heuristics-based). I think this screams for a GNOME bug to be opened to figure out what to do here...

from input-wacom.

I put on my waders and tried out a hacked-up XKB definition with success. The ugly part, as you say, is going to be applying the option for these pens. I can try to gather the "keyboard" device names from the pens we have available if that helps in putting together a heuristic (whether for an xorg.conf.d rule or some GNOME logic). The kernel device itself doesn't look terribly helpful; it basically appears to be a full keyboard rather than just the handful of keys it ever sends.

from input-wacom.

There's XKB_FIXED_LAYOUT, XKB_FIXED_VARIANT which was intended for similar use-cases. but I can't find anything in the GNOME tree that actually uses it. Adding support for that would be the best solution I think, together with a udev rule to set it for the device. Beyond that...

/me scratches his head and shrugs

from input-wacom.

I think this screams for a GNOME bug to be opened to figure out what to do here...

Please let me know if opening Gnome issue is still necessary.

from input-wacom.

Yes please, we'll need to track this

from input-wacom.

Mutter bugreport: https://gitlab.gnome.org/GNOME/mutter/issues/432 (was that right component to fill this bug, btw?)

from input-wacom.

Meanwhile I added feature request regarding configuration of this button to Gnome Control Center: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/638

from input-wacom.

Ok, the request has been reported to Gnome. The button/key is beyond this project's scope.

from input-wacom.