You are not logged in.
Pages: 1
Hello,
I am trying to get my multimedia keys to work. I don't know why, but all the "music" keys (next, prev, pause, ...) work, but nothing related to sound.
Here is the output of xinput:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ HID-compliant Mouse HID-compliant Mouse id=9 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ Eee PC WMI hotkeys id=13 [slave keyboard (3)]
↳ USB Keyboard id=10 [slave keyboard (3)]
↳ USB Keyboard Consumer Control id=11 [slave keyboard (3)]
↳ USB Keyboard System Control id=12 [slave keyboard (3)]
Here is the output of setxkbmap -print -query
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
rules: evdev
model: pc105
layout: us
Thank you very much in advance for any help.
Last edited by Scriptor (2020-05-23 14:47:15)
Offline
Does not work "how"?
Do they produce output in xev or "sudo libinput debug-events"?
What are they bound to (xbindkeys, some DE shortcut handler)?
Offline
Hello,
Thank you for your quick reply. Here is the output from xev when trying to perform a "mute" key:
FocusOut event, serial 32, synthetic NO, window 0x3600001,
mode NotifyGrab, detail NotifyAncestor
FocusOut event, serial 32, synthetic NO, window 0x3600001,
mode NotifyUngrab, detail NotifyPointer
FocusIn event, serial 32, synthetic NO, window 0x3600001,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 32, synthetic NO, window 0x0,
keys: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
What seems strange is that sudo libinput debug-events seems to recognize the key.
When the keys work I can see XF86.... But here I don't see anything.
Thank you very much for your help.
Last edited by Scriptor (2020-05-23 15:10:23)
Offline
Thats typical for a passive keyboard grab, so
a) the key works
b) some daemon holds a grab on it (you'll have to elaborate on your setup here)
c) apparently that daemon does not what you want it to do (mute the speaker)
Offline
Hello,
Thats typical for a passive keyboard grab, so
a) the key works
b) some daemon holds a grab on it (you'll have to elaborate on your setup here)
c) apparently that daemon does not what you want it to do (mute the speaker)
So if I understand well, I need to find the daemon responsible for this behavior ?
Thank you very much for your help.
Offline
Yes.
xdotool key "XF86LogGrabInfo"
will dump all grabs into the xorg log.
It should be easier to spot if you delay (sleep 5) the call and press (and hold) the relevant key over its execution because the grab will likely turn active.
Offline
Yes.
xdotool key "XF86LogGrabInfo"
will dump all grabs into the xorg log.
It should be easier to spot if you delay (sleep 5) the call and press (and hold) the relevant key over its execution because the grab will likely turn active.
I'm really sorry but I'm not quite sure to understand how this work. I'm not sure what to do after executing xdotool key "XF86LogGrabInfo".
Thank you for your time and patience.
Offline
The key is a server shortcut that prints all grabs into the xorg log. The position of that depends on your setup, see https://wiki.archlinux.org/index.php/Xo … leshooting
The list will hint what keycodes are grabbed by which client, but if you didn't set up an external daemon like xbindkeys, this will likely be some part of your desktop environment (kde, gnome, xfce and even fluxbox and openbox have their own global shortcut systems built in)
Offline
Pages: 1