aboutsummaryrefslogtreecommitdiff
path: root/xorg-server/xkeyboard-config/compat/README
diff options
context:
space:
mode:
authormarha <marha@users.sourceforge.net>2010-07-13 07:48:55 +0000
committermarha <marha@users.sourceforge.net>2010-07-13 07:48:55 +0000
commitd8f81c980a46279ac619312a914b563144894512 (patch)
tree3d2dce1c24fa37edf81c47af2311dbaf56a763f6 /xorg-server/xkeyboard-config/compat/README
parent1812c17dc8e8f071d8731716849957e97bb2b974 (diff)
downloadvcxsrv-d8f81c980a46279ac619312a914b563144894512.tar.gz
vcxsrv-d8f81c980a46279ac619312a914b563144894512.tar.bz2
vcxsrv-d8f81c980a46279ac619312a914b563144894512.zip
Renamed xkbdata.src also on trunk since the current merging of subversion will loose all the changes in xkbdata.src when the directory is renamed on the source branch.
Diffstat (limited to 'xorg-server/xkeyboard-config/compat/README')
-rw-r--r--xorg-server/xkeyboard-config/compat/README33
1 files changed, 33 insertions, 0 deletions
diff --git a/xorg-server/xkeyboard-config/compat/README b/xorg-server/xkeyboard-config/compat/README
new file mode 100644
index 000000000..00d591e7b
--- /dev/null
+++ b/xorg-server/xkeyboard-config/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 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.