1 The core protocol interpretation of keyboard modifiers does not include direct 2 support for multiple keyboard groups, so XKB reports the effective keyboard 3 group to XKB-aware clients using some of the reserved bits in the state field 4 of some core protocol events. This modified state field would not be interpreted 5 correctly by XKB-unaware clients, so XKB provides a group compatibility mapping 6 which remaps the keyboard group into a core modifier mask that has similar 7 effects, when possible. 8 9 XKB maintains three compatibility state components that are used to make 10 XKB-unaware clients(*) work as well as possible: 11 - The compatibility state which corresponds to the effective modifier and 12 effective group state. 13 - The compatibility lookup state which is the core-protocol equivalent of the 14 lookup state. 15 - The compatibility grab state which is the nearest core-protocol equivalent 16 of the grab state. 17 18 Compatibility states are essentially the corresponding XKB states, but with 19 the keyboard group possibly encoded as one or more modifiers. 20 21 Modifiers that correspond to each keyboard group are described in this 22 group compatibility map. 23 24 25 ---- 26 (*) The implementation of XKB invisibly extends the X library to use the 27 keyboard extension if it is present. That means, clients that use library or 28 toolkit routines to interpret keyboard events automatically use all of XKB's 29 features; clients that directly interpret the state field of core-protocol 30 events or the keymap directly may be affected by some of the XKB differences. 31 Thus most clients can take all advantages without modification but it also 32 means that XKB state can be reported to clients that have not explicitly 33 requested the keyboard extension. 34
Indexes created Sun Oct 25 00:26:45 UTC 2026