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 /.hgtags | |
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 '.hgtags')
0 files changed, 0 insertions, 0 deletions