README (1712B)
- 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
- 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.
- 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.
- 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.