💾 Archived View for log.aviary.biz › 2022-01-03.gmi captured on 2024-05-12 at 15:10:43. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-01-08)
-=-=-=-=-=-=-
i don't recall a time where pressing my volume keys *didn't* print garbage onto my terminal. today, i decided to do something about it.
% sndioctl output.level output.level=0.745 % [57439u^C # i pressed the "more volume" key. gah! % sndioctl output.level output.level=0.776
to start, i wanted to try blocking this key from my window manager, i3. i3 lets you bind keys to actions, and i figured i could at least make a key do nothing. i used xev(1) to tell me how to refer to these keys. i ran xev in a terminal, when focused the new X client that spawned, and pressed my volume keys. xev gave me this output:
KeyPress event, serial 31, synthetic NO, window 0x1000001, root 0x7af, subw 0x0, time 17386103, (61,-47), root:(1025,686), state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 34, synthetic NO, window 0x1000001, root 0x7af, subw 0x0, time 17386190, (61,-47), root:(1025,686), state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 34, synthetic NO, window 0x1000001, root 0x7af, subw 0x0, time 17387821, (61,-47), root:(1025,686), state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 34, synthetic NO, window 0x1000001, root 0x7af, subw 0x0, time 17387955, (61,-47), root:(1025,686), state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 34, synthetic NO, window 0x1000001, root 0x7af, subw 0x0, time 17388822, (61,-47), root:(1025,686), state 0x0, keycode 160 (keysym 0x1008ff12, XF86AudioMute), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 34, synthetic NO, window 0x1000001, root 0x7af, subw 0x0, time 17388917, (61,-47), root:(1025,686), state 0x0, keycode 160 (keysym 0x1008ff12, XF86AudioMute), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
from this i knew to refer to these keys as XF86AudioRaiseVolume, XF86AudioLowerVolume and XF86AudioMute. i wrote i3 config like this:
bindsym XF86AudioRaiseVolume exec true bindsym XF86AudioLowerVolume exec true bindsym XF86AudioMute exec true
and it worked! but this was kinda unsatisfying. it seems that the operating system already handles these keypresses. indeed, these keys have worked to change my volume since i installed openbsd a few years ago. i think this works because the acpi(4) driver supports my hardware out of the box. if this is true, i don't even want the window manager to get these keys.
while perusing the i3 docs, i found mention of xmodmap(1). i found the keycodes that correspond to the keys.
% xmodmap -pke | egrep 'XF86Audio(RaiseVolume|LowerVolume|Mute)' keycode 160 = XF86AudioMute NoSymbol XF86AudioMute keycode 174 = XF86AudioLowerVolume NoSymbol XF86AudioLowerVolume keycode 176 = XF86AudioRaiseVolume NoSymbol XF86AudioRaiseVolume
after fiddling with the command syntax, i wrote these lines in my ~/.xsession:
keymap () { # silence volume buttons; they are handled by acpithinkpad(4) /usr/X11R6/bin/xmodmap -e 'keycode 174 =' /usr/X11R6/bin/xmodmap -e 'keycode 176 =' /usr/X11R6/bin/xmodmap -e 'keycode 160 =' } keymap
i don't know if this is the "right" way to do things, and i don't care! i'm just happy to understand a little more how my computer works.