-
Show log
Commit
-
Hash : 07b18bde
Author :
Date : 2012-08-09T02:33:51
Modernize struct xkb_mods Currently xkb_mods has the following members: - uint8_t real_mods - 8 X11 core mods - xkb_mod_mask_t vmods - 16 virtual mods, zero-based index - xkb_mod_mask_t mask - the computed effective *real* modifier mask, basically a cache for the first two which is: real_mods | real mods computed from vmods Our API acts on masks which combine the real_mods and vmods into a single value, which is: 8 first bits real mods | 16 next bits virtual mods (XkbNumModifiers = 8, XkbNumVirtualMods = 16). This is also the format which ResolveVModMask uses (which is where all the modifier masks really "come from", e.g. "Shift+Lock+Level5" -> xkb_mod_mask_t). What the code does now after getting the mask from ResolveVModMask, is to break it into real part and virtual part and store them seperately, and then join them back together when the effective mask is calculated. This is all pretty useless work. We change xkb_mods to the following: - xkb_mod_mask_t mods - usually what ResolveVModMask returns - xkb_mod_mask_t mask - the computed mask cache And try to consistently use the word "mods" for the original, non-effective mods and mask for the effective mods (which can only contain real mods for now, because things break otherwise). The separation is also made clearer. The effective masks are computed by UpdateModifiersFromCompat after all the sections have been compiled; before this the mask field is never touched; after this (i.e. map.c and state.c) the original mods field is never touched. This single execption to this rule is keymap-dump.c: it needs to print out only the original modifiers, not computed ones. This is also the reason why we actually keep two fields instead keeping one and modifying it in place. The next logical step is probably to turn the real mods into vmods themselves, and get rid of the distinction entirely (in a compatible way). Signed-off-by: Ran Benita <ran234@gmail.com>
-
README
-
xkbcommon ========= libxkbcommon is a keymap compiler and support library which processes a reduced subset of keymaps as defined by the XKB specification. Primarily, a keymap is created from a set of Rules/Model/Layout/Variant/Options names, processed through an XKB ruleset, and compiled into a struct xkb_keymap, which is the base type for all xkbcommon operations. From an xkb_keymap, an xkb_state object is created which holds the current state of all modifiers, groups, LEDs, etc, relating to that keymap. All key events must be fed into the xkb_state object using xkb_state_update_key. Once this is done, the xkb_state object will be properly updated, and the keysyms to use can be obtained with xkb_key_get_syms. libxkbcommon does not distribute a dataset itself, other than for testing purposes. The most common dataset is xkeyboard-config, as used by all current distributions for their X11 XKB data. More information on xkeyboard-config is available here: http://www.freedesktop.org/wiki/Software/XKeyboardConfig API === While xkbcommon's API is somewhat derived from the classic XKB API as found in <X11/extensions/XKB.h> and friends, it has been substantially reworked to expose fewer internal details to clients. The only supported API is available in <xkbcommon/xkbcommon.h>. Any definition not in this header (including accessing internal structures through the old macros previously available) should be regarded as an implementation detail and is liable to change at any time. During its early development, xkbcommon does not promise API or ABI stability. Regardless, we will attempt to not break ABI during a minor release series, so applications written against 0.1.0 should be completely compatible with 0.1.3, but not necessarily with 0.2.0. However, new symbols may be introduced in any release. Thus, anyone packaging xkbcommon should make sure any package depending on it depends on a release greater than or equal to the version it was built against (or earlier, if it doesn't use any newly-introduced symbols), but less than the next major release. xkbcommon 1.x will offer full API and ABI stability for its lifetime, with a soname of libxkbcommon.so.1. Any ABI breaks will wait until xkbcommon 2.0, which will be libxkbcommon.so.2. The xkbcomp command-line tool has also been removed, although this will likely reappear in a later release. Relation to X11 =============== Relative to the XKB 1.1 specification implemented in current X servers, xkbcommon has removed support for some parts of the specification which introduced unnecessary complications. Many of these removals were in fact not implemented, or half-implemented at best, as well as being totally unused in the standard dataset. Notable removals: - geometry support + there were very few geometry definitions available, and while xkbcommon was responsible for parsing this insanely complex format, it never actually did anything with it + hopefully someone will develop a companion library which supports keyboard geometries in a more useful format - KcCGST (keycodes/compat/geometry/symbols/types) API + use RMLVO instead; KcCGST is now an implementation detail + including pre-defined keymap files - XKM support + may come in an optional X11 support/compatibility library - around half of the interpret actions + pointer device, message and redirect actions in particular - non-virtual modifiers + core and virtual modifiers have been collapsed into the same namespace, with a 'significant' flag that largely parallels the core/virtual split - radio groups + completely unused in current keymaps, never fully implemented - overlays + almost completely unused in current keymaps - key behaviors + used to implement radio groups and overlays, and to deal with things like keys that physically lock; unused in current keymaps - indicator behaviours such as LED-controls-key + the only supported LED behaviour is key-controls-LED; again this was never really used in current keymaps Notable additions: - 32-bit keycodes - extended number of modifiers - extended number of groups - multiple keysyms per level + this requires incompatible dataset changes, such that X11 would not be able to parse these Development =========== xkbcommon is maintained in git at freedesktop.org: git://anongit.freedesktop.org/git/xorg/lib/libxkbcommon Patches are always welcome, and may be sent to either xorg-devel@lists.x.org, or wayland-devel@lists.freedesktop.org. Bugs are tracked in Bugzilla at: http://bugs.freedesktop.org The primary author and maintainer is Daniel Stone, who can be reached at: <daniel@fooishbar.org> Credits ======= Many thanks are due to Dan Nicholson for his heroic work in getting xkbcommon off the ground initially, as well as to Ran Benita for subsequent development.