Merge remote-tracking branch 'origin/released'

* origin/released:
  mesa xkeyboard-config xserver git update 15 jan 2014
  randrproto libfontenc mesa xserver git update 10 Jan 2014
  randsrproto fontconfig libX11 git update 6 Jan 2014

Conflicts:
	mesalib/src/glsl/builtin_functions.cpp
	mesalib/src/glsl/ir_builder.h
	xorg-server/Xext/xres.c
	xorg-server/dix/dispatch.c
	xorg-server/dix/dixfonts.c
	xorg-server/hw/xwin/wingc.c
	xorg-server/hw/xwin/winwindowswm.c
	xorg-server/include/gc.h
	xorg-server/os/access.c

1 files changed, 7 insertions, 7 deletions

diff --git a/xorg-server/xkeyboard-config/compat/README b/xorg-server/xkeyboard-config/compat/README
index 00d591e7b..3c5747bb8 100644
--- a/xorg-server/xkeyboard-config/compat/README
+++ b/xorg-server/xkeyboard-config/compat/README
@@ -1,7 +1,7 @@
 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
+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.
@@ -15,8 +15,8 @@ XKB-unaware clients(*) work as well as possible:
 - 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. 
+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.
@@ -25,9 +25,9 @@ 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.
+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.