🚀 feat(kali): thanks to kalilinux.org

usr/lib/win-kex/VcXsrv/xkbdata/compat/README

@@ -0,0 +1,33 @@
+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.