Some of the multimedia keys on my Lenovo X1 Carbon aren't recognized by xev. Each time I press the "volume down" key, for example, I get an output that looks like:

FocusOut event, serial 34, synthetic NO, window 0x4800001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 34, synthetic NO, window 0x4800001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 34, synthetic NO, window 0x0,
    keys:  2   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   

However, the "key pressing event" is recognized by ACPI. Using acpi_listen gives me an output of:

button/volumedown VOLDN 00000080 00000000 K
button/volumeup VOLUP 00000080 00000000 K

How can I map this to the more classic XF86AudioLowerVolume and other similar keys? If that's impossible, what's the best way to directly map this to a custom script?

  • 1
    The focus events mean that some application, possibly your window manager, is stealing those events (and acting on them), probably because it has bound actions to it. So they are already recognized, and processed. – dirkt Jun 29 '17 at 10:28
  • OK, thanks! I'm using i3 as a window manager. There isn't anything visible (or audible) happening when I press those keys, so I don't know what that could be. Is it possible to know what's stealing the ACPI events? – Ted Jun 29 '17 at 12:09
  • Additional info: using wmctrl -l in addition to xev, I can see that the window 0x4800001 above is the "N/A Event Tester" window from xev. So this doesn't provide any useful info as to what is stealing the event =( – Ted Jun 29 '17 at 12:37
  • 1
    Many desktop environments are setup by default to react on those events, but there's so many variations I have no idea what it is in your case. Googling about volume control keys for i3/Gnome/whatever you use might turn up something. xlsclients might also show more possible culprits, for example, I can see ibus on my system with xlsclients, but not with wmctrl -l. – dirkt Jun 29 '17 at 13:09
  • i3 is not supposed to do any of that, it's a minimalistic window manager. The recommended way to do volume control is through bindings like bindsym XF86AudioRaiseVolume. I looked at the output of xlsclients, and there is nothing there susceptible to steal ACPI events (some shells, and some programs that I all closed to verify that the problem was still there). – Ted Jun 29 '17 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.