Key config for XF86AudioMicMute

[godlike64]

Is your feature request related to a problem? Please describe. The current Bazecor version has no key config option for XF86AudioMicMute

Describe the solution you'd like There should be a key available in the key config, section 'MEDIA" for XF86AudioMicMute.

Describe alternatives you've considered WIth the current configuration, the only way to access this key would be by setting up a custom keyboard shortcut on the desktop of choice.

Additional context This key is present on some laptops (e.g. Thinkpad P51), next to the volume/mute sound keys.

EDIT: I have noticed the Linux/Xorg version of the key, I'm unaware how the key is referred to in Windows/Mac.

[godlike64]

Any chance of implementing this? If not, how would a regular user go about adding support for key codes not present in Bazecor? Even though my javascript is not good, I would be willing to give it a try but I don't know where to start.

[Lite5h4dow]

@godlike64 src/api/keymap/db/mediacontrols.js is where all the media controls are. if you know the XF86 keycode you can add it there.

[godlike64]

Hey @Lite5h4dow thanks for the reply. I'm digging on this and I've seem to hit a wall.

I opened up the file you mentioned and can indeed see all the keys. So I ran xev to get the key for XF86AudioMicMute:

KeyRelease event, serial 41, synthetic NO, window 0x8000001,
    root 0x229, subw 0x0, time 167516255, (662,300), root:(2586,353),
    state 0x0, keycode 198 (keysym 0x1008ffb2, XF86AudioMicMute), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

I also did the same for XF86AudioMute in case it was needed:

