Shortcuts lost/mismatched if bound to X11 in differing orders #3011

New issue

Open

opened 2026-02-20 22:16:39 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-20 22:16:39 -05:00

Owner

Originally created by @Dessix on GitHub (May 29, 2025).

Description

I am using the OpenDeck tool, which internally utilizes Enigo for input emulation.

I have several push-to-talk keys set up to emulate keys which are not normally bound in X11's xmodmap. However, Enigo has the capability to dynamically map these keys as long as the modmap has open slots. It does so for unmapped keys upon their first invocation.

I have bound global (Parent + subchannels), local (current only), and push-to-talk to F33, F34, and F35 respectively. However, Mumble stores these based on their index in the xmodmap, rather than their actual key symbol.

What's odd is that Mumble is frequently able to recognize what key symbol it is, but then loses it later; this seems to be because the key is stored as the xmodmap index and only displayed by its known symbol. If Mumble is then loaded without the key in question mapped, it forgets that it was - for example - F35, and simply shows whatever index that key was at the time of previous use. If that index is now occupied by a different key, it silently binds to that new key.

If it is possible to store the expected symbol, then load it when a new keycode is activated, rather than only storing the index into the xmodmap, this could avoid the binding juxtapositions.

Steps to reproduce

Here is what it looks like if I open Mumble after pressing the global (F33) then local (F34):

Then if I close OpenDeck, dropping the Enigo context, these dynamic-bound keys are unmapped; opening Mumble anew shows the raw indecies previously held by these keys at binding time:

But if I now start OpenDeck anew, then press the buttons in the opposing order, local (F34) then global (F33), then load Mumble, I end up with the following corrupted configuration:

Mumble version

1.6.0 on master branch and on davidebeatrici:shortcut-data-qdatastream-fix

Mumble component

Client

OS

Linux

Reproducible?

Yes

Additional information

For reproducibility's sake, these OpenDeck bindings look like this:

OpenDeck only preserves Enigo contexts long enough to use for PTT (helpful but not required to repro, otherwise unmapping is near-instantaneous) in this branch.

Relevant log output

Screenshots

No response

Originally created by @Dessix on GitHub (May 29, 2025). ### Description I am using the [OpenDeck](https://github.com/nekename/OpenDeck) tool, which internally utilizes [Enigo](https://github.com/enigo-rs/enigo) for input emulation. I have several push-to-talk keys set up to emulate keys which are not *normally* bound in X11's `xmodmap`. However, Enigo has the capability to dynamically map these keys as long as the modmap has open slots. It does so for unmapped keys upon their first invocation. I have bound `global` (Parent + subchannels), `local` (current only), and `push-to-talk` to F33, F34, and F35 respectively. However, Mumble stores these based on their index in the `xmodmap`, rather than their actual key symbol. What's odd is that Mumble is frequently able to recognize *what* key symbol it is, but then loses it later; this seems to be because the key is stored as the xmodmap index and only displayed by its known symbol. If Mumble is then loaded without the key in question mapped, it forgets that it was - for example - `F35`, and simply shows whatever index that key was at the time of previous use. If that index is now occupied by a different key, it silently binds to that new key. If it is possible to store the expected symbol, then load it when a new keycode is activated, rather than only storing the index into the xmodmap, this could avoid the binding juxtapositions. ### Steps to reproduce Here is what it looks like if I open Mumble after pressing the global (F33) then local (F34): ![Image](https://github.com/user-attachments/assets/7d12ceb0-a326-4618-bf06-fb6bd57a2fdd) Then if I close OpenDeck, dropping the Enigo context, these dynamic-bound keys are unmapped; opening Mumble anew shows the raw indecies previously held by these keys at binding time: ![Image](https://github.com/user-attachments/assets/e40da2fa-5f59-4ac4-b1f5-854f2aad02a0) But if I now start OpenDeck anew, then press the buttons in the opposing order, local (F34) then global (F33), then load Mumble, I end up with the following corrupted configuration: ![Image](https://github.com/user-attachments/assets/0caa816a-c123-4177-9b74-ee9e43ffd8c5) ### Mumble version 1.6.0 on master branch and on davidebeatrici:shortcut-data-qdatastream-fix ### Mumble component Client ### OS Linux ### Reproducible? Yes ### Additional information For reproducibility's sake, these OpenDeck bindings look like this: ![Image](https://github.com/user-attachments/assets/85d43ad3-ea84-49c6-b778-6fd32a5d456d) OpenDeck only preserves Enigo contexts long enough to use for PTT (helpful but not required to repro, otherwise unmapping is near-instantaneous) in [this branch](https://github.com/Dessix/OpenDeck/tree/dessix/ptt-fix). ### Relevant log output ```shell ``` ### Screenshots _No response_

deekerman added the

client

bug

GlobalShortcuts

labels

2026-02-20 22:16:39 -05:00

deekerman commented

2026-02-20 22:16:41 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (May 29, 2025):

The use of raw input event IDs for storing shortcuts also makes the settings non-portable across different platforms. I believe the reason it has been chosen to do this way is because Mumble wants to support any kind of key/button on any kind of device and for some of them we might simply not be able to assign a proper "symbol". However, I think the approach of attempting to use a symbolic value first and only using the raw ID as a fallback is a good compromise.

@Krzmbrzl commented on GitHub (May 29, 2025): The use of raw input event IDs for storing shortcuts also makes the settings non-portable across different platforms. I believe the reason it has been chosen to do this way is because Mumble wants to support any kind of key/button on any kind of device and for some of them we might simply not be able to assign a proper "symbol". However, I think the approach of attempting to use a symbolic value first and only using the raw ID as a fallback is a good compromise.