[PATCH inputproto] Fix typos in XIproto.txt

Peter Hutterer peter.hutterer at who-t.net
Sun Jan 30 19:10:01 PST 2011


On Thu, Jan 27, 2011 at 10:40:11PM -0200, Fernando Carrijo wrote:
> 
> Signed-off-by: Fernando Carrijo <fcarrijo at freedesktop.org>

merged, thanks.

Cheers,
  Peter

> ---
> 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


More information about the xorg-devel mailing list