On Thu, Nov 03, 2016 at 01:22:03PM +0100, Mariusz Mazur wrote: > What I did: > 1. Switched the overlay key to act as a modifier. > interpret Overlay1_Enable+AnyOfOrNone(all) { > - action= LockControls(controls=Overlay1); > + action= SetControls(controls=Overlay1); > > 2. Bound it to caps lock. > 3. Defined caps+hjkl to act as arrow keys. > 4. Defined caps+f to send XF86LaunchA to start a new terminal window > (among other similar shortcuts, like ones for switching virtual > desktops, but caps+f is the worst offender, so I'll focus on that).
Nice hack. > It would seem using the overlay mechanism the way I do messes with > whatever mechanism xbindkeys/lxde use for intercepting keyboard > shortcuts. Does anybody have any suggestions on any tools/approaches I > could use to try to debug this further? Or is this mechanism something > so ancient that there's hope of getting it to work correctly? Just a guess, but maybe you are hitting this? https://cgit.freedesktop.org/xorg/xserver/tree/xkb/xkbPrKeyEv.c?id=xorg-server-1.18.99.902#n134 Try running `xbindkeys --verbose` and see its output on key press/relase? The problem is in one of xserver, libX11 or xbindkeys, this would help narrow it down. xbindkeys, for some reason, matches keysym bindings strangely; instead of converting keycodes to keysyms and comparing the keysyms, it converts the keysyms to keycodes and compares keycodes. This is lossy and can cause the wrong binding to match. However, I don't think this is the issue in the scenario you describe, unless you have some other keys which map to XF86LaunchA. Ran _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel