rfc1013.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Viewable
           A window is "viewable" if it and all of its ancestors are
           mapped.  This does not imply that any portion of the window
           is actually visible.

   Visible
           A region of a window is "visible" if someone looking at the
           screen can actually "see" it:  the window is viewable and the
           region is not occluded by any other window.

   Window gravity
           When windows are resized, subwindows may be repositioned
           automatically relative to some position in the window.  This
           attraction of a subwindow to some part of its parent is known
           as "window gravity".

   Window manager
           Manipulation of windows on the screen, and much of the user
           interface (policy) is typically provided by a "window
           manager" client.

   XYFormat
           The data for a pixmap is said to be in "XYFormat" if it is
           organized as a set of bitmaps representing individual bit
           planes.



M.I.T.                                                         [Page 12]

RFC 1013                                                       June 1987


   ZFormat
           The data for a pixmap is said to be in "ZFormat" if it is
           organized as a set of pixel values in scanline order.

SECTION 2.  PROTOCOL FORMATS


Request Format

   Every request contains an 8-bit "major" opcode, and a 16-bit length
   field expressed in units of 4 bytes.  Every request consists of 4
   bytes of header containing the major opcode, the length field, and a
   data byte) followed by zero or more additional bytes of data; the
   length field defines the total length of the request, including the
   header.  The length field in a request must equal the minimum length
   required to contain the request; if the specified length is smaller
   or larger than the required length, an error is enerated.  Unused
   bytes in a request are not required to be zero.  Major opcodes 128
   through 255 are reserved for extensions.  Extensions are intended
   to contain multiple requests, so extension requests typically have
   an additional minor opcode encoded in the "spare" data byte in the
   request header, but the placement and interpretation of this minor
   opcode, and all other fields in extension requests, are not defined
   by the core protocol. Every request is implicitly assigned a sequence
   number, starting with one,used in replies, errors, and events.

Reply Format

   Every reply contains a 32-bit length field expressed in units of 4
   bytes. Every reply consists of 32 bytes, followed by zero or more
   additional bytes of data, as specified in the length field.  Unused
   bytes within a reply are not guaranteed to be zero.  Every reply
   also contains the least significant 16 bits of the sequence number
   of the corresponding request.

Error Format

   Error reports are 32 bytes long.  Every error includes an 8-bit error
   code. Error codes 128 through 255 are reserved for extensions.  Every
   error also includes the major and minor opcodes of the failed
   request, and the least significant 16 bits of the sequence number of
   the request.  For the following errors (see Section 5), the failing
   resource id is also returned: Colormap, Cursor, Drawable, Font,
   GContext, IDChoice, Pixmap, and Window.  For Atom errors, the failing
   atom is returned.  For Value errors, the failing value is returned.
   Other core errors return no additional data.  Unused bytes within
   an error are not guaranteed to be zero.

Event Format

   Events are 32 bytes long.  Unused bytes within an event are not



M.I.T.                                                         [Page 13]

RFC 1013                                                       June 1987


   guaranteed to be zero.  Every event contains an 8-bit type code.  The
   most significant bit in this code is set if the event was generated
   from a SendEvent request. Event codes 64 through 127 are reserved for
   extensions, although the core protocol does not define a mechanism
   for selecting interest in such events. Every core event (with the
   exception of KeymapNotify) also contains the least significant 16
   bits of the sequence number of the last request issued by the client
   that was (or is currently being) processed by the server.


SECTION 3.  SYNTAX


   The syntax {...} encloses a set of alternatives.

   The syntax [...] encloses a set of structure components.

   In general, TYPEs are in upper case and AlternativeValues are
   capitalized.

   Requests in Section 10 are described in the following format:

       RequestName
               arg1: type1
               ...
               argN: typeN
           =>
               result1: type1
               ...
               resultM: typeM

               Errors: kind1, ..., kindK

               Description.

If no => is present in the description, then the request has no
reply (it is asynchronous), although errors may still be reported.

Events in Section 12 are described in the following format:

    EventName
            value1: type1
            ...
            valueN: typeN

            Description.








M.I.T.                                                         [Page 14]

RFC 1013                                                       June 1987


SECTION 4.  COMMON TYPES


LISTofFOO

   A type name of the form LISTofFOO means a counted list of elements
   of type FOO; the size of the length field may vary (it is not
   necessarily the same size as a FOO), in some cases may be implicit,
   and is not fully specified in this document.

BITMASK and LISTofVALUE

   The types BITMASK and LISTofVALUE are somewhat special.  Various
   requests contain arguments of the form:
           value-mask: BITMASK
           value-list: LISTofVALUE
   used to allow the client to specify a subset of a heterogeneous
   collection of "optional" arguments.  The value-mask specifies which
   arguments are to be provided; each such argument is assigned a unique
   bit position.  The representation of the BITMASK will typically
   contain more bits than there are defined arguments; unused bits in
   the value-mask must be zero (or the server generates a Value error).
   The value-list contains one value for each one bit in the mask, from
   least to most significant bit in the mask.  Each value is represented
   with 4 bytes, but the actual value occupies only the least
   significant bytes as required; the values of the unused bytes do not
   matter.

