34 lines
1.7 KiB
Plaintext
34 lines
1.7 KiB
Plaintext
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 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 state are essentially the corresponding XKB states, but with
|
|
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
|
|
features; clients that directly interpret the state field of core protocol
|
|
events or the keymap direcly 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.
|