X Window System core protokol

X Window System core protokol^[1][2][3] je základním protokolem X Window System, který je síťovým okenním systémem užívaným k tvorbě grafického uživatelského rozhraní pro Unix a další operační systémy. X Window System je postaven na modelu klient–server: samostatný server ovládá vstup/výstup hardwaru, například obrazovku, klávesnici, a myš. Všechny aplikace se chovají jako klienti, komunikují s uživatelem a s dalšími aplikacemi pomocí serveru. Tato interakce je řízena pomocí X Window System core protokolu.

V X Window System core protokolu jsou používány pouze 4 druhy paketů, které jsou posílány asynchronně po síti: požadavky, odpovědi, události a chyby. Požadavky posílá klient na server, aby ho požádat o provedení určitých operací (například vytvoření nového okna) a o zaslání dat s odpovědí. Odpovědi jsou posílány serverem a obsahují poskytovaná data. Události jsou posílány serverem, aby informovaly klienty o uživatelských aktivitách nebo jiných zajímavých okolnostech. Server odesílá chyby v paketech, aby podal klientovi oznámení o chybách, které nastaly během zpracování jejich žádosti. Požadavky mohou generovat odpovědi, události a chyby. Kromě toho protokol nenařizuje, v jakém pořadí mají být pakety odesílány po síti. Existují také další rozšíření core protokolu. Každé z těchto rozšíření obsahuje vlastní požadavky, odpovědi, události a chyby.

Protokol byl vytvořen roku 1984 na univerzitě MIT, současná verze X11 byla vydána v roce 1987. Jeho tvůrci Bob Scheifler a Jim Gettys zavedli hlavní princip, že jejich core protokol měl "vytvořit mechanismus, ne zákonitosti". Proto core protokol nespecifikuje interakce mezi klienty a mezi klientem a serverem. Ty jsou předmětem zvláštní specifikace,^[4] jako například ICCCM a freedesktop.org, a jsou typicky vynuceny automaticky využíváním dané knihovny widgetů.

Klient se serverem spolu komunikují výměnou paketů přes komunikační kanál. Spojení je navázáno klientem. (Způsob navázání spojení není v protokolu specifikován.) Klient také odesílá první paket obsahující pořadí bajtů, které bude použito, informace o verzi protokolu a způsob autentizace, který klient očekává od serveru. Server odpovídá zasláním paketu oznamujícím přijetí nebo odmítnutí spojení, nebo požadavkem na další autentizaci. Pokud je spojení přijato, paket oznamující přijetí obsahuje data pro klienta, která klient využívá pro další interakci se serverem.

Po ustanovení spojení mohou být mezi klientem a serverem vyměňovány 4 typy paketů.

1. Požadavek: Klient požaduje informace ze serveru nebo po serveru požaduje provedení nějaké akce.
2. Odpověď: Server odpovídá na požadavek. Ne všechny požadavky mají odpověď.
3. Událost: Server informuje klienta o události, například o stisku klávesy nebo tlačítka myši, přesunu okna, změně velikosti okna, atd.
4. Chyba: V případě chybného požadavku zasílá server paket oznamující chybu. Protože jsou požadavky řazeny do fronty, chybový paket nemusí být odeslán okamžitě.

Pakety s požadavky a odpověďmi mají proměnlivou délku, naopak pakety s událostmi a chybami mají pevně danou délku 32 bajtů.

Pakety s požadavky, jakmile jsou serverem přijaty, jsou číslovány postupně. První požadavek má číslo 1, druhý 2, atd. Nejméně významných 16 bitů z očíslování požadavku je zahrnuto v odpovědi a případně v paketu oznamujícím chybu. Jsou také zahrnuty v událostních paketech, aby naznačily očíslování požadavku, který je právě zpracováván, nebo bylo jeho zpracování právě dokončeno.

To, co bývá obvykle nazýváno oknem ve většině grafických prostředí, je v X Windows systému nazváno oknem na nejvyšší úrovni (anglicky top-leveled window). Pojem okno je také užíván k označení oken, které leží uvnitř jiného okna, což jsou podokna (anglicky subwindows) rodičovského okna (anglicky parent window). Grafické komponenty jako například tlačítka, menu, ikony a další mohou být vytvořeny použitím podoken.

Klient může požádat o vytvoření okna, přesněji může požádat o vytvoření podokna z již existujícího okna. Výsledkem je tedy hierarchické uspořádání oken vytvořených klientem do stromu. Kořenem tohoto stromu je hlavní okno, což je speciální okno vytvořené serverem automaticky při spuštění. Všechna ostatní okna jsou přímá nebo nepřímá podokna hlavního okna. Okna na nejvyšší úrovni jsou přímými podokny okna hlavního. Hlavní okno je tak veliké jako virtuální plocha a leží za všemi ostatními okny.

Zachování obsahu okna není vždy garantováno. Ten může být zničen zejména při přemísťování okna, při změně velikosti okna, nebo například při překrytí okna jiným oknem. Obecně dochází k jeho zničení, pokud není okno viditelné, nebo je vidět jen jeho část. Ke ztrátě obsahu okna dochází zejména, pokud X server neudržuje záložní uložení (anglicky backing store) obsahu okna. Klient může požádat, aby záložní uložení bylo udržováno, ale server nemá žádnou povinnost mu vyhovět. Klienti tedy nemohou předpokládat, že je záložní uložení udržováno. Pokud má viditelná část okna blíže neurčený obsah, je poslána událost upozorňující klienta, že obsah okna musí být znovu vykreslen.

Každé okno má přidruženou sadu atributů, jako například geometrii okna (velikost a pozice), obrázek na pozadí, cokoliv, o co bylo záložní uložení požádáno, atd. Protokol zahrnuje požadavky pro klienta na zkontrolování a změnu atributů okna.

Okna mohou být InputOutput (vstup i výstup) nebo InputOnly (pouze vstup). InputOutput okna mohou být zobrazena na obrazovce a jsou použita pro kreslení. InputOnly okna nejsou nikdy zobrazována na obrazovce a jsou použita pouze pro obdržení vstupu.

Orámování okna a titulek okna (možné i včetně tlačítek), které jsou většinou vidět okolo okna, jsou vytvořeny správcem oken, ne klientem, který vytváří samotná okna. Správce oken se také stará o vstupy související s těmito prvky, jako například o změnu velikosti v případě, že uživatel klikne na okenní rám a táhne s ním. Klienti většinou pracují na okně, které vytvořili, ignorujíce změny provedené správcem oken. Změna, která musí být vzata v úvahu, je, že re-parenting správci oken (většina dnešních moderních správců oken) mění rodiče okna na nejvyšší úrovni na okno, které není hlavní. Z pohledu core protokolu je správce oken klientem ničím nelišícím se od ostatních aplikací.

Data o oknu mohou být získána spuštěním programu xwiniinfo. Předání parametru -tree zobrazí program strom podoken okna spolu s jejich identifikátory a geometrickými daty.

Pixmapa je místo v paměti, na které je možné kreslit. Na rozdíl od oken nejsou pixmapy automaticky zobrazovány na obrazovce. Obsah pixmapy nebo jeho část lze libovolně přesouvat do okna a zpět, tato operace je možná díky double bufferování. Většina proveditelných grafických operací na oknech může být také provedena na pixmapách.

Okna a pixmapy se společně označují jako drawables a jejich obsah je uložen na serveru. Klient o něj může server požádat.

Klient může požadovat spoustu grafických operací jako například vymazání oblasti, zkopírování jedné oblasti do druhé, vykreslení bodů, čar, obdélníků a textu. Kromě vymazání jsou všechny operace možné jak v oknech, tak i na pixmapách.

Většina požadavků na grafické operace zahrnuje grafický kontext, což je struktura, která obsahuje parametry grafických operací. Grafický kontext zahrnuje barvu popředí, barvu pozadí, font textu a ostatní grafické parametry. Při požadavku na grafickou operaci klient zahrnuje grafický kontext. Ne všechny parametry grafického kontextu mají vliv na operaci, například font neovlivňuje vykreslení obdélníku.

Protokol specifikuje použití fontů na straně serveru.^[5] Takové fonty jsou uloženy jako soubory a server k nim přistupuje buď přímo přes lokální souborový systém, nebo přes síť z jiného programu nazvaného font server. Klient může požádat server o seznam fontů, které jsou na něm dostupné, a také o načtení (pokud se tak ještě nestalo) nebo vyřazení (pokud není použit jinými klienty) fontu. Klient může také požádat o obecné informace o fontu a o místu, které zabere konkrétní řetězec při vykreslení konkrétním fontem.

Jména fontů jsou libovolné řetězce na úrovni X Window core protokolu. Konvence X logical font description^[6] specifikuje, jak má být font pojmenován v závislosti na jeho atributech. Tyto konvence také specifikují hodnoty nepovinných vlastností, které mohou být připojeny k fontům.

Program xlsfonts tiskne seznam fontů uložených na serveru. Program xfontsel zobrazuje glify fontů a umožňuje uživateli vybrat jméno fontu pro vložení do dalšího okna.

Užití fontů na straně serveru je v současné době odmítané ve prospěch fontů na straně klienta.^[7] Takovéto fonty jsou vykreslovány klientem, ne serverem, s podporou Xft nebo cairo knihoven a rozšíření XRender. Fonty na straně klienta nejsou nijak specifikovány core protokolem.

