The core protocol interpretation of keyboard modifiers does not include directsupport for multiple keyboard groups, so XKB reports the effective keyboardgroup to XKB-aware clients using some of reserved bits in the state field ofsome core protocol events. This modified state field would not be interpretedcorrectly by XKB-unaware clients, so XKB provides a group compatibility mappingwhich remaps the keyboard group into a core modifier mask that has similareffects, when possible.XKB maintains three compatibility state components that are used to makeXKB-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 withkeyboard group possibly encoded as one or more modifiers. Modifiers that correspond to each keyboard group are described in thisgroup compatibility map.----(*) The implementation of XKB invisibly extends the X library to use thekeyboard extension if it is present. That means, clients that use library ortoolkit routines to interpret keyboard events automatically use all of XKBfeatures; clients that directly interpret the state field of core protocolevents or the keymap direcly may be affected by some of the XKB differences.Thus most clients can take all advantages without modification but it alsomeans that XKB state can be reported to clients that have not explicitlyrequested the keyboard extension.