summaryrefslogtreecommitdiff
path: root/dwm.c%3fid%3d712d6639ff8e863560328131bbb92b248dc9cde7?id=89f9905714c1c1b2e8b0...
diff options
context:
space:
mode:
authorChris Down <chris@chrisdown.name>2022-12-07 14:55:08 +0000
committerHiltjo Posthuma <hiltjo@codemadness.org>2022-12-07 23:06:26 +0100
commit89f9905714c1c1b2e8b09986dfbeca15b68d8af8 (patch)
tree6cdaa8ca57ad6edb94136a621edc2200245bcbfe /dwm.c%3fid%3d712d6639ff8e863560328131bbb92b248dc9cde7?id=89f9905714c1c1b2e8b09986dfbeca15b68d8af8
parentba56fe9fea0a28d8184a727a987836a0903e2682 (diff)
grabkeys: Avoid missing events when a keysym maps to multiple keycodes
It's not uncommon for one keysym to map to multiple keycodes. For example, the "play" button on my keyboard sends keycode 172, but my bluetooth headphones send keycode 208, both of which map back to XF86AudioPlay: % xmodmap -pke | grep XF86AudioPlay keycode 172 = XF86AudioPlay XF86AudioPause XF86AudioPlay XF86AudioPause keycode 208 = XF86AudioPlay NoSymbol XF86AudioPlay keycode 215 = XF86AudioPlay NoSymbol XF86AudioPlay This is a problem because the current code only grabs a single one of these keycodes, which means that events for any other keycode also mapping to the bound keysym will not be handled by dwm. In my case, this means that binding XF86AudioPlay does the right thing and correctly handles my keyboard's keys, but does nothing on my headphones. I'm not the only person affected by this, there are other reports[0]. In order to fix this, we look at the mappings between keycodes and keysyms at grabkeys() time and pick out all matching keycodes rather than just the first one. The keypress() side of this doesn't need any changes because the keycode gets converted back to a canonical keysym before any action is taken. 0: https://github.com/cdown/dwm/issues/11
Diffstat (limited to 'dwm.c%3fid%3d712d6639ff8e863560328131bbb92b248dc9cde7?id=89f9905714c1c1b2e8b09986dfbeca15b68d8af8')
0 files changed, 0 insertions, 0 deletions