Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
state: support querying whether virtual modifiers are active
This allows the user to query directly whether "NumLock", "Super", "Meta", "Alt" etc. are active, rather than resorting to the real modifiers or just guessing. This should help e.g. toolkits which have things like Meta in the modifier masks they report. Demo: $ sudo ./test/interactive keysyms [ Caps_Lock ] unicode [ ] group [ English (US) (0) ] mods [ ] leds [ ] keysyms [ A ] unicode [ A ] group [ English (US) (0) ] mods [ -Lock ] leds [ Caps Lock ] keysyms [ Num_Lock ] unicode [ ] group [ English (US) (0) ] mods [ Lock ] leds [ Caps Lock ] keysyms [ KP_1 ] unicode [ 1 ] group [ English (US) (0) ] mods [ Lock -Mod2 -NumLock ] leds [ Caps Lock Num Lock ] keysyms [ Shift_R ] unicode [ ] group [ English (US) (0) ] mods [ Lock Mod2 NumLock ] leds [ Caps Lock Num Lock ] keysyms [ a ] unicode [ a ] group [ English (US) (0) ] mods [ Shift Lock Mod2 NumLock ] leds [ Caps Lock Num Lock ] keysyms [ Meta_L ] unicode [ ] group [ English (US) (0) ] mods [ -Shift Lock Mod2 NumLock ] leds [ Caps Lock Num Lock ] keysyms [ Meta_L ] unicode [ ] group [ English (US) (0) ] mods [ -Shift Lock Mod2 NumLock ] leds [ Caps Lock Num Lock ] keysyms [ a ] unicode [ a ] group [ English (US) (0) ] mods [ Shift Lock Mod1 Mod2 NumLock Alt Meta ] leds [ Caps Lock Num Lock ] keysyms [ Super_L ] unicode [ ] group [ English (US) (0) ] mods [ Shift Lock Mod1 Mod2 NumLock Alt Meta ] leds [ Caps Lock Num Lock ] keysyms [ a ] unicode [ a ] group [ English (US) (0) ] mods [ Shift Lock Mod1 Mod2 Mod4 NumLock Alt Meta Super ] leds [ Caps Lock Num Lock ] keysyms [ Control_L ] unicode [ ] group [ English (US) (0) ] mods [ Shift Lock Mod1 Mod2 Mod4 NumLock Alt Meta Super ] leds [ Caps Lock Num Lock ] keysyms [ a ] unicode [ a ] group [ English (US) (0) ] mods [ Shift Lock Control Mod1 Mod2 Mod4 NumLock Alt Meta Super ] leds [ Caps Lock Num Lock ] Previously, NumLock, Alt, Meta, Super would not be here. To facilitate this support, we also add #defines for the names of the Meta, Super, Hyper and NumLock modifiers. These are set freely in xkeyboard-config, but are essentially treated as ABI there. Also, the standard explicitly recommends the names for NumLock, Alt and Meta: http://www.x.org/releases/X11R7.6/doc/libX11/specs/XKB/xkblib.html#conventions We also change the define of Alt from "Mod1" to "Alt"; this is more correct, and safe. "Mod1" continues to work as before. One case that needs special consideration are the xkb_state_mod_indices_are_active() and mod_names_are_active() functions. By default, they perform an exclusive match on the modifiers that are passed to them. With virtual modifiers in the mix, you often get unexpected modifiers as well, which break it. I'm not really sure have exclusive-by-default is a good idea, because it also breaks when the user just pressed Num Lock of Caps Lock. However, for now we just revert to the old behavior of real-mods-only for these functions, which should be fine in most cases. We can revisit this later, when something more clever comes to mind. *** To get the virtual modifiers in, we essentially change just two things: 1. When SetMods/LockMods(modifiers=modMapMods) is used, we also add the modifiers in the key's vmodmap (in addition the key's modmap). The vmodmap of a key is set by virtualMod fields in interprets, or directly in the 'key' statements in xkb_symbols. It essentially contains the virtual modifiers that are bound to this key. 2. We no longer mask out virtual modifiers from the effective modifier masks in types, actions and indicators. This means mostly that if a type specifies e.g. "map[NumLock+LevelThree] = Level4", the active modifier mask in the state will in fact be matched against the NumLock and LevelThree modifiers. Together with 1, this works out nicely, and our tests all pass. Signed-off-by: Ran Benita <[email protected]>
- Loading branch information
