X Window核心協議

X Window 核心协议是X窗口系统的基础协议，它是一个以位图显示的网络化视窗系统，用来在Unix、类Unix和其它操作系统上创建用户图形界面。X Window 系统基于主从式模型：单一服务器控管硬件的输出入，如屏幕、键盘和鼠标；所有的应用程序都被视作客户端，用户之间通过服务器来交互。交互部分由X Window核心协议来管理。还有其它与X窗口系统有关的协议，有的创建在X Window核心协议之上的，有的是独立的协议。
在X Window核心协议中，只会在网络上以异步方式发送四种数据包：请求、回应、事件和错误。请求是由客户端发送到服务器，告之进行一些动作（例如创建一个视窗），并回传以便持握的数据。回应是由服务器回传的若干数据。事件是由服务器发送的，其用来通知客户端某些用户的动作，或者发生了其它所关心的事件。错误是由服务器发送的数据包，其用来通知客户端，在处理其请求时，发生了一些错误。请求有可能产生回应、事件和错误；除此之外，协议并不要求数据包中的特定指令要以网络来发送。还有其它对核心协议的扩充，这些扩充有自己的请求、回应、事件和错误。
X Window 源于1984年的麻省理工学院（目前所发布的X11 发表于1987年9月）。设计者鲍伯·斯凯夫勒（Bob Scheifler）和吉姆·杰提斯（Jim Gettys）早期对核心协议的原则是“机制，而非策略”，所以核心协议并未规定客户端之间以及客户端和用户之间的交互界面规范。这部分则由其它的独立规格所规范，如ICCCM、freedesktop.org规范，且可由所使用的特定组件工具包自动强制运行。

视窗

在X窗口系统以及各种图形化用户界面中，视窗即为一个顶层视窗。视窗也用来指视窗内部的视窗，这类视窗是父视窗的子视窗。图形化组件，如按钮、菜单、图标等等，都是使用视窗来实现的。
客户端可请求创建一个视窗。更严谨的说，客户端可请求创建现存视窗的子视窗。所以客户端所创建的视窗，皆以树状结构组织（层次结构结构）。树状结构的根即为根视窗，根视窗是服务器在引导时，所自动创建的特殊视窗。其余视窗都是根视窗的子视窗，顶层视窗就是根视窗下的第一个子视窗。如图所见，根视窗和屏幕同等大小，且在其余视窗的后面（被子视窗遮盖住）。
视窗里的内容并非在所有时候都能显示出来。更精确地说，在视窗移动、调整大小、被其它视窗遮盖、部分或整个视窗不可见时，视窗里的内容就有可能会被销毁。更精确地说，如果 X 服务器无法维护视窗内容的后备存放区（backing store）时，这些内容就会丢失。客户端可请求为视窗进行维护的后备存放区，但服务器没有义务要这样做。因此，客户端不可假设已得到后备存放区的维护。若视窗有一部分未指出内容时，就会发送一个事件，通知客户端重绘那部分内容。
每个视窗都关系一组属性值（Attribute），如视窗的几何性质（大小和位置）、背景图、是否请求了后备存放区等等。协议中还包含用来给客户端检阅和改变视窗属性值的请求。
视窗可以是InputOutput（输出／输入）或 InputOnly（仅输入）。前者是显示在屏幕上用于绘图的视窗，而后者并不显示在屏幕上，仅用来接受输入。
平常可看到视窗周围的装饰性框架和标题栏（可能含有按钮），是由视窗管理器所创建的视窗，而非客户端所创建的。视窗管理器也处理与组件有关的输入，例如当用户点击并拖曳视窗的边框时，便会调整视窗大小。客户端所创建的视窗，通常可以忽略视窗管理器所带来的变化。还有一个改变必须注意，那就是改变亲属关系的视窗管理器，几乎所有新式的视窗管理器，都会将顶层视窗的亲属关系改变到一个视窗（不是根视窗）里去。从核心协议的角度来看，视窗管理器是一个客户端，与其它的应用程序没有区别。
关于视窗的数据，可运行xwininfo 程序来获取。加上-tree命令行参数，程序便会显示子视窗的树状结构，连同识别子和几何性质数据一起显示。

图形映射和可绘区

图形映射（pixmap）是内存中可用来绘图的区域。与视窗不同，图形映射的内容并不会自动显示在屏幕上。不过图形映射的内容（或部分内容）可转换到视窗上，反之亦然。这就让双缓冲得以实现。大部分可在视窗上完成的图形化操作，也可以图形映射完成。
视窗和图形映射被统称为可绘区（drawable），且其数据内容都保留在服务器上。客户端可请求从服务器上，将可绘区的内容转换到客户端，反之亦然。

图形上下文和字体

客户端可请求很多种图形运算，如清空一块区域、复制一块区域到另一处，绘制一个点、线、矩形和文字。对清空而言，所有运算都有可能用在可绘区上（视窗和图形映射）。
图形上下文（graphic context）包括了对图形运算的大部分请求，图形上下文是一种结构，包含有图形运算的参数。图形上下文包含前景色、背景色、文字的字体，以及各种图形参数。当请求图形运算时，客户端就包含一个图形上下文。很明显的，并非所有的图形上下文参数都会参与运算：例如，字体对于直线的绘制不产生作用。
核心协议规格使用了服务器侧的字体。如字体是以文件形式存放，服务器经由本机的文件系统直接访问，或经由网络从字体服务器访问。客户端可向服务器请求有效的字体列表，且可请求服务器加载（没有的话）或卸载（客户端不再需要的话）字体。客户端可请求关于字体的信息（例如，ascent 字体），并以指定的字体来绘制指定的字符串。
在X Window核心协议的层次上，字体的名称可以是任意的字符串。X 逻辑字体描述协议规范了如何根据字体的属性来命名。这些协议也规范了可附属于字体的选用属性之值（value）。
xlsfonts 程序可输出存放在服务器上的字体列表。xfontsel 程序可显示字体的标记，并让用户选取字体的名称，以在其它视窗中粘贴。
目前已不再重视服务器侧字体的使用，而转向客户端侧字体的使用。例如，借由支持Xft或cairo程序库，以及XRender扩充，改由客户端（而非服务器）绘制字体。客户端侧字体在核心协议中尚未给出规范。

事件

事件是由服务器发送到客户端用以通信的数据包，发送一些客户端可能感兴趣的事情。例如，当用户按下按键或点击鼠标时，便会发送一个事件。事件不只用于输入：例如，发送的事件表明特定视窗创建了新的子视窗。
每一个事件都会涉及到视窗。例如，当用户的鼠标在视窗之内并点击时，这个事件就会涉及到那个视窗。事件数据包中含有那个视窗的识别子。
客户端可以请求服务器发送事件给另一个客户端，这可用于客户端之间的通信。例如，当客户端请求目前所选取的文字时，就会发送事件给客户端，以处理目前所持有的选取内容。
当再度观看内容已被销毁的区域时，有可能会发送Expose（显露）事件。而且在某些情况下，视窗的内容可能会被销毁。例如，当视窗被其它视窗遮盖住，且服务器没有维护后备存放区时。此时服务器会产生一个Expose 事件，以通知客户端重绘视窗已消失的部分。
大部分的事件只会在客户端预先表示关心时才会发送。因为客户端可能只需要关心某类型的事件。例如，客户端可能会关心关于键盘的事件，但却不关心关于鼠标的事件。即使在客户端并未明确请求的情况下，某几类事件也会不断的发送给客户端。
客户端可以设置视窗的属性值（attribute），以指明想要接收哪些事件。例如，当视窗的内容已销毁时，为重绘其内容，客户端就必须接收Expose 事件，以通知视窗需要再次重绘。客户端要能接收到Expose 事件，就要预先指明它所关心的事件，这部分可以适当设置视窗属性值的事件掩码来完成。
不同的客户端可以请求同一视窗的事件。甚至可对同一视窗设置不同的事件掩码。例如，某个客户端可以只对视窗请求键盘事件，而另一个客户端只对视窗请求鼠标事件。这是可以的，因为服务器会为每一个客户端维护事件掩码，而且是每一个视窗都维护一份独立的事件掩码。不过偶尔也有某几类事件，只能由一个客户端选择。特别是，这类事件回报鼠标按钮的点击，且部分变化会涉及到视窗管理器。
xev 程序显示视窗所涉及到的事件。xev -id WID 可对识别子为WID 的视窗要求所有可能的事件，并将其输出。

元素

元素（Atoms）是用来表示字符串的32位整数。本协议的设计者之所以引入元素，是为了以简短、大小恒定的方式表示字符串：由于字符串可以是任意的长度，而元素总是32位整数。某些数据包可能会多次发送相同的字符串，元素的简短性可以削减指令所使用的数据包长度，进而增进网络的使用效率。大小恒定的元素有利于大小恒为32位组的事件：大小恒定的数据包可以包含元素，却不能包含过长的字符串。
更严谨的说，元素是存放在服务器上的字符串的识别子，相当于资源的识别子（视窗、图形映射等），但仍有两个不同点。首先，元素的识别子是由服务器选择的，而非客户端。换句话说，当客户端请求创建一个新的元素时，其仅仅发送字符串给服务器存放，而非字符串的识别子；元素的识别子是由服务器选择，并回传给客户端作为回应。其次，资源和元素之间的重大差异是，元素并未与客户端相连系。元素一经创建，就能一直存留至服务器结束或重置（此非资源的默认行为）。
元素是识别子，所以也是独一无二的。不过元素和资源的识别子可以相一致。与元素关系的字符串称作元素名。元素的名称一经创建就不能再更改，而且不能有两个相同名称的元素。故一般以元素的内容作为元素的名称：“元素 ABCD”意谓著，或更精确地说，“这个元素关系的字符串是ABCD”或“元素的名称是ABCD”。客户端可以请求创建新的元素，且可请求指定字符串的元素（识别子）。某些元素已预先定义（由服务器以特定的识别子和字符串所创建）。
元素运用于多个目的，主要与连接到同一服务器的不同客户端之间有关。特别是，元素用于与视窗属性的关系，以下详述。
所有存在于服务器上的元素列表，可使用xlsatoms 程序输出。尤其这个程序可以元素的名称（元素所关系的字符串）列出每一个元素（识别子是一串数字）。

