kc3-lang/libxkbcommon

Diff

  • Show log

    Commit

  • Hash : 54174409
    Author : Ran Benita
    Date : 2014-03-27T17:42:20

    state: fix consumed modifier calculation The current calculation is in short: entry ? (entry->mask & ~entry->preserve) : 0 This changes it be type->mask & ~(entry ? entry->preserve : 0) This is what Xlib does. While less intuitive, it is actually more correct, if you follow this deduction: - The key group's type->mask defines which modifiers the key even cares about. The others are completely irrelevant (and in fact they are masked out from all sided in the level calculation). Example: NumLock for an alphabetic key. - The type->mask, the mods which are not masked out, are *all* relevant (and in fact in the level calculation they must match *exactly* to the state). These mods affect which level is chosen for the key, whether they are active or not. - Because the type->mask mods are all relevant, they must be considered as consumed by the calculation *even if they are not active*. Therefore we use type->mask instead of entry->mask. The second change is what happens when no entry is found: return 0 or just take preserve to be 0? Let's consider an example, the basic type type "ALPHABETIC" { modifiers = Shift+Lock; map[Shift] = Level2; map[Lock] = Level2; level_name[Level1] = "Base"; level_name[Level2] = "Caps"; }; Suppose Shift+Lock is active - it doesn't match any entry, thus it gets to level 0. The first interpretation would take them both to be unconsumed, the second (new one) would take them both to be consumed. This seems much better: Caps is active, and Shift disables it, they both do something. This change also fixes a pretty lousy bug (since 0.3.2), where Shift appears to apparently *not* disable Caps. What actually happens is that Caps is not consumed (see above) but active, thus the implicit capitalization in get_one_sym() kicks in and capitalizes it anyway. Reported-by: Davinder Pal Singh Bhamra Signed-off-by: Ran Benita <ran234@gmail.com>

  • Properties

  • Git HTTP https://git.kmx.io/kc3-lang/libxkbcommon.git
    Git SSH git@git.kmx.io:kc3-lang/libxkbcommon.git
    Public access ? public
    Description
    Users
    		 thodg_w thodg_m thodg_l kc3_lang_org thodg www_kmx_io
    Tags

  • README.md

  • libxkbcommon

    xkbcommon 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_state_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

    Quick Guide

    See Quick Guide.

    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 supported API is available in the xkbcommon/xkbcommon-*.h files. Additional support is provided for X11 (XCB) clients, in the xkbcommon-x11 library, xkbcommon/xkbcommon-x11.h.

    The xkbcommon API and ABI are stable. 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.5.3, but not necessarily with 1.0.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.

    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

    An extremely rudimentary homepage can be found at

    http://xkbcommon.org

    xkbcommon is maintained in git at

    https://github.com/xkbcommon/libxkbcommon

    Patches are always welcome, and may be sent to either

    <xorg-devel@lists.x.org> or <wayland-devel@lists.freedesktop.org>

    Bugs are also welcome, and may be reported either at

    Bugzilla https://bugs.freedesktop.org/describecomponents.cgi?product=libxkbcommon

    or

    Github https://github.com/xkbcommon/libxkbcommon/issues

    The maintainers are

    Credits

    Many thanks are due to Dan Nicholson for his heroic work in getting xkbcommon off the ground initially.

kmx.io     mail     discord kmxgit v0.4.0