KeyRelease event, serial 40, synthetic NO, window 0x8000001,
    root 0x229, subw 0x0, time 167515052, (662,300), root:(2586,353),
    state 0x0, keycode 121 (keysym 0x1008ff12, XF86AudioMute), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Now if I look at mediacontrols.js, I can see the Mute key alright:

 18 const MediaControlTable = {
 19   groupName: "Media",
 20   keys: [
 21     {
 22       code: 19682,
 23       labels: {
 24         top: "Media",
 25         primary: "MUTE"
 26       }
 27     },

However, I can't figure out where that 19682 is coming from, which I believe is the correct code to be used here. On my xev output, the keycode for XF86AudioMute (the 'MUTE' key in Linux) is 121 and I see no way of turning that into 19682. It is either too early in the day for me or this is indeed beyond me :).

[Lite5h4dow]

ill take a look myself later now I have the dev environment running. might be a serial code if I understand how the keyboard is programmed, ill get back to you if/when i know more.

[Lite5h4dow]

@godlike64 just to let you know where I've gotten given this is referencing kaliedoscope keycodes (as seen here: https://github.com/keyboardio/Kaleidoscope/blob/master/src/kaleidoscope/key_defs/consumerctl.h) I think I found what you are looking for. Consumer_StartOrStopMicrophoneCapture is that correct? if so I just need to find the corresponding keycode.

[godlike64]

Could be. While researching this I got to the HID tables: https://www.usb.org/sites/default/files/hut1_21_0.pdf

Don't know if it's related. From your link, it certainly seems to be the only one related to this, other than this one:

define Consumer_MicrophoneCa CONSUMER_KEY(HID_CONSUMER_MICROPHONE_CA, HID_TYPE_CA)

I can certainly try a test build or patch to see if that would provide this functionality.

[chbroecker]

I would also really love to have this enhancement. :)

[godlike64]

Any news on this? Is there by any chance a test build we might be able to test to help out?

[godlike64]

I've been trying to find the keycode for this, and I've hit a wall. I tried using rule of threes taking into account the current hex keycodes on the kaleidoscope/HID tables that were mentioned in this issue, comparing with ones for which we do know the decimal 5-digit keycode that are mapped in the file, and extrapolating from there to get 5-digit values to test. Unfortunately none of the ones I tried worked, and I am now trying one by one seeing if it works.

Hence my question: is it possible that there is something at the firmware level missing? Because on all of the keys that I try, on the xev output I get either no output at all when pressing the key, or this:

KeyRelease event, serial 57, synthetic NO, window 0xdc00001,
    root 0x1e2, subw 0x0, time 450533046, (81,94), root:(1263,155),
    state 0x10, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

and this makes me wonder if there's a firmware component missing for this. Nevermind the fact that I could never figure out how do we go from, e.g.

#define HID_CONSUMER_SCAN_NEXT_TRACK                0xB5    // OSC

which is 181 in decimal, to 22709:

 { 
   code: 22709,
   labels: {
     top: "Media",
     primary: "TRACK+",
     verbose: "Next track"
   }

I have found no reference that would let me figure out the 5-digit value based on the hex keycode on the consumer table, so I'm thinking this might be an internal mapping of the firmware?

[Lite5h4dow]

thing is, although this is a standard input, its not guaranteed to be implimented. i hit the same roadblock when doing it.

[godlike64]

thing is, although this is a standard input, its not guaranteed to be implimented. i hit the same roadblock when doing it.

Sorry for the dumb question, but does this mean that it is not possible at all? Or it might be possible if implemented in the firmware?

[Lite5h4dow]

its doable it just relies on applications like slack and discord recognising the key

[godlike64]

its doable it just relies on applications like slack and discord recognising the key

If the key can emit XF86AudioMicMute, it doesn't matter which application is using the microphone, since the desktop environment in use will recognize it and mute the microphone device completely. In fact muting the microphone from the application becomes unnecessary with this, as the microphone is muted globally.

[Lite5h4dow]

im sure thats true if you only have one default input on comms. but for people using complex audio setups im not sure it works globaly

[godlike64]

In those cases, XF86AudioMicMute, when picked up by the desktop environment, will mute the default microphone. The same way that XF86AudioMute (which is already provided by Bazecor, I believe the label is MUTE) mutes the default sound output device if there are more than one of them.

[GazHank]

Has anyone had any luck identifying the required codes for Mic Mute?

It looks like a recent change to the HID codes from microsoft has added a consumer code of 0xD5 to the spec (18645 in decimal if my maths is correct) but trying to send that code doesn't seem to do anything. I think it's just too new, or it just mutes the broadcasted mic and not system wide.

There are plenty of other codes which are old enough to be in active deployment (e.g. Brightness controls and Camera Mute), but I can't seem, to find a microphone mute code that works yet...

[godlike64]

Has anyone had any luck identifying the required codes for Mic Mute?

It looks like a recent change to the HID codes from microsoft has added a consumer code of 0xD5 to the spec (18645 in decimal if my maths is correct) but trying to send that code doesn't seem to do anything. I think it's just too new, or it just mutes the broadcasted mic and not system wide.

There are plenty of other codes which are old enough to be in active deployment (e.g. Brightness controls and Camera Mute), but I can't seem, to find a microphone mute code that works yet...

For some reason I'm unable to do a test build, as Bazecor just greets me with a blank screen and I can't do anything, but I'm wondering how you got from 0xD5 to 18645?

Edit: managed to build it with a media key pointing to 18645. Configured that on a key and nope, nothing happens. xev catches this:

KeyPress event, serial 41, synthetic NO, window 0x10800001,
    root 0x1e2, subw 0x0, time 2081686754, (32,105), root:(3153,166),
    state 0x10, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x10800001,
    root 0x1e2, subw 0x0, time 2081686824, (32,105), root:(3153,166),
    state 0x10, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

which is what I've been getting on my tests (it appears to be a blank key). The actual XF86AudioMicMute as recognized by Linux is:

KeyRelease event, serial 41, synthetic NO, window 0x8000001,
    root 0x229, subw 0x0, time 167516255, (662,300), root:(2586,353),
    state 0x0, keycode 198 (keysym 0x1008ffb2, XF86AudioMicMute), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

[GazHank]

Hi @godlike64

sorry I should have explained the maths, 0xD5 is the key code but it is on the consumer page, as such the keycodes is offset as as to not clash with other uses for the keys. For example Speaker mute is 0xE2 within the hid table, but is offset by 4C00 or 5800, so sending a keycode of 4CE2 (19682) or 58E2 (22754) is actually needed to trigger the speaker mute / unmute function.

As such I've tried the new 0xD5 code with a few offsets: 48D5 (18645), 4CD5 (19669) and 58D5 (22741). None of these codes seem to cause the desired affect. As such, either I'm trying the wrong codes or they are not yet in use (even for the xbox gamebar which seems to be microsofts original intended purpose).

From what I can tell, XF86AudioMicMute isn't directly mapped of the HID keycodes, but rather an system specific remapping, or virtual key code. For most Linux systems this seems to be simply F20, unfortunately this wont work for alternative OSs but will probably work for Linux users. Since F20 is already available within Bazecor you should be able to map it as you like.

There is some extra info and links available on the UHK issue log if that is helpful

@AlexDygma I wonder if we should allow users to directly enter a chosen key code. At the moment if the keyboard has a key with a keycode that isnt recognised by bazecor then it allows the user to type the desired code:

However this "feature" isnt enabled by default. I think this might be a neat way for experienced user to try out new keycodes (or language specific codes if needed). We could always hide this behind a toggle button in Preference->Advanced so as to not confuse anyone unnecessarily? I'd be happy to draft a code change for this, if that would be helpful

Cheers

Gaz

[godlike64]

You @GazHank are gorram awesome! It was F20 all along! I wonder which other F keys are already mapped by default, or even mapped in other OSs :thinking:

The manually entering a keycode I already stumbled upon on one of my tests, if I left a random keycode assigned and on the next build, that keycode does not belong to anything, I got the text input to manually enter one. Sadly, once you enter a keycode that is mapped and recognized by Bazecor, you get the actual recognized keycode and can no longer enter a text value. Would certainly be interesting to have it available via an advanced setting to try out new ones!

[ryanerwin]

As @GazHank I would very much like to specify keycodes manually...

For example, F20, F21 and F22 I would like to use, but I also do not want to disable the embedded support that the OS has for XF86AudioMicMute, XF86TouchpadToggle and XF86TouchpadOn...

We have the FX KLeys F1-F24 in the Dygma Configuration... We also have the Media Keys... Seems like F20, F21, F22 could also be separated...

There are also XF86LaunchN keys... Some are by default assigned to F14-F19, but would also be ideal if these were separated.

[GazHank]

@ryanerwin I'm not sure I understand what you mean by separated?

Is it that you would like to override the OS mapping of those F keys so that they can be used for an alternative purpose?

[ryanerwin]

In my ~/.Xmodmap I have to following so Linux recognizes F13-F24

keycode 191 = F13 
keycode 192 = F14 
keycode 193 = F15 
keycode 194 = F16 
keycode 195 = F17 
keycode 196 = F18 
keycode 197 = F19 
keycode 198 = F20 
keycode 199 = F21 
keycode 200 = F22 
keycode 201 = F23 
keycode 202 = F24 

It would be nice to have extra keycodes assigned for:

XF86Tools XF86Launch1-XF86Launch9 XF86TouchpadToggle XF86TouchpadOn XF86AudioMicMute

Even if in the OS we had to add a few more entries ~/.Xmodmap...

It's all much easier to keep up to date when we look at Bazecor and can see what key is what...

Perhaps you could just allow us to enter whatever keycode we want for keys, and assign our own label that shows in Bazecor.... That would be ideal.

[GazHank]

Ah ok, there is a bit of a hidden feature within BazeCor 0.3x (I don't know if it's in the beta version 1, as I've not had chance to play with that yet)

If you Define a key to use an keyCode which isnt recognised by the software then instead of forcing you to select a key it let's you manually enter the keycode.

At the moment the easiest way to do this is probably to manually tweak the exported layer file. I also experienced this then I added the Japansese or German specific keys to my keyboard and then reverted to the base BazeCor software. I think it probably makes sense to allow manual entry of keycodes via an extra option in the key selector (or hit it behind the advances settings button)

Once the beta is a little more stable I will take a look and see if this can easily be added. I doubt the team will have chance to incorporate any external patches at the moment as they seem super busy getting the beta stable

[ryanerwin]

I also experienced this then I added the Japansese or German specific keys to my keyboard and then reverted to the base BazeCor software

Yes, I also experienced this when adding some of the new XF86Brightness++ / XF86Brightness-- keys in the patched version, then starting up the release version and some keycodes aren't labeled.

My point is that you should allow the user to enter**Key code** AND **Label** so that we know what that keycode represents.

[Lite5h4dow]

found it, adding it to beta.

[javierguzman]

This is duplicated #257 so I close this. The long story short is to give the user the ability to add XF86 key codes