push-to-talk not working with some media keys #1829

New issue

Open

opened 2026-02-20 21:15:18 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-20 21:15:18 -05:00

Owner

Originally created by @xorbug on GitHub (May 6, 2020).

Hi all, forwarding from the Debian BTS [0]:

Dear Maintainer,

some multimedia keys are not working when bound to the push-to-talk
shortcut, but some of them do work fine.

For example the ThinkVantage button on a Thinkpad x230 keyboard
generates XF86Launch1 keysym. Output from xev:
KeyPress event, serial 34, synthetic NO, window 0x1600001,
    root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
    state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x1600001,
    root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374),
    state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
The key is correctly detected and saved (as XF86Launch1) by the
shortcut setting dialog in mumble, but when pushing it, the voice is
not activated.
Also, there should be no interference by the rest of the system, since
this button, but also all other media keys i chose for testing, are
not used by the window manager, nor by any running application.

The same for e.g. XF86Display. Other media keys such as XF86AudioPlay
instead, work as expected, as all other "standard" keys do, afaict.

[...]

If needed, details on the system available at the original bug page [0].
Thanks everyone.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958059

Originally created by @xorbug on GitHub (May 6, 2020). Hi all, forwarding from the Debian BTS [0]: > Dear Maintainer, > > some multimedia keys are not working when bound to the push-to-talk > shortcut, but some of them do work fine. > > For example the ThinkVantage button on a Thinkpad x230 keyboard > generates XF86Launch1 keysym. Output from xev: > > ``` > KeyPress event, serial 34, synthetic NO, window 0x1600001, > root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374), > state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 0 bytes: > XFilterEvent returns: False > > KeyRelease event, serial 34, synthetic NO, window 0x1600001, > root 0x147, subw 0x0, time 1969174503, (263,75), root:(266,1374), > state 0x0, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES, > XLookupString gives 0 bytes: > XFilterEvent returns: False > > ``` > The key is correctly detected and saved (as XF86Launch1) by the > shortcut setting dialog in mumble, but when pushing it, the voice is > not activated. > Also, there should be no interference by the rest of the system, since > this button, but also all other media keys i chose for testing, are > not used by the window manager, nor by any running application. > > The same for e.g. XF86Display. Other media keys such as XF86AudioPlay > instead, work as expected, as all other "standard" keys do, afaict. > > [...] If needed, details on the system available at the original bug page [0]. Thanks everyone. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958059

deekerman added the

client

bug

GlobalShortcuts

labels

2026-02-20 21:15:18 -05:00

deekerman commented

2026-02-20 21:15:21 -05:00

Author

Owner

@ghost commented on GitHub (Feb 15, 2023):

Has this been tested with 1.4 or backported to Debian 10?

@ghost commented on GitHub (Feb 15, 2023): Has this been tested with 1.4 or backported to Debian 10?

deekerman commented

2026-02-20 21:15:21 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Feb 16, 2023):

I would assume this to still be the case as we have not changed anything in the shortcut handling on Linux (that could go in the direction of fixing this) 🤔

@Krzmbrzl commented on GitHub (Feb 16, 2023): I would assume this to still be the case as we have not changed anything in the shortcut handling on Linux (that could go in the direction of fixing this) :thinking: