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對談。