I have reported the following bug in the Debian BTS, concerning
tabbed from suckless-tools 46:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018177
On my machine with a reconfigured keypad to give the same behavior of
the digit row of the keyboard (independently of the NumLock status),
Mod-[0..9] works with the keys of the digit row, but not with those
of the keypad.
According to xev:
[1 on the digit row]
state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
[Ctrl-1 on the digit row]
state 0x4, keycode 10 (keysym 0x31, 1), same_screen YES,
[1 on the keypad]
state 0x0, keycode 87 (keysym 0x31, 1), same_screen YES,
XKeysymToKeycode returns keycode: 10
[Ctrl-1 on the keypad]
state 0x4, keycode 87 (keysym 0x31, 1), same_screen YES,
XKeysymToKeycode returns keycode: 10
The bug sems to be the following:
for(i = 0; i < LENGTH(keys); i++) {
if((code = XKeysymToKeycode(dpy, keys[i].keysym))) {
for(j = 0; j < LENGTH(modifiers); j++) {
XGrabKey(dpy, code, keys[i].mod
| modifiers[j], w,
True, GrabModeAsync,
GrabModeAsync);
}
}
}
So this will grab only what XKeysymToKeycode gives, thus for 1, it
is keycode 10, which corresponds to the key 1 on the digit row, and
keycode 87 (on the keypad) is ignored.
Instead of the above code, shouldn't it enumerate keycodes and look
for all those that match a wanted keysym?
--
Vincent Lefèvre <vincent_AT_vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Received on Sat Aug 27 2022 - 02:09:06 CEST