On Thu, Jan 27, 2011 at 10:40:11PM -0200, Fernando Carrijo wrote: > > Signed-off-by: Fernando Carrijo <[email protected]>
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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
