diff options
author | Chris Down <chris@chrisdown.name> | 2022-12-07 14:55:08 +0000 |
---|---|---|
committer | Hiltjo Posthuma <hiltjo@codemadness.org> | 2022-12-07 23:06:26 +0100 |
commit | 89f9905714c1c1b2e8b09986dfbeca15b68d8af8 (patch) | |
tree | 6cdaa8ca57ad6edb94136a621edc2200245bcbfe /config.mk | |
parent | ba56fe9fea0a28d8184a727a987836a0903e2682 (diff) | |
download | dwm-89f9905714c1c1b2e8b09986dfbeca15b68d8af8.tar.gz |
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 'config.mk')
0 files changed, 0 insertions, 0 deletions