Keyboard shortcuts don't work on Wayland #2294

Open
opened 2026-02-20 22:03:50 -05:00 by deekerman · 41 comments
Owner

Originally created by @Krzmbrzl on GitHub (Sep 7, 2021).

Describe the bug
When using Wayland instead of X11, the global shortcut engine does not work and as a consequence none of the user-registered shortcuts function.

Steps to Reproduce
Steps to reproduce the behavior:

  1. Use Wayland
  2. Try to use or register a shortcut

Expected behavior
Shortcuts to work normally

Desktop (please complete the following information):

  • OS: Linux (Wayland)
  • Version: all

Additional context
To my knowledge to this date Wayland (in contrast to X11) does not provide a way to either grab all user input nor does it allow to register global shortcuts. Instead one is supposed to register shortcuts with the currently used Window Manager (but there does not seem to exist a standard to do this).

Related issues: #3816 #3243 #4073 #5303

Originally created by @Krzmbrzl on GitHub (Sep 7, 2021). **Describe the bug** When using Wayland instead of X11, the global shortcut engine does not work and as a consequence none of the user-registered shortcuts function. **Steps to Reproduce** Steps to reproduce the behavior: 1. Use Wayland 2. Try to use or register a shortcut **Expected behavior** Shortcuts to work normally **Desktop (please complete the following information):** - OS: Linux (Wayland) - Version: all **Additional context** To my knowledge to this date Wayland (in contrast to X11) does not provide a way to either grab all user input nor does it allow to register global shortcuts. Instead one is supposed to register shortcuts with the currently used Window Manager (but there does not seem to exist a standard to do this). Related issues: #3816 #3243 #4073 #5303
Author
Owner

@davidebeatrici commented on GitHub (Sep 7, 2021):

#3269

@davidebeatrici commented on GitHub (Sep 7, 2021): #3269
Author
Owner

@icher commented on GitHub (Jan 22, 2022):

Well, when I used 1.3.4 I can define hotkey for Push-to-talk and use it when Mumble window is focused. You can't use it in games whatever, but it's worked when you just want to talk. In 1.4 I can't do that. What should I do to use Push-to-talk when Mumble window is active at least?

@icher commented on GitHub (Jan 22, 2022): Well, when I used 1.3.4 I can define hotkey for Push-to-talk and use it when Mumble window is focused. You can't use it in games whatever, but it's worked when you just want to talk. In 1.4 I can't do that. What should I do to use Push-to-talk when Mumble window is active at least?
Author
Owner

@Krzmbrzl commented on GitHub (Jan 22, 2022):

ATM there is no way around it. But there is already a ticket about weakening the disabling of shortcuts on Wayland.

@Krzmbrzl commented on GitHub (Jan 22, 2022): ATM there is no way around it. But there is already a ticket about weakening the disabling of shortcuts on Wayland.
Author
Owner

@trthomps commented on GitHub (Jan 28, 2022):

I was using PTT successfully in 1.3.4 as long as my mouse had focus on an X app (i.e. most games right now). Would be nice to restore that behavior until global shortcuts are fixed in Wayland.

@trthomps commented on GitHub (Jan 28, 2022): I was using PTT successfully in 1.3.4 as long as my mouse had focus on an X app (i.e. most games right now). Would be nice to restore that behavior until global shortcuts are fixed in Wayland.
Author
Owner

@segmentati0nf4ult commented on GitHub (Feb 8, 2022):

Same here. It was working before, but with one of the last upgrades it seems that the functionality was disabled on purpose. I was able to use it successfully while focusing on a X Window.

@segmentati0nf4ult commented on GitHub (Feb 8, 2022): Same here. It was working before, but with one of the last upgrades it seems that the functionality was disabled on purpose. I was able to use it successfully while focusing on a X Window.
Author
Owner

@Nothankslads commented on GitHub (Apr 19, 2022):

Has there been any progress on this?

@Nothankslads commented on GitHub (Apr 19, 2022): Has there been any progress on this?
Author
Owner