属性

每一个视窗都有一组预先定义的属性值（Attribute）和属性（Property），并存放在服务器上，客户端可以适当的请求方式取存。属性值是有关视窗方面的数据，如视窗的大小、位置、背景色等等。属性则是附属于视窗上的数据片断。与属性值相反，属性在X Window核心协议的层次中并没有其它含意。客户端可在视窗的属性中存放属性值数据。
属性是以名称、类型和值来描述，属性相当于指令式编程语言的变量，应用程序可以指定名称、类型和值来创建新的属性。属性和视窗关系：两个相同名称的属性可存在于两个不同的视窗，且可具有不同的类型和值。
属性的名称、类型和值皆为字符串；更精确地说就是元素，客户端可借由识别字，以访问存放在服务器上的字符串。客户端应用程序可以元素的识别子（含有属性的名称）访问特定的属性。
属性大多用于客户端之间的通信。例如，名称为WM_NAME（属性名称就是元素所关系的字符串"WM_NAME"）的属性，是用来存放视窗的名称；视窗管理器通常会读取这个属性，并在视窗顶部显示名称。
某些客户端之间的通信也使用了根视窗的属性。例如，根据freedesktop视窗管理器规格视窗管理器应该在根视窗的_NET_ACTIVE_WINDOW 属性名中存放目前有效（active）视窗的识别子。X资源所含有的程序参数，同样也是存放在根视窗的属性里；借由这个方式，即使分别运行在不同电脑上，所有客户端仍可访问到那些参数。
xprop 程序可输出指定视窗的属性，xprop -root 则可输出根视窗每一个属性的名称、类型和值。

其它

还有其它的请求和事件，有一种请求是有关视窗之间的亲属关系：客户端可请求改变视窗的父视窗，或请求关于父视窗的信息。其它的请求则是关于选取，这部分大多由其它的协议来管理。还有的请求是关于输入焦点和游标的形状。客户端也可请求将资源（视窗、图形映射等等）的所有者杀死，这会使服务器终止和那个所有者的连接。最后，客户端还可发送空运算请求给服务器。

扩充

X Window 核心协议被设计成可扩充。核心协议指定一个机制用来查询可用的扩充，以及如何产生扩充的请求、事件和错误数据包。
更精确地说，客户溯可以请求所有可用的扩充的清单，扩充的数据包相当于核心协议的数据包。核心协议指定请求、事件和错误数据包要包含一个指明其类型的整数（例如，创建一个新视窗的请求是号码1）。一部分范围的整数已保留给扩充。

授权

在客户端和服务器刚开始创建连接的时候，服务器的回应可以是接受、拒绝或要求验证。验证请求包含要使用的验证方法的名称。核心协议并不规范验证程序，这部分要看所使用的验证类型，并在服务器发送接受或拒绝数据包之后结束。
在客户端和服务器之间正常交互的时候，只有在涉及基于主机的访问方式的验证才要请求。更精确地说，客户端可要求激活这个方式，并请求读入和改变主机（客户端）（经授权的连接）的清单。一般的应用程序不使用这类请求；xhost 程序使用这类请求，给用户或Shell script访问主机访问清单。基于主机的访问方式被认为是不安全的。

X Window 核心协议不规定什么

X Window 核心协议并不硬性规定客户端之间的通信方法，也不指明如何用视窗作成可视化组件（图形用户界面如按钮、菜单等），GUI 组件则交由客户端程序库实现相关的组件工具包。客户端之间的通信方法则交由其它的标准，如ICCCM和freedesktop规格 。
客户端之间的通信和选取、剪切缓冲器、拖曳有关，这些方法是用来让用户从某个视窗转移数据到另一个视窗。视窗有可能由不同的程序来控制，所以一个用来交换数据的协议是必要的。客户端之间的通信和X视窗管理器同样也有关系，它是用来管理视窗的外观并统一用户界面。另一个和客户端之间的通信有某种程度上的关系的还有期间管理。
用户的期间要如何开始，也是核心协议未能涵盖到的问题，这部分通常由X显示管理器自动完成。用户也可以运行xinit或startx程序，以手动的方式开始一个X会话。