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 <vinc...@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)