Or Types

   A type of the form "T1 or ... or Tn" means the union of the indicated
   types; a single-element type is given as the element without
   enclosing braces.

DEVICE: 32-bit id (<class,model,manufacturer,unit> 8 bits each)
WINDOW: 32-bit id
PIXMAP: 32-bit id
CURSOR: 32-bit id
FONT: 32-bit id
GCONTEXT: 32-bit id
COLORMAP: 32-bit id
DRAWABLE: WINDOW or PIXMAP
ATOM: 32-bit id (top 3 bits guaranteed to be zero)
VISUALID: 32-bit id (top 3 bits guaranteed to be zero)
VALUE: 32-bit quantity (used only in LISTofVALUE)
INT8: 8-bit signed integer
INT16: 16-bit signed integer
INT32: 32-bit signed integer
CARD8: 8-bit unsigned integer
CARD16: 16-bit unsigned integer
CARD32: 32-bit unsigned integer



M.I.T.                                                         [Page 15]

RFC 1013                                                       June 1987


TIMESTAMP: CARD32
BITGRAVITY: {Forget, Static,
             NorthWest, North, NorthEast,
             West, Center, East,
             SouthWest, South, SouthEast}
WINGRAVITY: {Unmap, Static,
             NorthWest, North, NorthEast,
             West, Center, East,
             SouthWest, South, SouthEast}
BOOL: {True, False}
EVENT: {KeyPress, KeyRelease,
        OwnerGrabButton,
        ButtonPress, ButtonRelease, EnterWindow, LeaveWindow,
        PointerMotion, PointerMotionHint,
        Button1Motion, Button2Motion, Button3Motion,
        Button4Motion, Button5Motion, ButtonMotion
        Exposure, VisibilityChange,
        StructureNotify, ResizeRedirect,
        SubstructureNotify, SubstructureRedirect,
        FocusChange,
        PropertyChange, ColormapChange,
        KeymapState}
POINTEREVENT: {ButtonPress, ButtonRelease, EnterWindow, LeaveWindow,
               PointerMotion, PointerMotionHint,
               Button1Motion, Button2Motion, Button3Motion,
               Button4Motion, Button5Motion, ButtonMotion
               KeymapState}
DEVICEEVENT: {KeyPress, KeyRelease,
              ButtonPress, ButtonRelease,
              PointerMotion,
              Button1Motion, Button2Motion, Button3Motion,
              Button4Motion, Button5Motion, ButtonMotion}
KEYCODE: CARD8
BUTTON: CARD8
KEYMASK: {Shift, CapsLock, Control, Mod1, Mod2, Mod3, Mod4, Mod5}
BUTMASK: {Button1, Button2, Button3, Button4, Button5}
KEYBUTMASK: KEYMASK or BUTMASK
STRING8: LISTofCARD8
STRING16: LISTofCHAR2B
CHAR2B: [byte1, byte2: CARD8]
POINT: [x, y: INT16]
RECTANGLE: [x, y: INT16,
            width, height: CARD16]
ARC: [x, y: INT16,
      width, height: CARD16,
      angle1, angle2: INT16]
HOST: [family: {Internet, NS, ECMA, Datakit, DECnet}
       address: LISTofCARD8]

   The [x,y] coordinates of a RECTANGLE specify the upper left corner.




M.I.T.                                                         [Page 16]

RFC 1013                                                       June 1987


   The primary interpretation of "large" characters in a STRING16 is
   that they are composed of two bytes used to index a 2-D matrix;
   hence the use of CHAR2B rather than CARD16.  This corresponds to
   the JIS/ISO method of indexing two-byte characters.  It is expected
   that most "large" fonts will be defined with two-byte matrix
   indexing.  For large fonts constructed with linear indexing, a
   CHAR2B can be interpreted as a 16-bit number by treating byte1 as
   the most significant byte; this means that clients should always
   transmit such 16-bit character values most significant byte first,
   as the server will never byte-swap CHAR2B quantities.

   The length, format, and interpretation of a HOST address are specific
   to the family.


SECTION 5.  ERRORS

   In general, when a request terminates with an error, the request has
   no side effects (i.e., there is no partial execution).  The only
   requests for which this is not true are ChangeWindowAttributes,
   ChangeGC, PolyText8, PolyText16, FreeColors, StoreColors, and
   ChangeKeyboardControl.

   The following error codes can be returned by the various requests:

Access
           An attempt to grab a key/button combination already grabbed
           by another client.

           An attempt to free a colormap entry not allocated by the
           client.

           An attempt to store into a read-only or an unallocated
           colormap entry.

           An attempt to modify the access control list from other than
           the local (or otherwise authorized) host.

           An attempt to select an event type, that at most one client
           can select at a time, when another client has already
           selected it.

Alloc
           The server failed to allocate the requested resource.

           Note that this only covers allocation errors at a very coarse
           level, and is not intended to (nor can it in practice hope
           to) cover all cases of a server running out of allocation
           space in the middle of service.





M.I.T.                                                         [Page 17]

RFC 1013                                                       June 1987


           The semantics when a server runs out of allocation space are
           left unspecified.

Atom
           A value for an ATOM argument does not name a defined ATOM.

Colormap
           A value for a COLORMAP argument does not name a defined
           COLORMAP.