@Krzmbrzl commented on GitHub (Apr 20, 2022):

No

@Krzmbrzl commented on GitHub (Apr 20, 2022): No
Author
Owner

@jsparber commented on GitHub (May 17, 2022):

What should I do to use Push-to-talk when Mumble window is active at least?

@icher You can enable "Display push to talk window" to get a extra window with a button. It's not great but better then nothing.

image

@jsparber commented on GitHub (May 17, 2022): > What should I do to use Push-to-talk when Mumble window is active at least? @icher You can enable "Display push to talk window" to get a extra window with a button. It's not great but better then nothing. ![image](https://user-images.githubusercontent.com/1911029/168845364-ed673c19-cc9a-49a4-bb3a-25b4d74a54b2.png)
Author
Owner

@icher commented on GitHub (May 21, 2022):

@icher You can enable "Display push to talk window" to get a extra window with a button. It's not great but better then nothing.

Nah, it's not usable. I just downgrade to 1.3.4 and run as QT_QPA_PLATFORM=xcb mumble.

@icher commented on GitHub (May 21, 2022): > @icher You can enable "Display push to talk window" to get a extra window with a button. It's not great but better then nothing. Nah, it's not usable. I just downgrade to 1.3.4 and run as `QT_QPA_PLATFORM=xcb mumble`.
Author
Owner

@bovinespongiformflu commented on GitHub (May 21, 2022):

Please restore old functionality, having it disabled entirely isnt helping anyone and it still worked fine in proton/x games.
edit:
https://github.com/mumble-voip/mumble/pull/5688 i see there is already a plan to restore functionality. do we know when this will be merged?

@bovinespongiformflu commented on GitHub (May 21, 2022): Please restore old functionality, having it disabled entirely isnt helping anyone and it still worked fine in proton/x games. edit: https://github.com/mumble-voip/mumble/pull/5688 i see there is already a plan to restore functionality. do we know when this will be merged?
Author
Owner

@tidux commented on GitHub (Oct 15, 2022):

A workaround is to use the RPC client to map keys to commands in your WM/DE, although you do need to dedicate two keybinds for it:

mumble rpc starttalking and mumble rpc stoptalking do what you'd expect for PTT.

@tidux commented on GitHub (Oct 15, 2022): A workaround is to use the RPC client to map keys to commands in your WM/DE, although you do need to dedicate two keybinds for it: `mumble rpc starttalking` and `mumble rpc stoptalking` do what you'd expect for PTT.
Author
Owner

@travismorton commented on GitHub (Nov 9, 2022):

I've been running a hacky workaround using the mumble D-Bus API and libinput. As long as your user is part of the input group you can listen for mouse/keyboard down/up events and forward them to the startTalking and stopTalking D-Bus methods. Here's the script I run in the background. It will enable PTT when BTN_EXTRA is pushed.

Before this I was using Sway's bindsym to emit the D-Bus calls similar to what @tidux suggested, but events would get dropped based on where the mouse was. Going directly to libinput helped me avoid the dropped button-up events which caused state issues and an always-on mic sometimes. It also doesn't depend on focus being on an X window for PTT to work.

@travismorton commented on GitHub (Nov 9, 2022): I've been running a hacky workaround using the mumble D-Bus API and `libinput`. As long as your user is part of the `input` group you can listen for mouse/keyboard down/up events and forward them to the `startTalking` and `stopTalking` D-Bus methods. Here's the [script](https://gist.github.com/travismorton/aef78d9f25c690baa769b9110ee896a6) I run in the background. It will enable PTT when BTN_EXTRA is pushed. Before this I was using Sway's `bindsym` to emit the D-Bus calls similar to what @tidux suggested, but events would get dropped based on where the mouse was. Going directly to `libinput` helped me avoid the dropped button-up events which caused state issues and an always-on mic sometimes. It also doesn't depend on focus being on an X window for PTT to work.
Author
Owner

@carlocastoldi commented on GitHub (Nov 9, 2022):

i love your script, @travismorton. Thanks a lot!

I think it removes the security of Wayland from possible keyloggers, but it's a price i'm ready to pay. Even more as I expect it to be a temporary solution. At least until a shortcuts xdg-portal is not finalized.

P.S. do you have a way to pin a particular /dev/input/event* to the same path?

@carlocastoldi commented on GitHub (Nov 9, 2022): i love your script, @travismorton. Thanks a lot! I think it removes the security of Wayland from possible keyloggers, but it's a price i'm ready to pay. Even more as I expect it to be a temporary solution. At least until a shortcuts xdg-portal is not finalized. P.S. do you have a way to pin a particular `/dev/input/event*` to the same path?
Author
Owner

@travismorton commented on GitHub (Nov 9, 2022):

Good point, I should have mentioned the possible security hole in adding your user to the input group. There's more nuanced ways to do that which involve udev rules and logind as mentioned in this reddit thread, although they don't completely solve the issue, just limit the blast radius.

After you mentioned pinning the event path I changed the script to fetch the context based on libinput seat rather than path. Assuming your DE/WM doesn't create multiple seats this should always be seat0 (as far as my limited understanding goes) and shouldn't change. The gist is updated as well, hopefully that accomplishes what you're looking for?

@travismorton commented on GitHub (Nov 9, 2022): Good point, I should have mentioned the possible security hole in adding your user to the `input` group. There's more nuanced ways to do that which involve udev rules and logind as mentioned in [this](https://old.reddit.com/r/linuxquestions/comments/bh4ex1/is_adding_a_user_to_input_group_secure/elq3uvk/) reddit thread, although they don't completely solve the issue, just limit the blast radius. After you mentioned pinning the event path I changed the script to fetch the context based on `libinput` seat rather than path. Assuming your DE/WM doesn't create multiple seats this should always be `seat0` (as far as my limited understanding goes) and shouldn't change. The gist is updated as well, hopefully that accomplishes what you're looking for?
Author
Owner

@carlocastoldi commented on GitHub (Nov 10, 2022):

here's more nuanced ways to do that which involve udev rules and logind as mentioned in this reddit thread

I was indeed wondering if we couldn't do some udev rule magic!

although they don't completely solve the issue, just limit the blast radius

it limits the "keylogging capabilities" to the device you want to bind PTT to, right? Or is the blast radius wider?

The gist is updated as well, hopefully that accomplishes what you're looking for?

It does! It's awesome, thanks!

P.S.: for anyone on Arch (or derivates), here is the PKGBUILD for python-libinput

@carlocastoldi commented on GitHub (Nov 10, 2022): > here's more nuanced ways to do that which involve udev rules and logind as mentioned in [this](https://old.reddit.com/r/linuxquestions/comments/bh4ex1/is_adding_a_user_to_input_group_secure/elq3uvk/) reddit thread I was indeed wondering if we couldn't do some udev rule magic! > although they don't completely solve the issue, just limit the blast radius it limits the "keylogging capabilities" to the device you want to bind PTT to, right? Or is the blast radius wider? > The gist is updated as well, hopefully that accomplishes what you're looking for? It does! It's awesome, thanks! P.S.: for anyone on Arch (or derivates), here is the [PKGBUILD](https://gist.github.com/carlocastoldi/a1428834fd2d847a6ce378999d64d207) for `python-libinput`
Author
Owner

@ananace commented on GitHub (Nov 20, 2022):

There is the XDG global shortcut portal API (PR, Docs) which should also allow for binding global shortcuts on Wayland in a DE-agnostic way - though with a bit of DBus work, unfortunately it's not actually available in any released version of KDE/GNOME yet, so it'll probably be a while until it can be used.

@ananace commented on GitHub (Nov 20, 2022): There is the XDG global shortcut portal API ([PR](https://github.com/flatpak/xdg-desktop-portal/pull/711), [Docs](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.GlobalShortcuts)) which should also allow for binding global shortcuts on Wayland in a DE-agnostic way - though with a bit of DBus work, unfortunately it's not actually available in any released version of KDE/GNOME yet, so it'll probably be a while until it can be used.
Author
Owner

@RichardFevrier commented on GitHub (Oct 6, 2023):

Will it be possible to use only one key to bind the Push To Talk functionality?

@RichardFevrier commented on GitHub (Oct 6, 2023): Will it be possible to use only one key to bind the Push To Talk functionality?
Author
Owner

@Krzmbrzl commented on GitHub (Oct 6, 2023):

I'm not sure if I understand your question correctly, but binding a single key requires the same infrastructure as binding multiples - Aka: it currently doesn't work properly on Wayland as the current shortcut implementation relies on being notified of all input events (essentially a key logger), which is not possible on Wayland.

@Krzmbrzl commented on GitHub (Oct 6, 2023): I'm not sure if I understand your question correctly, but binding a single key requires the same infrastructure as binding multiples - Aka: it currently doesn't work properly on Wayland as the current shortcut implementation relies on being notified of _all_ input events (essentially a key logger), which is not possible on Wayland.
Author
Owner

@RichardFevrier commented on GitHub (Oct 6, 2023):

I meant; will the xdg-desktop-portal GlobalShortcuts lets mumble users to use only a single key for the Push to Talk functionality when everything will be implemented?

@RichardFevrier commented on GitHub (Oct 6, 2023): I meant; will the xdg-desktop-portal GlobalShortcuts lets mumble users to use only a single key for the Push to Talk functionality when everything will be implemented?
Author
Owner

@Krzmbrzl commented on GitHub (Oct 6, 2023):

Ah 💡
Yes I would expect so. The hope would be for this change to be completely transparent such that the user doesn't notice whether they are using Mumble with X11 or with Wayland.

@Krzmbrzl commented on GitHub (Oct 6, 2023): Ah :bulb: Yes I would expect so. The hope would be for this change to be completely transparent such that the user doesn't notice whether they are using Mumble with X11 or with Wayland.
Author
Owner

@RichardFevrier commented on GitHub (Oct 6, 2023):

Maybe @aleixpol would know 🙂

@RichardFevrier commented on GitHub (Oct 6, 2023): Maybe @aleixpol would know 🙂
Author
Owner

@aleixpol commented on GitHub (Oct 7, 2023):

Yes, it's possible to use a single key for push to talk as does this PR, it's not something theoretical.

@aleixpol commented on GitHub (Oct 7, 2023): Yes, it's possible to use a single key for push to talk as does this PR, it's not something theoretical.
Author
Owner

@jp-bennett commented on GitHub (Nov 5, 2023):

KDE has added "Legacy X11 App Support" to the system settings when running under Wayland, and one of the options is to allow applications to read keystrokes again. This completely fixes push-to-talk support on Fedora. There is a merge request (https://invent.kde.org/plasma/kwin/-/merge_requests/4595) to extend this system to also send mouse button presses.

@jp-bennett commented on GitHub (Nov 5, 2023): KDE has added "Legacy X11 App Support" to the system settings when running under Wayland, and one of the options is to allow applications to read keystrokes again. This completely fixes push-to-talk support on Fedora. There is a merge request (https://invent.kde.org/plasma/kwin/-/merge_requests/4595) to extend this system to also send mouse button presses.
Author
Owner

@CmdrMoozy commented on GitHub (Mar 2, 2024):

Note that for now at least the "Legacy X11 App Support" only seems to work for keyboard shortcuts. For mouse button support, it appears KDE 6.1 will be needed: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg889735.html

@CmdrMoozy commented on GitHub (Mar 2, 2024): Note that for now at least the "Legacy X11 App Support" only seems to work for keyboard shortcuts. For mouse button support, it appears KDE 6.1 will be needed: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg889735.html
Author
Owner

@Mikilio commented on GitHub (Mar 26, 2024):

I use hyprland and in a very wayland like way I let the compositor handle global shortcuts for me by sending it to the mumble application. I believe that also in the future, global shortcuts should be handled by the compositor. Maybe we can ask freedesktop to make a standard configuration format for this. That way, mumble can suggest configurations that work independent of the compositor. This way there are no security compromises as the user will be conscious of all changes.

@Mikilio commented on GitHub (Mar 26, 2024): I use hyprland and in a very wayland like way I let the compositor handle global shortcuts for me by sending it to the mumble application. I believe that also in the future, global shortcuts should be handled by the compositor. Maybe we can ask freedesktop to make a standard configuration format for this. That way, mumble can suggest configurations that work independent of the compositor. This way there are no security compromises as the user will be conscious of all changes.
Author
Owner

@Ases commented on GitHub (Jun 18, 2024):

Note that for now at least the "Legacy X11 App Support" only seems to work for keyboard shortcuts. For mouse button support, it appears KDE 6.1 will be needed: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg889735.html

I confirm that the Push To Talk with a mouse button is now functional under KDE Plasma 6.1 configuring the Legacy X11 App Support. 🎉

@Ases commented on GitHub (Jun 18, 2024): > Note that for now at least the "Legacy X11 App Support" only seems to work for keyboard shortcuts. For mouse button support, it appears KDE 6.1 will be needed: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg889735.html I confirm that the Push To Talk with a mouse button is now functional under KDE Plasma 6.1 configuring the Legacy X11 App Support. :tada:
Author
Owner

@BadCo-NZ commented on GitHub (Jun 21, 2024):

Note that for now at least the "Legacy X11 App Support" only seems to work for keyboard shortcuts. For mouse button support, it appears KDE 6.1 will be needed: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg889735.html

I confirm that the Push To Talk with a mouse button is now functional under KDE Plasma 6.1 configuring the Legacy X11 App Support. 🎉

How did you do this? Mumble flatpak crashes for me on Fedora Kinoite when I enable Global Shortcuts.

@BadCo-NZ commented on GitHub (Jun 21, 2024): > > Note that for now at least the "Legacy X11 App Support" only seems to work for keyboard shortcuts. For mouse button support, it appears KDE 6.1 will be needed: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg889735.html > > I confirm that the Push To Talk with a mouse button is now functional under KDE Plasma 6.1 configuring the Legacy X11 App Support. 🎉 How did you do this? Mumble flatpak crashes for me on Fedora Kinoite when I enable Global Shortcuts.
Author
Owner

@Ases commented on GitHub (Jun 21, 2024):

Note that for now at least the "Legacy X11 App Support" only seems to work for keyboard shortcuts. For mouse button support, it appears KDE 6.1 will be needed: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg889735.html

I confirm that the Push To Talk with a mouse button is now functional under KDE Plasma 6.1 configuring the Legacy X11 App Support. 🎉

How did you do this? Mumble flatpak crashes for me on Fedora Kinoite when I enable Global Shortcuts.

I'm currently using Mumble v1.5.517 from snapcrafters on KDE neon.
Although I'm not a fan of snaps and generally avoid them, I wanted
to try it.
I then simply configured "Legacy X11 App Support" without any special adjustments.

@Ases commented on GitHub (Jun 21, 2024): > > > Note that for now at least the "Legacy X11 App Support" only seems to work for keyboard shortcuts. For mouse button support, it appears KDE 6.1 will be needed: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg889735.html > > > > > > I confirm that the Push To Talk with a mouse button is now functional under KDE Plasma 6.1 configuring the Legacy X11 App Support. 🎉 > > How did you do this? Mumble flatpak crashes for me on Fedora Kinoite when I enable Global Shortcuts. I'm currently using Mumble v1.5.517 from snapcrafters on KDE neon. Although I'm not a fan of snaps and generally avoid them, I wanted to try it. I then simply configured "Legacy X11 App Support" without any special adjustments.
Author
Owner

@trthomps commented on GitHub (Jun 21, 2024):

I can also confirm it's been working for a while on Arch Linux with the system packages.

@trthomps commented on GitHub (Jun 21, 2024): I can also confirm it's been working for a while on Arch Linux with the system packages.
Author
Owner

@aleixpol commented on GitHub (Jun 21, 2024):

Please don't consider the issue as addressed with the "Legacy X11 app support". Because it's only for X11 and effectively a backwards-compatibility workaround, not the right way to support it on Wayland.
https://github.com/mumble-voip/mumble/pull/5976

@aleixpol commented on GitHub (Jun 21, 2024): Please don't consider the issue as addressed with the "Legacy X11 app support". Because it's only for X11 and effectively a backwards-compatibility workaround, not the right way to support it on Wayland. https://github.com/mumble-voip/mumble/pull/5976
Author
Owner

@dotbanana commented on GitHub (Oct 18, 2024):

So after all those years this is still not working yes?
Is mumble dead?

@dotbanana commented on GitHub (Oct 18, 2024): So after all those years this is still not working yes? Is mumble dead?
Author
Owner

@omnigenous commented on GitHub (Nov 12, 2024):

@Mikilio I'm also on hyprland, did you find a workaround?

@omnigenous commented on GitHub (Nov 12, 2024): @Mikilio I'm also on hyprland, did you find a workaround?
Author
Owner

@IDDQD69 commented on GitHub (Nov 12, 2024):

@Mikilio I'm also on hyprland, did you find a workaround?

Hyprland works just fine for me:

input {
...
kb_options = caps:none

}

bind = , VoidSymbol, pass, ^(info.mumble.Mumble)$
bind = , VoidSymbol, pass, ^(discord)$

worked just fine

@IDDQD69 commented on GitHub (Nov 12, 2024): > @Mikilio I'm also on hyprland, did you find a workaround? Hyprland works just fine for me: input { ... kb_options = caps:none } bind = , VoidSymbol, pass, ^(info\.mumble\.Mumble)$ bind = , VoidSymbol, pass, ^(discord)$ worked just fine
Author
Owner

@omnigenous commented on GitHub (Nov 12, 2024):

@IDDQD69 this is really bizarre, I have same key (F10) to mute mic both in mumble and teamspeak. So when teamspeak is open along side mumble F10 to mute mic works in both teamspeak and mumble and I even removed global pass with mumbles class and it still worked with this for mumble:

bind = , F10, pass, ^(TeamSpeak)$

So apparently global keybind is leaking to other apps beside teamspeak unless I'm missing something.

Do you know if teamspeak starting something in background to make global keybind work? I want to be able to have only mumble open and use mute keybind.

@omnigenous commented on GitHub (Nov 12, 2024): @IDDQD69 this is really bizarre, I have same key (`F10`) to mute mic both in mumble and teamspeak. So when teamspeak is open along side mumble `F10` to mute mic works in both teamspeak and mumble and I even removed global pass with mumbles class and it still worked with this for mumble: ``` bind = , F10, pass, ^(TeamSpeak)$ ``` So apparently global keybind is leaking to other apps beside teamspeak unless I'm missing something. Do you know if teamspeak starting something in background to make global keybind work? I want to be able to have only mumble open and use mute keybind.
Author
Owner

@IDDQD69 commented on GitHub (Nov 12, 2024):

@IDDQD69 this is really bizarre, I have same key (F10) to mute mic both in mumble and teamspeak. So when teamspeak is open along side mumble F10 to mute mic works in both teamspeak and mumble and I even removed global pass with mumbles class and it still worked with this for mumble:

bind = , F10, pass, ^(TeamSpeak)$

So apparently global keybind is leaking to other apps beside teamspeak unless I'm missing something.

Do you know if teamspeak starting something in background to make global keybind work? I want to be able to have only mumble open and use mute keybind.

if they both use X, then they probably "hear" all the keypresses that are binded for any other X app? I really have no idea how any of this really works :D

@IDDQD69 commented on GitHub (Nov 12, 2024): > @IDDQD69 this is really bizarre, I have same key (`F10`) to mute mic both in mumble and teamspeak. So when teamspeak is open along side mumble `F10` to mute mic works in both teamspeak and mumble and I even removed global pass with mumbles class and it still worked with this for mumble: > > ``` > bind = , F10, pass, ^(TeamSpeak)$ > ``` > > So apparently global keybind is leaking to other apps beside teamspeak unless I'm missing something. > > Do you know if teamspeak starting something in background to make global keybind work? I want to be able to have only mumble open and use mute keybind. if they both use X, then they probably "hear" all the keypresses that are binded for any other X app? I really have no idea how any of this really works :D
Author
Owner

@danielwerg commented on GitHub (Jan 10, 2025):

I'm on hyprland and also has this issue. I only needed to mute and deafen so thankfully to mumble rpc I could bind those commands instead of using [global] keybinds!

mumble rpc togglemute
mumble rpc toggledeaf
@danielwerg commented on GitHub (Jan 10, 2025): I'm on hyprland and also has this issue. I only needed to mute and deafen so thankfully to mumble rpc I could bind those commands instead of using [global] keybinds! ```sh mumble rpc togglemute mumble rpc toggledeaf ```
Author
Owner

@Fifthdread commented on GitHub (Feb 18, 2025):

I run the Flatpack version of Mumble and I had to create the custom kde shortcut to get a global hotkey to work for me, as well as force Mumble to launch via x11.

Forcing it to run via x11 was easy, as I just edited the Mumble settings with Flatseal to disable Wayland windowing system.

This is the kde shortcut I created- flatpak run info.mumble.Mumble rpc togglemute

... jank, but it works.

@Fifthdread commented on GitHub (Feb 18, 2025): I run the Flatpack version of Mumble and I had to create the custom kde shortcut to get a global hotkey to work for me, as well as force Mumble to launch via x11. Forcing it to run via x11 was easy, as I just edited the Mumble settings with Flatseal to disable Wayland windowing system. This is the kde shortcut I created- `flatpak run info.mumble.Mumble rpc togglemute` ... jank, but it works.
Author
Owner

@julien9808 commented on GitHub (Mar 15, 2025):

with Gnome, disable Wayland windowing system works in Flatseal works for me too

@julien9808 commented on GitHub (Mar 15, 2025): with Gnome, disable Wayland windowing system works in Flatseal works for me too
Author
Owner

@steveyh25 commented on GitHub (Oct 19, 2025):

making the app run as x11 and enabling legacy X11 support makes mumble work again, but I've noticed that discord does not have this problem and runs as a wayland app so a solution must be possible

@steveyh25 commented on GitHub (Oct 19, 2025): making the app run as x11 and enabling legacy X11 support makes mumble work again, but I've noticed that discord does not have this problem and runs as a wayland app so a solution must be possible
Author
Owner

@Krzmbrzl commented on GitHub (Oct 20, 2025):

a solution must be possible

It's possible. We "only" need to use the xdg-portal way of doing shortcuts, which is the intended way of handling global shortcuts under Wayland. The problem is that this is a very much non-trivial change for which we haven't found the time yet. There is #5976 but the same things apply to that: not enough resources have been found for getting it done.

@Krzmbrzl commented on GitHub (Oct 20, 2025): > a solution must be possible It's possible. We "only" need to use the xdg-portal way of doing shortcuts, which is the intended way of handling global shortcuts under Wayland. The problem is that this is a very much non-trivial change for which we haven't found the time yet. There is #5976 but the same things apply to that: not enough resources have been found for getting it done.
Author
Owner

@kooltux commented on GitHub (Jan 5, 2026):

Maybe already mentioned somewhere, but this is something I tested today successfully on openSUSE Leap 16.0 : defining a shortcut in Gnome keyboard settings (settings->keyboard->view and customize shortcuts->custom shortcuts) to run /usr/bin/mumble rpc togglemute

@kooltux commented on GitHub (Jan 5, 2026): Maybe already mentioned somewhere, but this is something I tested today successfully on openSUSE Leap 16.0 : defining a shortcut in Gnome keyboard settings (settings->keyboard->view and customize shortcuts->custom shortcuts) to run `/usr/bin/mumble rpc togglemute`
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mumble-mumble-voip#2294
No description provided.