rfc1013.txt

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

Cursor
           A value for a CURSOR argument does not name a defined CURSOR.

Drawable
           A value for a DRAWABLE argument does not name a defined
           WINDOW or PIXMAP.

Font
           A value for a FONT or <FONT or GCONTEXT> argument does not
           name a defined FONT.

GContext
           A value for a GCONTEXT argument does not name a defined
           GCONTEXT.

IDChoice
           The value chosen for a resource identifier is either not
           included in the range assigned to the client, or is already
           in use.

Implementation
           The server does not implement some aspect of the request.  A
           server which generates this error for a core request is
           deficient.  As such, this error is not listed for any of the
           requests, but clients should be prepared to receive such
           errors, and handle or discard them.

Length
           The length of a request is shorter or longer than that
           required to minimally contain the arguments.

Match
           An InputOnly window is used as a DRAWABLE.

           Some argument (or pair of arguments) has the correct type and
           range, but fails to "match" in some other way required by the
           request.

Name
           A font or color of the specified name does not exist.




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


Pixmap
           A value for a PIXMAP argument does not name a defined PIXMAP.

Property
           The requested property does not exist for the specified
           window.

Request
           The major or minor opcode does not specify a valid request.

Value
           Some numeric value falls outside the range of values accepted
           by the request.  Unless a specific range is specified for an
           argument, the full range defined by the argument's type is
           accepted.  Any argument defined as a set of alternatives can
           generate this error.

Window
           A value for a WINDOW argument does not name a defined WINDOW.


Note:  the Atom, Colormap, Cursor, Drawable, Font, GContext, Pixmap,
and Window errors are also used when the argument type is extended
by union with a set of fixed alternatives, e.g.,<Window or
PointerRoot or None>.

SECTION 6.  KEYBOARDS

   Keycodes are always in the inclusive range [8,255].

   For keyboards with both left-side and right-side modifier keys (e.g.,
   Shift and Control), the mask bits in the protocol always define the
   OR of the keys. If electronically distinguishable, they can have
   separate up/down events generated, and clients that want to
   distinguish can track the individual states manually.

   <As part of the core we need to define a universal association
   between keycaps and keycodes.  A keycap is the graphical information
   imprinted on a keyboard key, e.g., "$ 4", "T", "+ =".>


SECTION 7.  POINTERS

   Buttons are always numbered starting with one.


SECTION 8.  PREDEFINED ATOMS

   Predefined atoms are not strictly necessary, and may not be useful in
   all environments, but will eliminate many InternAtom requests in most
   applications.  The core protocol imposes no semantics on these names,



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


   except as they are used in FONTPROP structures (see QueryFont).  Note
   that upper/lower case matters.

      BITMAP               ICON_SIZE               RGB_GREEN_MAP
      COMMAND              ITALIC_ANGLE            RGB_RED_MAP
      COPYRIGHT            MAX_SPACE               SECONDARY
      CUT_BUFFER0          MIN_SPACE               SIZE_HINTS
      CUT_BUFFER1          NAME                    STRIKEOUT_ASCENT
      CUT_BUFFER2          NORMAL_HINTS            STRIKEOUT_DESCENT
      CUT_BUFFER3          NORM_SPACE              STRING
      CUT_BUFFER4          PIXMAP                  SUBSCRIPT_X
      CUT_BUFFER5          POINT_SIZE              SUBSCRIPT_Y
      CUT_BUFFER6          PRIMARY                 SUPERSCRIPT_X
      CUT_BUFFER7          QUAD_WIDTH              SUPERSCRIPT_Y
      DEFAULT_CHAR         RECTANGLE               UNDERLINE_POSITION
      END_SPACE            RESIZE_HINT             UNDERLINE_THICKNESS
      FACE_NAME            RESOLUTION              WEIGHT
      FAMILY_NAME          RGB_BEST_MAP            WINDOW
      FONT_ASCENT          RGB_BLUE_MAP            WM_HINTS
      FONT_DESCENT         RGB_COLOR_MAP           X_HEIGHT
      ICON                 RGB_DEFAULT_MAP         ZOOM_HINTS
      ICON_NAME