Veškerá data o oknech, pixmapách, fontech a dalších objektech jsou uložena na serveru. Klient zná identifikátory těchto objektů, celá čísla, které používá při interakci se serverem. Například, pokud si klient vyžádá vytvoření okna, požádá server o vytvoření okna s daným identifikátorem. Identifikátor může být později použit klientem na další požadavky, příkladem může být vykreslení textového řetězce do daného okna. Následující objekty jsou na serveru a klient je zná díky číselnému identifikátoru:

• Okno
• Pixmapa
• Font
• Mapa barev (tabulka barev)
• Grafický kontext

Tyto objekty se nazývají zdroje. Pokud klient požaduje vytvoření zdroje, musí také specifikovat jeho identifikátor. Například při vytváření nového okna musí klient specifikovat nejen jeho atributy (rodič, šířka, výška, atd.), ale také mu musí přiřadit identifikátor.

Identifikátory jsou 32bitová celá čísla, u kterých se 3 nejvýznamnější bity rovnají nule. Každý klient má vlastní sadu identifikátorů, kterou může použít na vytvoření nových zdrojů. Tato sada je specifikována serverem jako dvě celá čísla připojená k paketu oznamujícímu přijetí spojení. Klienti volí identifikátory, které jsou v sadě tak, aby nedocházelo ke kolizím. Dva objekty (okna, pixmapy, fonty, mapy barev a grafické kontexty) nemohou mít stejný identifikátor.

Jakmile byl zdroj vytvořen, klient používá jeho identifikátor k požadavkům týkajících se zdroje na serveru. Některé operace ovlivňují daný zdroj (např. žádost k přesunu okna), další požadují data zdroje uložená na serveru (např. požadavky na atributy oken).

Identifikátory jsou jedinečné na serveru, ne pouze u klienta, např. dvě okna nemají stejné identifikátory, i když je vytvořili dva různí klienti. Klient má přístup k jakémukoli objektu, pokud je mu předán jeho identifikátor. Zvlášť má také přístup ke zdrojům vytvořeným jinými klienty, i když jejich identifikátory se nachází mimo sadu identifikátorů, které je klient schopný vytvořit.

V důsledku toho mohou dva klienti připojení na stejný server použít stejné identifikátory k odkazování na stejný zdroj. Například, pokud klient vytvoří okno s identifikátorem 0x1e00021 a předává toto číslo 0x1e00021 další aplikaci (jakýmkoli způsobem, například může toto číslo uchovávat v souboru, který je také přístupný dalším aplikacím), tato další aplikace je schopna pracovat na stejném okně. Tato možnost je například využívána X Window verzí Ghostview: tento program vytváří podokna, uloží jejich identifikátory v proměnném prostředí a zavolá Ghostscript. Ten vykresluje obsah souboru Postscript zobrazeného v tomto okně.^[8]

Zdroje jsou normálně zničeny, když klient, který je vytvořil, ukončí spojení se serverem. Nicméně, před ukončením spojení může klient požádat server o jeho zachování.

Události jsou pakety, které posílá server klientovi v případě, že ho může zajímat nějaká akce. Události jsou například posílány v případě stisku klávesy nebo tlačítka myši. Nejsou ovšem používány pouze pro vstup: například se může jednat také o oznámení, že je vytvořeno nové podokno rodičovského okna.

Každá událost je relativní k oknu. Pokud například uživatel klikne a jeho kurzor se nachází v okně, tak bude událost relativní k danému oknu. Paket události vždy obsahuje identifikátor okna.

Klient může požádat server, aby poslal událost jinému klientovi. Tento styl komunikace se používá u klientů při posílání událostí. Taková událost je generována například v případě, když klient požádá o momentálně vybraný text. Takováto událost je poslána klientovi, který právě obsluhuje okno udržující výběr.

Expose událost je poslána, když se zviditelní zničený obsah v prostoru okna. Obsah okna může být zničen jen za určitých podmínek. Například pokud je okno otevřené a není udržováno serverem. Server generuje Expose událost k oznámení klientovi, že byla vykreslena část okna.

Většina druhů událostí je posílána, pokud o ně klient předtím projeví zájem. To proto, že klienti mohou mít zájem pouze o určitý druh událostí. Například může mít klient zájem o události týkající se stisku kláves, ale události týkající se myši ho vůbec nezajímají. Existují ale také určité druhy událostí, které jsou klientům zasílány i v případě, že o ně klienti neprojevili zájem.

Klienti specifikují, jaké druhy událostí chtějí zasílat pomocí nastavovacího atributu okna. Například, aby se překreslilo okno, když byl zničen jeho obsah, tak klient musí obdržet Expose událost, která informuje o tom, že okno má být znovu překresleno. Ačkoliv bude klientovi odeslána Expose událost pouze, pokud nejprve projeví zájem o tento druh událostí. To se provede vhodným nastavením masky atributu okna.

Různí klienti mohou požadovat události od stejného okna. Mohou dokonce nastavit rozdílné masky ve stejném okně. Například jeden klient může u okna požadovat pouze události týkající se stisku kláves a jiný klient může požadovat jen události týkající se myši ve stejném okně. Toto je možné díky tomu, že server udržuje a odděluje masky jednotlivých oken pro jednotlivé klienty. Ačkoliv existují také druhy událostí, které mohou být odebírány pouze jedním klientem po určitý čas.

Program xev umožňuje vypisovat události, které se vztahují k danému oknu. Zejména, xev -id WID požaduje všechny možné události vztahující se k oknu s identifikátorem WID a vypíše je.

Zde je možný příklad interakce mezi serverem a programem, který vytvoří okno s černou oblastí, které se při stisku tlačítka ukončí. V tomto případě server nepošle žádnou odpověď, protože klient požaduje, aby se negenerovaly odpovědi. Tyto požadavky mohou vygenerovat chybu.

1. Klient otevře spojení se serverem a pošle počáteční paket specifikující pořadí bytů, které používá.
2. Server přijme spojení (v tomto případě bez autorizace), zasláním patřičného paketu, který obsahuje další informace jako třeba identifikátor kořenového okna (např. 0x0000002b) a které identifikátory může klient vytvořit.
3. Klient požádá o vytvoření výchozího grafického kontextu s identifikátorem 0x00200000 (tento požadavek, jako ostatní požadavky v tomto případě, negenerují odpovědi ze serveru).
4. Klient požádá server, aby vytvořil okno na nejvyšší úrovni s identifikátorem 0x00200001, velikostí 200x200, pozicí (10,10), atd.
5. Klient požaduje změnu v atributech okna 0x00200001 se specifikací, že má zájem o přijmutí událostí Expose a KeyPress.
6. Klient požádá okno 0x00200001, aby bylo namapováno (zobrazeno na obrazovce).
7. Když je okno zviditelněno a jeho obsah musí být vykreslen, pošle server klientovi událost Expose.
8. V reakci na tuto událost, klient požádá oblast o vykreslení posláním požadavku PolyFillRectangle s oknem 0x00200001 a grafickým kontextem 0X00200000.

Pokud je okno překryto jiným oknem a znovu odkryto za předpokladu, že záložní uložení není spravováno:

1. Server pošle další událost Expose, která říká klientovi, že okno má být znovu vykresleno.
2. Klient překreslí okno posláním požadavku PolyFillRectangle.

Pokud je klávesa stisknuta:

1. Server posílá klientovi událost KeyPress, aby oznámil, že uživatel stiskl klávesu.
2. Klient reaguje adekvátně (v tomto případě ukončím).

Na úrovni protokolu je barva reprezentována 32bitovým celým číslem bez znaménka tzv. hodnotou pixelu (anglicky pixelvalue). Tyto prvky ovlivňují zobrazování barev:

1. Barevná hloubka
2. Mapa barev, což je tabulka obsahující červenou, zelenou a modrou barvu a jejich intenzitu
3. Názorný vzor, který určuje, jak je tabulka použita při zobrazování barev

V nejjednodušším případě, je mapa barev tabulka obsahující RGB trojici na každém řádku. Hodnota pixelu x představuje barvu obsaženou v x-tém řádku tabulky. Jestliže klient změní záznamy na mapě barev, tak je toto zobrazení označováno jako vizuální třída PseudoColor. Vizuální třída StaticColor je podobná, ale klient nemůže měnit záznamy na mapě barev.

Nachází se zde celkem 6 možných vizuálních tříd, každá z nich označuje rozdílnou cestu pro znázornění RGB trojice s hodnotou pixelu. Dvě třídy jsou PseudoColor a StaticColor. Další dvě jsou GrayScale a StaticGray, které se liší pouze v zobrazování odstínů šedi.

Zbývající 2 virtuální třídy se liší od ostatních tříd, protože rozkládají hodnoty pixelů na 3 části a používají 3 vzájemně oddělené tabulky pro červenou, zelenou a modrou intenzitu. Podle této reprezentace barev je hodnota pixelu převedena na RGB trojici takto:

1. Hodnota pixelu je sekvence bitů.
2. Tato sekvence je rozdělena na 3 části.
3. Každá z těchto 3 částí je brána jako celé číslo a použito jako index k nalezení hodnoty v každé ze 3 oddělených tabulek.

Tento mechanismus vyžaduje mapu barev, která se skládá ze tří samostatných tabulek, jedné tabulky pro každou primární barvu. Výsledkem konverze je stále trojnásobek hodnoty intenzity. Tuto reprezentaci používají třídy DirectColor a TrueColor, které se liší v tom, zda může klient měnit mapu barev nebo ne.

Všech těchto 6 mechanizmů pro reprezentaci barev s hodnotou pixelu potřebuje některé další parametry k práci. Tyto parametry jsou shromážděny ve vizuálním typu, který obsahuje vizuální třídy a ostatní parametry pro reprezentaci barev. Každý server má pevnou sadu vizuálních typů, kde každý z nich je spojen s číselným identifikátorem. Tyto identifikátory jsou 32bitová celá čísla bez znaménka, ale nejsou nezbytně odlišná od identifikátorů zdrojů nebo atomů.

Když klient potvrdí spojení, přijme paket odeslaný serverem obsahující sekvenci bloků, kde každý obsahuje informaci o jedné obrazovce. Pro každou obrazovku obsahuje relativní blok seznam ostatních bloků. Každý z nich souvisí s určitou barevnou hloubkou, která je podporována obrazovkou. Pro každou podporovanou hloubku tento seznam obsahuje seznam vizuálních typů. V důsledku toho je každá obrazovka spojena řadou možných hloubek a každá hloubka každé obrazovky je spojena řadou možných vizuálních typů. Daný vizuální typ může být použit pro více obrazovek a pro různé hloubky.

Přijatý paket pro každý vizuální typ obsahuje jak jeho identifikátor, tak i aktuální parametry, které obsahuje (vizuální třídy, atd.). Klient ukládá tyto informace, protože o ně nemůže znovu požádat. Kromě toho klient nemůže měnit nebo vytvářet nové vizuální typy. Žádost o vytvoření nového okna obsahuje hloubku a identifikátor vizuálního typu k použití pro reprezentaci barev v tomto okně.

Mapy barev jsou používány bez ohledu na to, zda hardwarové ovládání obrazovky (např. grafická karta) používá paletu, což je tabulka, která se také používá pro reprezentaci barev. Servery používají mapy barev, i když hardware nevyužívá paletu. Kdykoli hardware použije paletu, jen omezený počet map barev může být nainstalován. Mapa barev je zejména instalována, pokud hardware zobrazuje barvy jí příslušející. Klient může požádat server o instalaci mapy barev. Nicméně to může požadovat odinstalování jiné mapy barev. Okna používající odinstalovanou mapu barev nejsou zobrazena se správnou barvou, je to efekt color flashing nebo technicolor. Tento problém může být vyřešen pomocí standardní mapy barev, což jsou mapy s předvídatelným vztahem mezi hodnotou pixelu a barvami. Díky této vlastnosti mohou být tyto mapy použity v různých aplikacích.

Vytvoření mapy barev se řídí podle konvence ICCCM. Standardní mapy barev jsou řízeny podle ICCCM a specifikací Xlib.

Část barevného systému X je X Color Management Systém (xcms). Tento systém byl předveden s X11R6 Release 5 v roce 1991. Tento systém se skládá z několika dalších funkcí v xlib, které naleznete v řadě funkcí Xcms*. Tento systém definuje barevná schémata nezávislá na zařízení, která mohou být převedena na RGB systémy závislé na zařízení. Systém se skládá z xlib Xcms* funkcí a stejně tak z X Device Color Characterization Convention (XSCCC), které popisuje jak převést různé barevné systémy nezávislé na zařízení na RGB systémy závislé na zařízení. Tento systém podporuje CIEXYZ, xyY, CIELUV a CIELAB a stejně tak TekHVC barevné systémy. [1], [2]

Atomy jsou 32bitová celá čísla, která jsou reprezentovaná řetězci. Protokol navrhuje atomy, protože reprezentují řetězce v krátké a pevné velikosti:^[9] zatímco řetězec může pokrýt datový typ long, atom je vždy 32bitové celé číslo. Stručnost atomu byla využita nařízením používat je v paketech, které jsou většinou posílány vícekrát se stejným řetězcem. Vedlo to v efektivnější použití sítě. Pevná délka atomů byla využívána díky pevné délce pro události.

Přesněji řečeno, atomy jsou identifikátory řetězců uložených na serveru. Jsou podobné identifikátorům zdrojů (Windows, Pixmaps a tak dále), ale mají dva zásadní rozdíly. Prvním rozdílem je to, že identifikátory atomů jsou vybírány serverem, ne klientem. Jinými slovy, když klient požaduje vytvoření nového atomu, tak pouze zašle řetězec (bez identifikátoru), který má být uložen. Identifikátor vybere server a pošle ho klientovi zpět jako odpověď. Druhý důležitý rozdíl mezi zdroji a atomy je, že atomy nejsou asociovány s klienty. Atom po vytvoření přežije, dokud server není ukončen nebo restartován (toto není běžné chování zdrojů).

Atomy jsou identifikátory a jsou tudíž unikátní. Ačkoliv atom s identifikátorem zdroje může kolidovat. Řetězec, který je asociován s atomem se nazývá jméno atomu. Jméno atomu nelze měnit po jeho vytvoření a žádné dva atomy nesmí mít stejné jméno. Výsledkem je, že jméno atomu je obecně používáno k jeho identifikaci. Například spojením „atom ABCD“ je přesněji myšleno „atom, jehož asociační klíč je ABCD“ nebo „atom, jehož jméno je ABCD“. Klient může požádat o vytvoření nového atomu a může požádat o atom (identifikátor) daného řetězce. Některé atomy jsou předdefinované, jsou vytvořeny serverem s daným identifikátorem a řetězcem. Atomy jsou používány k mnoha účelům. Především souvisí s komunikací mezi klienty, kteří jsou připojeny na tentýž server. Zejména jsou používány v asociaci s vlastnostmi oken.

Seznam všech atomů uložených na serveru může být vypsán pomocí programu xlsatoms. Zejména tento program vypisuje každý atom (identifikátor, který je číslo) s jeho jménem (jeho asociační řetězec).

Každé okno má předdefinovanou sadu atributů, který je uložena na serveru a je přístupná klientům pomocí určitých dotazů. Atributy jsou data o oknech, jako velikost, pozice, barva pozadí apod. Vlastnosti jsou jakékoliv kusy dat spojené s okny. Atributy společně s vlastnostmi nemají žádný význam na úrovni X Windows core protokolu. Klient také může ukládat libovolná data jako vlastnosti okna.

Vlastnost je definována jménem, typem a hodnotou. Zároveň jsou podobné proměnným v imperativních programovacích jazycích, kde klient proměnné přiřadí typ, pojmenuje ji a ohodnotí (stejně jako vlastnost v našem případě). Následně se tyto vlastnosti přiřadí k oknům. Může se stát, že existují dvě vlastnosti se stejným jménem ve dvou různých oknech a uchovávat různé typy.

Jméno, typ a hodnota vlastnosti jsou řetězce. Přesněji to jsou atomy, které jsou jako řetězce uloženy na serveru, k nimž přistupujeme za pomocí identifikátoru. Klient, který je autorizován, přistupuje k vlastnostem právě použitím zmíněného identifikátoru atomu, který obsahuje jméno vlastnosti.

Vlastnosti jsou používány zejména ke komunikaci mezi klienty. Například, vlastnost pojmenovaná WM_NAME (vlastnost pojmenovaná atomem, kterému je přiřazen řetězec WM_NAME) se používá pro uložení jména okna. Správce oken si obvykle tuto vlastnost přečte a její hodnotu přiřadí titulku okna.

Některé typy komunikace mezi klienty používají vlastnosti hlavního okna. Například podle specifikací Freedesktop window manager^[10] by měl správce oken ukládat identifikátory aktivních oken do vlastnosti hlavního okna pojmenované _NET_ACTIVE_WINDOW. X resources uchovávají parametry programu a jsou uloženy ve vlastnostech hlavního okna. Touto cestou k nim mohou přistupovat všichni klienti, i když běží na různých počítačích.

xprop program tiskne vlastnosti vybraných oken.

xprop -root tiskne jméno, typ a hodnotu každé vlastnosti hlavního okna

V prostředí X Window System má každá fyzická klávesa přiřazené číslo v rozsahu 8-255. Toto číslo nazýváme kód klávesy. Ten identifikuje pouze klávesu, ne znak nebo výraz (např. Page Up), který může být natištěný na klávese. Každý z těchto znaků nebo výrazů je místo toho identifikován podle keysym. Zatímco kód klávesy záleží pouze na aktuální stisknuté klávese, keysym může záviset, například na stisku nebo nestisknu klávesy Shift nebo jiného modifikátoru.

V případě stisknutí nebo uvolnění klávesy odesílá server událost KeyPress (klávesa stisknuta) nebo KeyRelease (klávesa uvolněna) patřičnému klientu. Tyto události obsahují:

1. kód klávesy stisknuté klávesy
2. aktuální stav modifikátorů (Shift, CTRL, atd.)

Server tedy posílá kód klávesy a stav modifikátoru, aniž by se snažil je přeložit na konkrétní znak. Převod má na starosti klient. Například klient obdržel událost informující o stisknutí určité klávesy, zatímco klávesa Shift byla stisknuta. Pokud by za normálních okolností tato klávesa vygenerovala „a“, klient vyhodnotí událost na „A“.

Zatímco překlad kódu kláves do keysyms probíhá na straně klienta, tak tabulka, která uchovává jejich vztahy, je spravována serverem. Ukládání této tabulky je na centralizovaném místě, které je přístupné pro všechny klienty. Běžní klienti se dotazují na toto mapování a používají ho pro dekódování událostí modifikátorů a kódů kláves na keysym. Zároveň klient je schopen měnit mapování dle potřeb.

Modifikátor je klávesa, která když je stisknuta, změní interpretaci ostatních kláves. Modifikátorem je například klávesa [Shift]. Když klávesa „a“ normálně vypíše malé písmeno „a“, tak spolu se Shift vypíše velké písmeno „A“. Mezi další běžné modifikátory patří: Ctrl, Alt, Meta.

X server pracuje nejvýše s 8 modifikátory, ale každý z modifikátorů může být přiřazen k více klávesám. Je to tak, protože hodně klávesnic má některé modifikátory zdvojené. Například klávesnice, které mají dvě „Shift“ klávesy (jednu na vlevo a druhou na vpravo). Tyto dvě klávesy vysílají sice odlišné kódy kláves (když jsou stisknuty), ale X server je obě překládá jako „Shift modifikátor“.

Pro každý z osmi modifikátorů udržuje server X seznam klávesových kódů, který odpovídá danému modifikátoru. Jako příklad, pokud seznam prvního modifikátoru (modifikátor „Shift“) obsahuje kód klávesy 0x37, pak klávesa která vysílá kód 0x37 je X Serverem považována za klávesu Shift.

Seznam namapovaných modifikátoru je udržován X serverem, ale může být změněn kterýmkoliv klientem. Například klient může požádat klávesu F1, aby byla přidána na seznam Shift modifikátorů. Od té chvíle, se tato klávesa chová jako další Shift modifikátor. Nicméně klávesový kód stále odpovídá „klávese F1“. Ve výsledku se klávesa F1 chová stejně jako předtím (například po stisknutí vyvolá nápovědu), ale také se chová jako klávesa shift (stisknutím „a“ v textovém editoru společně s klávesou F1 zobrazí „A“).

X server udržuje a používá mapování modifikátoru také pro tlačítka myši. Nicméně tlačítka mohou být pouze zaměňována. To nejvíce využijí leváci pro výměnu levého a pravého tlačítka.

xmodmap program ukazuje změny mapování kláves, modifikátoru a tlačítek na myši.

„Grab“ je stav, kdy jsou všechny události klávesnice nebo myši zaslány klientovi. Klient se může dotázat na grab klávesnice, myši nebo obojího. Pokud server na dotaz odpoví, všechny události klávesnice/myši jsou zaslány „grabbing“ klientovi dokud grab není uvolněn. Další klienti nemohou přijímat tyto události.

Když je dotazován grab, tak klient upřesňuje „grab okno“ a všechny události jsou poslány do grabbing klienta, tak jako by měly přímou souvislost s grab oknem. V takovém stavu další klienti nedostávají události i když je mají vybrány v grab okně.

Existují dva druhy grabs:

aktivní

grab se vykoná okamžitě

pasivní

grab se vykoná pouze, když je předtím stisknuta klávesa nebo tlačítko myši, a ruší se když až se uvolní

Klient může nad klávesnicí zřídit grab, ukazatel nebo obojí. Dotaz na grabbing může zahrnovat požadavek na zamrznutí klávesy nebo ukazatele. Rozdíl mezi grabbing a zamrzáním je ten, že grabbing mění příjemce události. Během zamrznutí se zastaví dodání úplně. Když je zařízení zamrznuté, tak generované události se ukládají do front,tak aby mohly být doručeny až zamrznutí pomine.

Další parametr ukazatelů událostí ovlivní dodávku události a maska události specifikuje doručování a rušení typů či událostí.

Požadavek na grabbing zahrnuje pole pro upřesnění, co se stane, když by událost byla poslána grabbing klientovi, i když ještě nebyl zřízen grab. Konkrétně klient může požadovat jejich odeslání, jako obvykle nebo v závislosti na grab. Tyto dvě podmínky nejsou stejné, jak by se mohlo zdát. Například klient, který by za normálních okolností obdržel události z klávesnice na prvním okně, může požádat klávesnici, aby by byla zachycena druhým oknem. Událost, která je obvykle poslána do prvního okna může nebo nemusí být přesměrována do grab okna, v závislosti na parametru v grab požadavku.

Klient také může požádat grab celého serveru. V tomto případě nebude serverem zpracován žádný požadavek s výjimkou těch, které přijdou od grabbing klienta.

V core protokolu existují také další požadavky a události. První druh požadavků je relativní k rodičovskému vztahu mezi okny. Klient může požádat o změnu rodičovského okna nebo může požadovat informace o rodičovství oken. Další požadavky jsou relativní k výběru, který je ovšem řízen jinými protokoly. Další požadavky se týkají například tvaru kurzoru. Klient může také požádat vlastníka zdroje (window, pixmap a tak dále), aby ho zničil.

X Window core protokol byl navržen tak, aby do něj bylo možné přidávat rozšíření. Stanovuje mechanismus, díky kterému je možné se dotazovat na dostupná rozšíření a jaké obsahuje rozšířené požadavky, události a chyby.

Klient může požadovat seznam všech dostupných rozšíření. Pakety rozšíření jsou podobné paketům, které obsahuje samotný core protokol. Core protokol stanovuje jaké požadavky, události a chyby obsahují celé číslo označující jeho typ (například požadavek pro vytvoření nového okna je očíslován číslem 1). Rozsah těchto celých čísel je rezervován pro rozšíření.

Když se klient pokouší navázat spojení se serverem, tak server buď spojení přijme, odmítne nebo požádá o autentizaci. Autentizační požadavek obsahuje jméno autentizační metody, která má být použita. Core protokol nespecifikuje autentizační proces, který závisí na typu použité autentizace jinak, než že server odešle paket oznamující schválení, nebo zamítnutí připojení.

Během pravidelných interakcí mezi klientem a serverem, jediné požadavky související s autorizací jsou ohledně host-based access metody. Obzvlášť, klient může požádat, aby tato metoda byla dostupná, a může požádat o čtení a změny v seznamu hostů (klientů), kteří jsou oprávněni ke spojení. Typické aplikace tyto požadavky nepoužívají, jsou používány xhost programy, aby dali uživateli nebo skriptu přístup k seznamu přístupů hostů. Metoda host-based access je považována za nebezpečnou.

Hlavní článek: Xlib

Většina klientských programů komunikuje se serverem pomocí klientské knihovny Xlib. Většina klientů používá knihovny jako Xaw, Motif, GTK+ nebo Qt, které zase využívají Xlib pro interakci se serverem. Využití Xlib má následující efekty:

1. Xlib implementuje synchronního klienta ohledně zpracování odpovědí a událostí:
   1. Funkce Xlib zasílají blok dotazů, dokud nezískají (pokud se očekávají) vhodné odpovědi; jinými slovy, může X Window klient, nevyužívající Xlib, posílat dotazy serveru a potom provádět jiné operace, zatímco čeká na odpověď, ale klient s Xlib může pouze volat funkci, která posílá dotazy, a následně čekat na odpověď, tudíž blokuje klienta dokud čeká na odpověď (pokavaď klient před voláním funkce nespustí nové vlákno);
   2. Během zasílání událostí asynchronně serverem si Xlib klienta ukládá přijaté události do fronty; klientský program k nim může přistoupit pouze voláním funkcí knihovny X11; jinými slovy, klient je nucen se zablokovat nebo aktivně čekat, jestliže očekává událost.
2. Xlib neposílá požadavky serveru okamžitě, ale ukládá je do fronty nazývané výstupní buffer; žádosti v bufferu jsou odeslány teprve, když:
   1. když si to program přímo zažádá voláním knihovní funkce jako XFlush;
   2. program zavolá funkci, která jako výsledek vrací něco, co obsahuje odpověď od serveru, jako XGetWindowAttributes;
   3. program požádá o událost ve frontě (například voláním XNextEvent) a bloky volání (například bloky XNextEvent, jestliže je fronta prázdná).

Knihovny vysoké úrovně, jako Xt (kterou zase využívá Xaw a Motif), umožňují klientskému programu určit callback funkce související s některými událostmi; knihovna se stará o dotazování fronty událostí a volání správné funkce, když je zapotřebí; některé události, jako ty, které indikují potřebu překreslení okna, jsou provedeny vnitřně pomocí Xt.

Knihovny nižší úrovně, jako XCB, poskytují asynchronní přístup k protokolu, umožňující lepší latence.

X Window System core protokol neřídí komunikaci mezi klienty a nespecifikuje, jak mají být použita okna k vytvoření visuálních elementů, které jsou běžné v grafických uživatelských rozhraních (tlačítka, menu, atd.) Elementy grafického uživatelského prostředí jsou definovány klientskými knihovnami tvořícími widget toolkity. Komunikace mezi klienty je stanovena jinými standardy, jako je ICCCM a freedesktop specifikace.^[10]

Komunikace mezi klienty je relevantní pro výběry, cut buffery a drag-and-drop, které jsou metodami používanými uživatelem k přenosu dat mezi okny. Protože jsou okna ovládána různými programy, je zapotřebí protokol na výměnu dat. Do meziklientské komunikace také spadají správci oken, což jsou programy, které ovládají vzhled oken a celkový dojem z grafického uživatelského rozhraní. Další záležitost, kde se meziklientská komunikace do určité míry projeví je správa relací.

Vznik těchto relací je také záležitost, kterou protokol nepopisuje. Obvykle se tím zabývá X display manager. Uživatel ovšem také může relaci začít manuálně pomocí programů xinit a startx.

V tomto článku byl použit překlad textu z článku X Window System core protocol na anglické Wikipedii.

• Protokoly a architektura pro X Window System
• Xlib

• X.Org Foundation (oficiální stránka) - Mirror s doménovým jménem 'freedesktop.org'.
• X Window System Internals
• Stránky Kentona Leeho o X Window and Motif Archivováno 20. 5. 2013 na Wayback Machine.
• X Window System Protocol, Version 11, Release 6.8