From 10b0200992ee81c0749a69eeba1a05562d724b3a Mon Sep 17 00:00:00 2001 From: Alan Coopersmith Date: Fri, 3 Dec 2010 22:00:44 -0800 Subject: spec: Fix section title markup in Connection Setup chapter Signed-off-by: Alan Coopersmith --- specs/sect1-9.xml | 230 +++++++++++++++++++++++++----------------------------- 1 file changed, 105 insertions(+), 125 deletions(-) (limited to 'specs/sect1-9.xml') diff --git a/specs/sect1-9.xml b/specs/sect1-9.xml index f84c5a5..9738071 100644 --- a/specs/sect1-9.xml +++ b/specs/sect1-9.xml @@ -1117,21 +1117,17 @@ other names. -Connection Setup - - - - + Connection Setup + + For remote clients, the X protocol can be built on top of any reliable byte stream. - + - -Connection Initiation - +
+ Connection Initiation - - + 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. @@ -1143,12 +1139,12 @@ 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 client sends the following information at connection setup: - -
+ +
protocol-major-version: CARD16 @@ -1161,12 +1157,12 @@ authorization-protocol-name: STRING8 authorization-protocol-data: STRING8 -
- +
+ The version numbers indicate what version of the protocol the client expects the server to implement. - - + + The authorization name indicates what authorization (and authentication) protocol the client expects the server to use, and the data is specific to that protocol. @@ -1177,14 +1173,15 @@ or that only implements the host-based mechanism may simply ignore this information. If both name and data strings are empty, this is to be interpreted as "no explicit authorization." - - -Server Response - + +
- +
+ Server Response + + The client receives the following information at connection setup: - + @@ -1197,12 +1194,12 @@ success: - + The client receives the following additional data if the returned success value is Failed, and the connection is not successfully established: - +
@@ -1216,12 +1213,12 @@ reason: STRING8
- + The client receives the following additional data if the returned success value is Authenticate, and further authentication negotiation is required: - +
@@ -1229,7 +1226,7 @@ reason: STRING8
- + The contents of the reason string are specific to the authorization protocol in use. The semantics of this authentication negotiation are not constrained, except that the negotiation must eventually terminate @@ -1237,14 +1234,14 @@ with a reply from the server containing a success value of Failed or Success. - + - + The client receives the following additional data if the returned success value is Success, and the connection is successfully established: - +
@@ -1415,17 +1412,16 @@ PseudoColor, DirectColor}
+
- -Server Information - +
+ Server Information - + The information that is global to the server is: - + - - + The protocol version numbers are an escape hatch in case future revisions of the protocol are necessary. In general, @@ -1439,15 +1435,13 @@ 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. - - - + + The vendor string gives some identification of the owner of the server implementation. The vendor controls the semantics of the release number. - - - + + The resource-id-mask contains a single contiguous set of bits (at least 18). The client allocates resource IDs for types WINDOW, PIXMAP, CURSOR, FONT, GCONTEXT, and COLORMAP by choosing a value with only @@ -1465,18 +1459,16 @@ However, note that the value spaces of resource identifiers, atoms, visualids, and keysyms are distinguished by context, and as such, are not required to be disjoint; for example, a given numeric value might be both a valid window ID, a valid atom, and a valid keysym. - - - + + 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 XY format (bitmap format) and to each pixel value in Z format. - - - + + A bitmap is represented in scanline order. Each scanline is padded to a multiple of bits as given by bitmap-scanline-pad. The pad bits are of arbitrary value. @@ -1490,9 +1482,8 @@ If a pixmap is represented in XY format, each plane is represented as a bitmap, and the planes appear from most significant to least significant in bit order with no padding between planes. - - - + + Pixmap-formats contains one entry for each depth value. The entry describes the Z format used to represent images of that depth. An entry for a depth is included if any screen supports that depth, @@ -1512,15 +1503,13 @@ the format is identical for bitmap format. Each scanline is padded to a multiple of bits as given by scanline-pad. When bits-per-pixel is 1, this will be identical to bitmap-scanline-pad. - - - + + How a pointing device roams the screens is up to the server implementation and is transparent to the protocol. No geometry is defined among screens. - - - + + The server may retain the recent history of pointer motion and do so to a finer granularity than is reported by MotionNotify @@ -1530,9 +1519,8 @@ The request makes such history available. The motion-buffer-size gives the approximate maximum number of elements in the history buffer. - - - + + Maximum-request-length specifies the maximum length of a request accepted by the server, in 4-byte units. That is, length is the maximum value that can appear in the length field of a @@ -1544,24 +1532,24 @@ and the server will read and simply discard the entire request. Maximum-request-length will always be at least 4096 (that is, requests of length up to and including 16384 bytes will be accepted by all servers). - - - + + Min-keycode and max-keycode specify the smallest and largest keycode values transmitted by the server. Min-keycode is never less than 8, and max-keycode is never greater than 255. Not all keycodes in this range are required to have corresponding keys. - - -Screen Information - - + +
+ +
+ Screen Information + + The information that applies per screen is: - + - - + 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 @@ -1572,9 +1560,8 @@ 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 @@ -1583,16 +1570,14 @@ 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. - - - + + The default-colormap is the one initially associated with the root window. Clients with minimal color requirements creating windows of the same depth as the root may want to allocate from this map by default. - - - + + Black-pixel and white-pixel can be used in implementing a monochrome application. These pixel values are for permanently allocated entries in the @@ -1600,15 +1585,13 @@ default-colormap. The actual RGB values may be settable on some screens and, in any case, may not actually be black and white. The names are intended to convey the expected relative intensity of the colors. - - - + + The border of the root window is initially a pixmap filled with the black-pixel. The initial background of the root window is a pixmap filled with some unspecified two-color pattern using black-pixel and white-pixel. - - - + + Min-installed-maps specifies the number of maps that can be guaranteed to be installed simultaneously (with InstallColormap), @@ -1619,9 +1602,8 @@ Multiple static-visual colormaps with identical contents but differing in resource ID should be considered as a single map for the purposes of this number. For the typical case of a single hardware colormap, both values will be 1. - - - + + Backing-stores indicates when the server supports backing stores for this screen, although it may be storage limited in the number of windows it can support at once. @@ -1632,28 +1614,27 @@ the server can support the save-under mode in and ChangeWindowAttributes, although again it may be storage limited. - - - + + The current-input-events is what GetWindowAttributes would return for the all-event-masks for the root window. - - - -Visual Information - - - + +
+ +
+ Visual Information + + The information that applies per visual-type is: - - - + + + A given visual type might be listed for more than one depth or for more than one screen. - - - + + + For PseudoColor, a pixel value indexes a colormap to produce independent RGB values; @@ -1687,18 +1668,18 @@ except the red, green, and blue values are equal for any single pixel value, resulting in shades of gray. StaticGray with a two-entry colormap can be thought of as monochrome. - - - + + + The red-mask, green-mask, and blue-mask are only defined for DirectColor and TrueColor. Each has one contiguous set of bits set to 1 with no intersections. Usually each mask has the same number of bits set to 1. - - - + + + The bits-per-rgb-value specifies the log base 2 of the number of distinct color intensity values (individually) of red, green, and blue. This number need not bear any relation to the number of colormap entries. @@ -1707,17 +1688,15 @@ Actual RGB values are always passed in the protocol within a maximum intensity. On hardware that provides a linear zero-based intensity ramp, the following relationship exists: - - - - + + + hw-intensity = protocol-intensity / (65536 / total-hw-intensities) - - - - + + + Colormap entries are indexed from 0. The colormap-entries defines the number of available colormap entries in a newly created colormap. @@ -1727,9 +1706,10 @@ and TrueColor, this will usually be 2 to the power of the maximum number of bits set to 1 in red-mask, green-mask, and blue-mask. - - + +
+ Requests -- cgit v1.2.3