SECTION 9.  CONNECTION SETUP

   For remote clients, the X protocol can be built on top of any
   reliable byte stream.  For TCP connections, displays on a given host
   a numbered starting from 0, and the server for display N listens and
   accepts connections on port 6000+N.

   The client must send an initial byte of data to identify the byte
   order to be employed.  The value of the byte must be octal 102 or
   154.  The value 102 (ASCII uppercase B) means values are transmitted
   most significant byte first, and value 154 (ASCII lowercase l) means
   values are transmitted least significant byte first.  Except where
   explicitly noted in the protocol, all 16-bit and 32-bit quantities
   sent by the client must be transmitted with this byte order, and all
   16-bit and 32-bit quantities returned by the server will be
   transmitted with this byte order.

   Following the byte-order byte, the following information is sent by
   the client at connection setup:

           protocol-major-version: CARD16
           protocol-minor-version: CARD16
           authorization-protocol-name: STRING8
           authorization-protocol-data: STRING8

           The version numbers indicate what version of the protocol the
           client expects the server to implement.  See below for an



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


           explanation. The authorization name indicates what
           authorization protocol the client expects the server to use,
           and the data is specific to that protocol. Specification of
           valid authorization mechanisms is not part of the core X
           protocol.  It is hoped that eventually one authorization
           protocol will be agreed upon.  In the mean time, a server
           that implements a different protocol than the client expects,
           or a server that only implements the host-based mechanism,
           will simply ignore this information.

   Received by the client at connection setup:
           success: BOOL
           protocol-major-version: CARD16
           protocol-minor-version: CARD16
           length: CARD16

           Length is the amount of additional data to follow, in units
           of 4 bytes. The version numbers are an escape hatch in case
           future revisions of the protocol are necessary.  In general,
           the major version would increment for incompatible changes,
           and the minor version would increment for small upward
           compatible changes.  Barring changes, the major version
           will be eleven, and the minor version will be zero.  The
           protocol version numbers returned indicate the protocol the
           server actually supports.  This might not equal the version
           sent by the client.  The server can (but need not) refuse
           connections from clients that offer a different version
           than the server supports.  A server can (but need not)
           support more than one version simultaneously.

   Additional data received if authorization fails:
           reason: STRING8

   Additional data received if authorization is accepted:
           vendor: STRING8
           release-number: CARD32
           resource-id-base, resource-id-mask: CARD32
           image-byte-order: {LSBFirst, MSBFirst}
           bitmap-format-scanline-unit: {8, 16, 32}
           bitmap-format-scanline-pad: {8, 16, 32}
           bitmap-format-bit-order: {LeastSignificant, MostSignificant}
           pixmap-formats: LISTofFORMAT
           roots: LISTofSCREEN
           keyboard: DEVICE
           pointer: DEVICE
           motion-buffer-size: CARD32
           maximum-request-length: CARD16

           where

             FORMAT: [depth: CARD8,



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


                      bits-per-pixel: {4, 8, 16, 24, 32}
                      scanline-pad: {8, 16, 32}]
             SCREEN: [root: WINDOW
                      device: DEVICE
                      width-in-pixels, height-in-pixels: CARD16
                      width-in-millimeters,height-in-millimeters:CARD16
                      allowed-depths: LISTofDEPTH
                      root-depth: CARD8
                      root-visual: VISUALID
                      default-colormap: COLORMAP
                      white-pixel, black-pixel: CARD32
                      min-installed-maps, max-installed-maps: CARD16
                      backing-stores: {Never, WhenMapped, Always}
                      save-unders: BOOL
                      current-input-masks: SETofEVENT]
            DEPTH: [depth: CARD8
                      visuals: LISTofVISUALTYPE]
            VISUALTYPE: [visual-id: VISUALID
                         class: {StaticGray, StaticColor,
                                 TrueColor,GrayScale, PseudoColor,
                                 DirectColor}
                                 red-mask, green-mask, blue-mask: CARD32
                                 bits-per-rgb-value: CARD8
                                 colormap-entries: CARD16]

   Per server information:

   The vendor string gives some indentification of the owner of the
   server implementation.  The semantics of the release-number is
   controlled by the vendor.

   The resource-id-mask contains a single contiguous set of bits (at
   least 18); the client allocates resource ids by choosing a value
   with (only) some subset of these bits set, and ORing it with
   resource-id-base.  Only values constructed in this way can be
   used to name newly created resources over this connection.
   Resource ids never have the top 3 bits set.  The client is not
   restricted to linear or contiguous allocation of resource ids.
   Once an id has been freed, it can be reused, but this should not
   be necessary. An id must be unique with respect to the ids of
   all other resources, not just other resources of the same type.

   Although the server is in general responsible for byte swapping
   data to match the client, images are always transmitted and
   received in formats (including byte order) specified by the
   server.  The byte order for images is given by image-byte-order,
   and applies to each scanline unit in XYFormat (bitmap) format,
   and to each pixel value in ZFormat.

   A bitmap is represented in scanline order.  Each scanline is padded
   to a multiple of bits as given by bitmap-format-scanline-pad.  The



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


   pad bits are of arbitrary value.  The scanline is quantized in
   multiples of bits as given by bitmap-format-scanline-unit.  Within
   each unit, the leftmost bit in the bitmap is either the least or
   most significant bit in the unit, as given by
   bitmap-format-bit-order.  If a pixmap is represented in XYFormat,
   each plane is represented as a bitmap, and the planes appear from
   most to least significant in bit order.

   For each pixmap depth supported by some screen, pixmap-formats lists
   the ZFormat used to represent images of that depth.  In ZFormat, the
   pixels are in scanline order, left to right within a scanline.  The
   number of bits used to hold each pixel is given by bits-per-pixel,
   and may be larger than strictly required by the depth.  When the
   bits-per-pixel is 4, the order of nibbles in the byte is the same as
   the image byte-order.  Each scanline is padded to a multiple of bits
   as given by scanline-pad.

   How a pointing device roams the screens is up to the server
   implementation, and is transparent to the protocol.  No geometry
   among screens is defined.

   The server may retain the recent history of pointer motion, and to a
   finer granularity than is reported by MotionNotify events.  Such
   history is available via the GetPointerMotions request.  The
   approximate size of the history buffer is given by
   motion-buffer-size.

   Maximum-request-length specifies the maximum length of a request, in
   4-byte units, accepted by the server; i.e., this is the maximum value
   that can appear in the length field of a request.  Requests larger
   than this generate a Length error, and the server will read and
   simply discard the entire request.  Maximum-request-length will
   always be at least 4096 (i.e., requests of length up to and including
   16384 bytes will be accepted by all servers).

   Per screen information:

   The allowed-depths specifies what pixmap and window depths are
   supported.  Pixmaps are supported for each depth listed, and windows
   of that depth are supported if at least one visual type is listed for
   the depth.  A pixmap depth of one is always supported and listed, but
   windows of depth one might not be supported.  A depth of zero is
   never listed, but zero-depth InputOnly windows are always supported.

   Root-depth and root-visual specify the depth and visual type of the
   root window.  Width-in-pixels and height-in-pixels specify the size
   of the root window (which cannot be changed).  The class of the root
   window is always InputOutput.  Width-in-millimeters and
   height-in-millimeters can be used to determine the physical size and
   the aspect ratio.