xenocara/dist/xkeyboard-config/compat/README

34 lines
1.7 KiB
Plaintext
Raw Normal View History

2009-06-06 11:52:23 -06:00
The core protocol interpretation of keyboard modifiers does not include direct
support for multiple keyboard groups, so XKB reports the effective keyboard
group to XKB-aware clients using some of the reserved bits in the state field
of some core protocol events. This modified state field would not be interpreted
2009-06-06 11:52:23 -06:00
correctly by XKB-unaware clients, so XKB provides a group compatibility mapping
which remaps the keyboard group into a core modifier mask that has similar
effects, when possible.
XKB maintains three compatibility state components that are used to make
XKB-unaware clients(*) work as well as possible:
- The compatibility state which corresponds to the effective modifier and
effective group state.
- The compatibility lookup state which is the core-protocol equivalent of the
lookup state.
- The compatibility grab state which is the nearest core-protocol equivalent
of the grab state.
Compatibility states are essentially the corresponding XKB states, but with
the keyboard group possibly encoded as one or more modifiers.
2009-06-06 11:52:23 -06:00
Modifiers that correspond to each keyboard group are described in this
group compatibility map.
----
(*) The implementation of XKB invisibly extends the X library to use the
keyboard extension if it is present. That means, clients that use library or
toolkit routines to interpret keyboard events automatically use all of XKB's
features; clients that directly interpret the state field of core-protocol
events or the keymap directly may be affected by some of the XKB differences.
2009-06-06 11:52:23 -06:00
Thus most clients can take all advantages without modification but it also
means that XKB state can be reported to clients that have not explicitly
requested the keyboard extension.