📄 rfc1013.txt
字号:
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.
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -