[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