Merge remote-tracking branch 'origin/released'

Conflicts:
	fontconfig/.gitignore
	libX11/src/ConvSel.c
	libX11/src/CrGlCur.c
	libX11/src/CrWindow.c
	libX11/src/GetDflt.c
	libX11/src/Window.c
	libX11/src/xlibi18n/XimProto.h
	libX11/src/xlibi18n/lcDynamic.c
	libxcb/src/.gitignore
	libxcb/src/xcb_ext.c
	libxcb/src/xcb_xid.c
	mesalib/src/glsl/.gitignore
	mesalib/src/glsl/glcpp/.gitignore
	mesalib/src/mapi/glapi/gen/glX_API.xml
	mesalib/src/mapi/glapi/glapi_getproc.c
	mesalib/src/mesa/main/.gitignore
	mesalib/src/mesa/main/syncobj.c
	mesalib/src/mesa/program/.gitignore
	xkbcomp/listing.c
	xkbcomp/xkbpath.c
	xorg-server/.gitignore
	xorg-server/Xext/xvmain.c
	xorg-server/dix/dispatch.c
	xorg-server/hw/xwin/glx/winpriv.h
	xorg-server/hw/xwin/winprefsyacc.y
	xorg-server/hw/xwin/winscrinit.c
	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/mlv_s.sh
	xorg-server/xkeyboard-config/rules/compat/.gitignore

1 files changed, 33 insertions, 33 deletions

diff --git a/xorg-server/xkeyboard-config/compat/README b/xorg-server/xkeyboard-config/compat/README
index 00d591e7b..ea8750fac 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.