diff options
author | marha <marha@users.sourceforge.net> | 2012-11-19 10:38:33 +0100 |
---|---|---|
committer | marha <marha@users.sourceforge.net> | 2012-11-19 10:38:33 +0100 |
commit | 24635abae6008bef13e30d798b3f33abab412770 (patch) | |
tree | e799fbde24e0fd935af76b0bc48d30ef69f75d54 /xorg-server/xkeyboard-config/compat/README | |
parent | e0844ae8b5ef87049537a7e0ebff81acc2695256 (diff) | |
parent | 6ce1d8f0f8c23e186175a7c84c21d7bfbe168dc5 (diff) | |
download | vcxsrv-24635abae6008bef13e30d798b3f33abab412770.tar.gz vcxsrv-24635abae6008bef13e30d798b3f33abab412770.tar.bz2 vcxsrv-24635abae6008bef13e30d798b3f33abab412770.zip |
Merge remote-tracking branch 'origin/released'
* origin/released:
Changed file permissions
dos -> unix
Conflicts:
libX11/include/X11/Xregion.h
libX11/src/ConvSel.c
libX11/src/CrGlCur.c
libX11/src/CrWindow.c
libX11/src/GetDflt.c
libX11/src/StrKeysym.c
libX11/src/Window.c
libX11/src/xkb/XKBBind.c
libX11/src/xkb/XKBGetMap.c
libX11/src/xkb/XKBSetGeom.c
libX11/src/xkb/XKBUse.c
libX11/src/xlibi18n/XimProto.h
libX11/src/xlibi18n/lcDynamic.c
libXdmcp/Key.c
libXdmcp/Write.c
libxcb/src/xcb_windefs.h
xkbcomp/keycodes.c
xkbcomp/xkbpath.c
xorg-server/hw/xwin/glx/winpriv.h
xorg-server/xkeyboard-config/rules/bin/ml1_s.sh
xorg-server/xkeyboard-config/rules/bin/ml1v1_s.sh
xorg-server/xkeyboard-config/rules/bin/ml1v_s.sh
xorg-server/xkeyboard-config/rules/bin/ml_s.sh
xorg-server/xkeyboard-config/rules/bin/mln_s.sh
xorg-server/xkeyboard-config/rules/bin/mlnvn_s.sh
xorg-server/xkeyboard-config/rules/bin/mlv_s.sh
xorg-server/xkeyboard-config/rules/compat/.gitignore
Diffstat (limited to 'xorg-server/xkeyboard-config/compat/README')
-rw-r--r-- | xorg-server/xkeyboard-config/compat/README | 66 |
1 files changed, 33 insertions, 33 deletions
diff --git a/xorg-server/xkeyboard-config/compat/README b/xorg-server/xkeyboard-config/compat/README index ea8750fac..00d591e7b 100644 --- a/xorg-server/xkeyboard-config/compat/README +++ b/xorg-server/xkeyboard-config/compat/README @@ -1,33 +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.
+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. |