连接设置¶
初始化连接
服务端响应
服务端信息
屏幕信息
显示相关信息
初始化连接¶
客户端必须发送一个初始字节的数据来确定要使用的字节顺序。字节的值必须为八进制’102’或’154’。
‘102’ (ASCII大写字母B)表示先传输最高有效位字节
‘154’ (ASCII小写字母l)表示先传输最低有效位字节
除协议中明确注明外，客户端发送的所有16位和32位数量都必须按此字节顺序传输，服务器返回的所有16位和32位数量都将按此字节顺序传输。
在字节顺序字节之后，客户端在连接建立时发送以下信息:
协议主版本：CARD16
协议副版本：CARD16
协议验证名：STRING8
协议验证数据：STRING8
版本号表示客户端希望服务器实现的协议版本。
授权名称指示客户机希望服务器使用的授权(和身份验证)协议，并且数据特定于该协议。有效授权机制的规范不是核心X协议的一部分。不实现客户端期望的协议或只实现基于主机的机制的服务器可能会简单地忽略此信息。如果名称字符串和数据字符串都为空，则将其解释为“没有显式授权”。
服务端响应¶
客户端在连接建立时接收到以下信息:
success: { Failed, Success, Authenticate}
如果返回的成功值为Failed，则客户端接收到以下附加数据，表示连接未成功建立:
protocol-major-version: CARD16
protocol-minor-version: CARD16
reason: STRING8
如果返回的成功值为Authenticate，则客户端接收到以下附加数据，需要进行进一步的身份验证协商:
reason: STRING8
原因字符串的内容特定于正在使用的授权协议。此身份验证协商的语义不受约束，除了协商最终必须以包含成功值Failed或success的服务器应答而终止外。
如果返回的成功值为success，则客户端接收到以下附加数据，表明连接建立成功:
protocol-major-version: CARD16
protocol-minor-version: CARD16
vendor: STRING8
release-number: CARD32
resource-id-base, resource-id-mask: CARD32
image-byte-order: { LSBFirst, MSBFirst }
bitmap-scanline-unit: {8, 16, 32}
bitmap-scanline-pad: {8, 16, 32}
bitmap-bit-order: { LeastSignificant, MostSignificant }
pixmap-formats: LISTofFORMAT
roots: LISTofSCREEN
motion-buffer-size: CARD32
maximum-request-length: CARD16
min-keycode, max-keycode: KEYCODE
where:
FORMAT: [depth: CARD8,
bits-per-pixel: {1, 4, 8, 16, 24, 32}
scanline-pad: {8, 16, 32}]
SCREEN: [root: WINDOW
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]
服务端信息¶
服务器的全局信息是: 协议版本号以防将来需要对协议进行修订。一般来说，主要版本将为不兼容的更改增加，而次要版本将为较小的向上兼容更改增加。除非有变化，主版本将是11，次版本将是0。返回的协议版本号表示服务器实际支持的协议。这可能不等于客户端发送的版本。服务器可以(但不需要)拒绝来自提供与服务器支持的版本不同的客户端的连接。一个服务器可以(但不需要)同时支持多个版本。
供应商字符串给出了服务器实现所有者的一些标识。供应商控制发布号的语义。
资源-id-掩码包含一组连续的位(至少18位)。客户端为WINDOW、PIXMAP、CURSOR、FONT、GCONTEXT和COLORMAP类型分配资源id，方法是选择一个只设置了这些位的一些子集的值，并使用resource-id-base对其进行ORing。只有以这种方式构造的值才能用于在此连接上命名新创建的资源。资源id从不设置前三位。客户端不限于线性或连续分配资源id。一旦ID被释放，它就可以被重用。相对于所有其他资源的ID, ID必须是唯一的，而不仅仅是相同类型的其他资源。但是，请注意，资源标识符、原子、可视化和键符的值空间是根据上下文区分的，因此，不需要不相交;例如，给定的数值可能同时是有效的窗口ID、有效的原子和有效的键符。
虽然服务器通常负责对数据进行字节交换以匹配客户机，但图像总是以服务器指定的格式(包括字节顺序)传输和接收。图像的字节顺序由图像字节顺序给出，并适用于XY格式(位图格式)的每个扫描线单元和Z格式的每个像素值。
位图按扫描线顺序表示。每个扫描线被填充为bitmap-scanline-pad给出的多个位。填充位的值是任意的。扫描线按位图-扫描线单元给出的位数倍数进行量化。位图扫描线单元总是小于或等于位图扫描线垫。在每个单元中，位图中最左边的位要么是单元中最低有效位，要么是最高有效位，由位图-位顺序给出。如果像素图以XY格式表示，则每个平面都表示为位图，并且平面按位顺序从最高有效到最低有效，平面之间没有填充。
像素图格式为每个深度值包含一个条目。该条目描述了用于表示该深度图像的Z格式。如果任何屏幕支持该深度，则包含深度条目，并且支持该深度的所有屏幕必须仅支持该深度的Z格式。在Z格式中，像素在扫描线内按从左到右的扫描线顺序排列。用于保存每个像素的比特数由比特每像素给出。每像素位数可能大于深度的严格要求，在这种情况下，最低有效位用于保存像素图数据，未使用的高阶位的值是未定义的。当每像素位为4时，字节中的咬痕顺序与图像的字节顺序相同。当每像素位数为1时，格式与位图格式相同。每条扫描线被填充为扫描线垫给出的位的倍数。当bitps -per-pixel为1时，这将与bitmap-scanline-pad相同。
指向设备如何在屏幕上漫游取决于服务器实现，并且对协议是透明的。屏幕之间没有定义几何形状。
服务器可能会保留指针运动的最近历史记录，并且这样做的粒度比MotionNotify事件报告的粒度更细。GetMotionEvents请求使这样的历史记录可用。motion-buffer-size给出了历史缓冲区中元素的大致最大数目。
maximum -request-length指定服务器接受的请求的最大长度，单位为4字节。也就是说，长度是请求的长度字段中可以出现的最大值。大于这个最大值的请求会产生Length错误，服务器将读取并丢弃整个请求。最大请求长度将始终至少为4096(也就是说，所有服务器将接受长度不超过16384字节的请求)。
Min-keycode和max-keycode表示服务器传输的最小键码值和最大键码值。Min-keycode不小于8,max-keycode不大于255。并非此范围内的所有键码都需要具有相应的键。
屏幕信息¶
每个屏幕适用的信息是:
allowed-depth指定所支持的像素图和窗口深度。所列的每个深度都支持像素图，如果为该深度列出了至少一种视觉类型，则支持该深度的窗口。像素图深度为1总是被支持和列出，但深度为1的窗口可能不被支持。不会列出深度为0的窗口，但始终支持零深度的InputOnly窗口。
root-depth和root-visual指定根窗口的深度和可视化类型。像素宽度和像素高度指定根窗口的大小(不能更改)。根窗口的类总是InputOutput。毫米宽度和毫米高度可用于确定物理尺寸和长宽比。
默认颜色映射是最初与根窗口关联的颜色映射。具有最小颜色要求的客户端创建与根相同深度的窗口，默认情况下可能希望从该映射分配。
黑像素和白像素可用于实现单色应用程序。这些像素值用于default-colormap中永久分配的条目。实际的RGB值可以在某些屏幕上设置，并且在任何情况下，实际上可能不是黑白的。这些名称旨在传达颜色的预期相对强度。
根窗口的边界最初是一个填充了黑色像素的像素图。根窗口的初始背景是一个像素图，使用黑像素和白像素填充一些未指定的双色图案。
Min-installed-maps指定可以保证同时安装的map的数量(使用InstallColormap)，而不管在每个map中分配了多少项。Max-installed-maps指定可能同时安装的最大映射数量，具体取决于它们的分配情况。多个具有相同内容但资源ID不同的静态视觉彩色地图应被视为该数字的单个地图。对于单个硬件颜色图的典型情况，两个值都为1。
back- stores指示服务器何时支持此屏幕的后备存储，尽管它可能在一次可以支持的窗口数量中受到存储限制。如果save-under为True，则服务器可以在CreateWindow和changewindowwatattributes中支持save-under模式，尽管它可能再次受到存储限制。
当前输入事件是getwindowatattributes将为根窗口的所有事件掩码返回的事件。
Visual 信息¶
适用于每个Visual类型的信息是:
给定的Visual类型可以为多个深度或多个屏幕列出。
对于PseudoColor，像素值索引颜色图以生成独立的RGB值;RGB值可以动态改变。灰度与PseudoColor的处理方式相同，除了未定义哪个主要驱动屏幕;因此，客户端应该始终为颜色映射中的红色、绿色和蓝色存储相同的值。对于DirectColor，像素值被分解为单独的RGB子字段，每个子字段分别索引对应值的颜色图。RGB值可以动态更改。TrueColor的处理方式与DirectColor相同，除了颜色映射具有预定义的只读RGB值。这些值与服务器相关，但在每个主服务器中提供线性或近似线性的增长坡道。StaticColor的处理方式与PseudoColor相同，只是颜色映射具有预定义的只读RGB值，这些值依赖于服务器。StaticGray的处理方式与StaticColor相同，只是对于任何单个像素值，红色、绿色和蓝色值是相等的，从而产生灰色阴影。具有两项颜色映射的StaticGray可以被认为是单色的。
红色蒙版、绿色蒙版和蓝色蒙版仅为DirectColor和TrueColor定义。每个都有一个连续的位集设置为1，没有交集。通常每个掩码都有相同的位数设置为1。
bit-per-rgb-value指定以2为基数的红、绿、蓝不同颜色强度值的对数。这个数字不需要与颜色映射条目的数量有任何关系。实际的RGB值总是在16位频谱内的协议中传递，0是最小强度，65535是最大强度。在提供线性零基强度斜坡的硬件上，存在以下关系:
Hw-intensity =协议强度/ (65536 / total- Hw-intensity) Colormap条目从0开始索引。colormap-entries定义了新创建的colormap中可用的colormap条目的数量。对于DirectColor和TrueColor，这通常是在红色蒙版，绿色蒙版和蓝色蒙版中设置为1的最大位数的2次方。