[PATCH inputproto] Fix typos in XIproto.txt

[Fernando Carrijo]

Signed-off-by: Fernando Carrijo <fcarrijo at freedesktop.org>
---
Nothing extraordinary here. Seriously!

 XIproto.txt |   30 ++++++++++--------------------
 1 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/XIproto.txt b/XIproto.txt
index f9d19f0..83cf9dd 100644
--- a/XIproto.txt
+++ b/XIproto.txt
@@ -1650,7 +1650,7 @@
    feedback class BellFeedback, which is reported in the
    BellFeedbackState structure. The members of that structure are:
 
-                     CLASS String:
+                     CLASS Bell:
                            [class: CARD8
                             length: CARD16
                             feedback id: CARD8
@@ -1676,7 +1676,7 @@
    class Led, which is reported in the LedFeedbackState structure.
    The members of that structure are:
 
-                     CLASS String:
+                     CLASS Led:
                            [class: CARD8
                             length: CARD16
                             feedback id: CARD8
@@ -1781,7 +1781,7 @@
                             feedback id: CARD8
                             int_to_display: INT32]
 
-   Some devices are capable of displaying an string. This is done
+   Some devices are capable of displaying a string. This is done
    using feedback class StringFeedbackClass using the
    StringFeedbackCtl structure. The members of that structure are
    as follows:
@@ -1978,29 +1978,19 @@ Controlling Device Encoding
    A server can impose restrictions on how modifiers can be
    changed (for example, if certain keys do not generate up
    transitions in hardware or if multiple keys per modifier are
-   not supported). The status reply is Failed if some such
-   restriction is violated, and none of the modifiers are changed.
+   not supported). If some such restriction is violated, the status
+   reply is MappingFailed, and none of the modifiers are changed.
 
-   If the new non-zero keycodes specified for a modifier differ
-   from those currently defined, and any (current or new) keys for
-   that modifier are logically in the down state, then the status
-   reply is Busy, and none of the modifiers are changed.
+   If the new keycodes specified for a modifier differ from those
+   currently defined and any (current or new) keys for that
+   modifier are in the logically down state, the status reply is
+   MappingBusy, and none of the modifiers are changed.
 
    This request generates a DeviceMappingNotify event on a Success
    status. The DeviceMappingNotify event will be sent only to
    those clients that have expressed an interest in receiving that
    event via the XSelectExtensionEvent request.
 
-   A X server can impose restrictions on how modifiers can be
-   changed, for example, if certain keys do not generate up
-   transitions in hardware or if multiple modifier keys are not
-   supported. If some such restriction is violated, the status
-   reply is MappingFailed , and none of the modifiers are changed.
-   If the new keycodes specified for a modifier differ from those
-   currently defined and any (current or new) keys for that
-   modifier are in the logically down state, the status reply is
-   MappingBusy, and none of the modifiers are changed.
-
 2.20 Controlling Button Mapping
 
    These requests are analogous to the core GetPointerMapping and
@@ -2350,7 +2340,7 @@ Controlling Device Encoding
    specified device and window. Events generated by SetDeviceFocus
    when the device is not grabbed have mode Normal. Events
    generated by SetDeviceFocus when the device is grabbed have
-   mode WhileGrabbed. Events generated when a device grab actives
+   mode WhileGrabbed. Events generated when a device grab activates
    have mode Grab, and events generated when a device grab
    deactivates have mode Ungrab.
 
-- 
1.7.1