Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

HP Active Pen G2 top button is recognized as XF86AudioMicMute #49

Closed
RussianNeuroMancer opened this issue Nov 1, 2018 · 11 comments
Closed

HP Active Pen G2 top button is recognized as XF86AudioMicMute #49

RussianNeuroMancer opened this issue Nov 1, 2018 · 11 comments

Comments

@RussianNeuroMancer
Copy link

RussianNeuroMancer commented Nov 1, 2018 •
edited
Loading

Hello!

Moved from https://sourceforge.net/p/linuxwacom/bugs/361/

I find that top button of HP Active Pen G2 (that was included in the package with HP Elite x2 1013 G3) is recognized as XF86AudioMicMute. Maybe remap this button to something else, more suitable?

sysinfo report is here: linuxwacom/wacom-hid-descriptors#42
@jigpu
Copy link
Member

jigpu commented Nov 7, 2018

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...

@RussianNeuroMancer
Copy link
Author

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.)

@jigpu
Copy link
Member

jigpu commented Nov 13, 2018 •
edited
Loading

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 :)

@whot
Copy link
Member

whot commented Nov 26, 2018

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...

@jigpu
Copy link
Member

jigpu commented Nov 27, 2018

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.

@whot
Copy link
Member

whot commented Nov 27, 2018

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

@RussianNeuroMancer
Copy link
Author

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.

@whot
Copy link
Member

whot commented Nov 29, 2018

Yes please, we'll need to track this

@RussianNeuroMancer
Copy link
Author

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

@RussianNeuroMancer
Copy link
Author

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

@jigpu jigpu mentioned this issue Jan 7, 2022
Closed
@Pinglinux
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jigpu @whot @RussianNeuroMancer @Pinglinux