X Window System-Protokolle und -Architektur

In der Informatik ist das X Window System (üblicherweise X11 oder X) ein netzwerktransparentes Fenstersystem für Bitmap- Displays. Dieser Artikel beschreibt die Protokolle und die technische Struktur von X11.

X verwendet ein Client-Server-Modell . Ein X-Server- Programm läuft auf einem Computer mit grafischer Anzeige und kommuniziert mit verschiedenen Client-Programmen . Der X-Server fungiert als Vermittler zwischen Benutzer und Client-Programmen. Er empfängt Anfragen der Client-Programme für grafische Ausgaben (Fenster) über TCP-Port 6000 plus die Anzeigenummer ^{[ 1 ]} und zeigt diese dem Benutzer an (Anzeige). Außerdem empfängt er Benutzereingaben (Tastatur, Maus) und leitet diese an die Client-Programme weiter.

In X läuft der Server auf dem Rechner des Benutzers, während die Clients auf entfernten Rechnern ausgeführt werden können. Diese Terminologie kehrt das gängige Konzept von Client-Server-Systemen um, bei denen der Client normalerweise auf dem lokalen Rechner des Benutzers und der Server auf dem entfernten Rechner läuft. Die X-Terminologie geht davon aus, dass das X-Programm im Zentrum aller Aktivitäten steht, d. h. es nimmt Anfragen von Anwendungen sowie Maus- und Tastatureingaben des Benutzers entgegen und beantwortet diese. Daher werden Anwendungen (auf entfernten Rechnern) als Clients des X-Serverprogramms betrachtet.

Das Kommunikationsprotokoll zwischen Server und Client arbeitet netzwerktransparent : Client und Server können auf demselben oder auf verschiedenen Rechnern laufen, möglicherweise mit unterschiedlichen Architekturen und Betriebssystemen . Client und Server können sicher über das Internet kommunizieren , indem sie die Verbindung über einen verschlüsselten Tunnel aufbauen . ^{[ 2 ]}

Bob Scheifler und Jim Gettys legten die frühen Prinzipien von X wie folgt dar (aufgeführt in Scheifler/Gettys 1996):

• Fügen Sie keine neuen Funktionen hinzu, es sei denn, ein Implementierer kann ohne diese keine reale Anwendung fertigstellen.
• Es ist genauso wichtig zu entscheiden, was ein System nicht ist, wie zu entscheiden, was es ist. Es sollte nicht alle Bedürfnisse der Welt befriedigen, sondern so erweiterbar sein, dass zusätzliche Bedürfnisse auf eine Weise erfüllt werden können, die mit zukünftigen Entwicklungen kompatibel ist.
• Das Einzige, was noch schlimmer ist, als von einem einzigen Beispiel zu verallgemeinern, ist, überhaupt keine Beispiele zu haben.
• Wenn ein Problem nicht vollständig verstanden wird, ist es wahrscheinlich am besten, gar keine Lösung anzubieten.
• Wenn Sie mit nur 10 Prozent des Aufwands 90 Prozent des gewünschten Effekts erzielen können, wählen Sie die einfachere Lösung. (Siehe auch: Schlechter ist besser .)
• Komplexität so weit wie möglich isolieren.
• Bieten Sie Mechanismen statt Richtlinien. Insbesondere sollten Sie die Gestaltung der Benutzeroberfläche in die Hände der Kunden legen.

Der erste Grundsatz wurde während der Entwicklung von X11 dahingehend geändert, dass neue Funktionen nur dann hinzugefügt werden sollten, wenn eine reale Anwendung bekannt ist, die diese benötigt.

X hat sich seither weitgehend an diese Prinzipien gehalten. Die X.Org Foundation entwickelt die Referenzimplementierung mit dem Ziel, diese zu erweitern und zu verbessern, wobei die Kompatibilität mit dem ursprünglichen Protokoll von 1987 nahezu vollständig gewahrt bleibt.

Die Kommunikation zwischen Server und Clients erfolgt durch den Austausch von Datenpaketen über einen Netzwerkkanal . Der Client stellt die Verbindung her, indem er das erste Paket sendet. Der Server antwortet mit einem Paket, das die Annahme oder Ablehnung der Verbindung signalisiert oder eine weitere Authentifizierung anfordert. Wird die Verbindung angenommen, enthält das Bestätigungspaket Daten, die der Client für die nachfolgende Interaktion mit dem Server benötigt.

Nachdem die Verbindung hergestellt wurde, tauschen Client und Server über den Kanal vier verschiedene Arten von Paketen aus:

1. Anfrage: Der Client fordert Informationen vom Server an oder bittet ihn, eine bestimmte Aktion auszuführen.
2. Antwort: Der Server antwortet auf eine Anfrage. Nicht alle Anfragen generieren eine Antwort.
3. Ereignis: Der Server sendet ein Ereignis an den Client, z. B. eine Tastatur- oder Mauseingabe oder das Verschieben, Vergrößern oder Anzeigen eines Fensters.
4. Fehler: Der Server sendet ein Fehlerpaket, wenn eine Anfrage ungültig ist. Da Anfragen in einer Warteschlange gespeichert werden, werden die von einer Anfrage generierten Fehlerpakete möglicherweise nicht sofort gesendet.

Der X-Server stellt eine Reihe grundlegender Dienste bereit. Die Clientprogramme realisieren komplexere Funktionalitäten durch Interaktion mit dem Server.

Was in anderen grafischen Benutzeroberflächen üblicherweise als Fenster bezeichnet wird , ist im X Window System ein Fenster der obersten Ebene . Der Begriff „ Fenster“ wird auch für Fenster verwendet, die in einem anderen Fenster enthalten sind, also für die Unterfenster eines übergeordneten Fensters . Grafische Elemente wie Schaltflächen, Menüs, Symbole usw. werden alle mithilfe von Fenstern realisiert.

Ein Fenster kann nur als Unterfenster eines übergeordneten Fensters erstellt werden. Dadurch werden die Fenster hierarchisch in einer Baumstruktur angeordnet . Der X-Server erstellt automatisch die Wurzel des Baums, das sogenannte Wurzelfenster . Die Fenster der obersten Ebene sind die direkten Unterfenster des Wurzelfensters. Sichtbar ist das Wurzelfenster so groß wie der Bildschirm und liegt hinter allen anderen Fenstern.

Der X-Server speichert alle Daten über Fenster, Schriftarten usw. Der Client kennt die Kennungen dieser Objekte – ganze Zahlen, die er als Namen für sie bei der Interaktion mit dem Server verwenden kann. Möchte ein Client beispielsweise ein Fenster erstellen, fordert er den Server dazu auf und erhält (im Erfolgsfall) eine Kennung zurück, die der Server dem neu erstellten Fenster zugeordnet hat. Mithilfe dieser Kennung kann der Client später beispielsweise einen im Fenster anzuzeigenden Text anfordern.

Serverspezifische Kennungen sind nicht nur clientseitig, sondern auch serverseitig eindeutig. Beispielsweise haben keine zwei Fenster dieselbe Kennung, selbst wenn sie von zwei verschiedenen Clients erstellt wurden. Ein Client kann auf jedes Objekt anhand seiner Kennung zugreifen, selbst wenn ein anderer Client das Objekt erstellt hat.

Jedes Fenster verfügt über vordefinierte Attribute und Eigenschaften, die auf dem X-Server gespeichert und über entsprechende Anfragen von Clients abgerufen werden können. Attribute sind Daten über das Fenster, wie Größe, Position, Hintergrundfarbe usw. Eigenschaften sind Daten, die einem Fenster zugeordnet sind. Im Gegensatz zu Attributen haben Eigenschaften auf der Ebene des X-Kernprotokolls keine Bedeutung. Ein Client kann beliebige Daten in einer Fenstereigenschaft speichern.

Eine Eigenschaft zeichnet sich durch einen Namen, einen Typ und einen Wert aus. Eigenschaften ähneln Variablen in imperativen Programmiersprachen , da die Anwendung eine neue Eigenschaft mit einem bestimmten Namen und Typ erstellen und ihr einen Wert zuweisen kann. Eigenschaften sind Fenstern zugeordnet: Zwei Eigenschaften mit demselben Namen können in zwei verschiedenen Fenstern existieren, aber unterschiedliche Typen und Werte haben.

Eigenschaften werden hauptsächlich für die Kommunikation zwischen Clients verwendet. Beispielsweise WM_NAMEspeichert die Eigenschaft „Name“ den Namen des Fensters; Fenstermanager lesen diese Eigenschaft üblicherweise aus und zeigen den Fensternamen oben im Fenster an.

Das xpropProgramm kann die Eigenschaften eines Fensters anzeigen. Insbesondere xprop -rootwerden die Eigenschaften des Stammfensters angezeigt, einschließlich der X-Ressourcen (Programmparameter).

Ereignisse sind Datenpakete, die vom Server an den Client gesendet werden, um ihn über ein für ihn relevantes Ereignis zu informieren. Ein Client kann den Server anweisen, ein Ereignis an einen anderen Client zu senden; dies dient der Kommunikation zwischen Clients. Fordert ein Client beispielsweise den aktuell markierten Text an, wird ein Ereignis an den Client gesendet, der das Fenster mit der Markierung gerade verarbeitet.

Der Inhalt eines Fensters kann unter bestimmten Bedingungen „zerstört“ werden (z. B. wenn das Fenster abgedeckt ist). Sobald ein Bereich mit zerstörtem Inhalt sichtbar wird, generiert der Server ein ExposeEreignis, um den Client darüber zu informieren, dass ein Teil des Fensters neu gezeichnet werden muss.

Andere Ereignisse können dazu dienen, Clients über Tastatur- oder Mauseingaben, die Erstellung neuer Fenster usw. zu informieren.

Bestimmte Ereignisarten werden immer an einen Client gesendet, die meisten jedoch nur dann, wenn der Client zuvor sein Interesse daran bekundet hat. Dies liegt daran, dass Clients möglicherweise nur an bestimmten Ereignisarten interessiert sind. Beispielsweise kann ein Client an Tastaturereignissen, nicht aber an Mausereignissen interessiert sein.

Die Farbdarstellung des X Window Systems kann Benutzer mitunter verwirren, und in der Vergangenheit wurden verschiedene Modi unterstützt. Die meisten modernen Anwendungen nutzen Vollfarbe (24-Bit-Farbtiefe, 8 Bit für Rot, Grün und Blau), ältere oder spezielle Anwendungen benötigen jedoch unter Umständen einen anderen Farbmodus. Viele kommerzielle Spezialanwendungen verwenden PseudoColor .

Das X11-Protokoll verwendet für die meisten Grafikoperationen einen einzelnen Farbwert, den sogenannten Pixelwert , als 32-Bit-Ganzzahl ohne Vorzeichen. Bei der Übertragung der Intensität von Primärfarben wird für jede Farbkomponente eine 16-Bit-Ganzzahl verwendet. Es gibt verschiedene Farbdarstellungen; nicht alle werden von jedem Gerät unterstützt.

• DirectColor: Ein Pixelwert wird in separate Rot-, Grün- und Blau-Teilfelder zerlegt. Jedes Teilfeld indiziert eine separate Farbtabelle. Einträge in allen Farbtabellen können geändert werden.
  • TrueColor: Funktioniert wie DirectColor, nur dass die Farbtabelleneinträge von der Hardware vordefiniert sind und nicht geändert werden können. Typischerweise bietet jede der Rot-, Grün- und Blau-Farbtabellen einen (nahezu) linearen Intensitätsverlauf.
• Graustufen: Ein Pixelwert indiziert eine einzelne Farbtabelle, die monochrome Intensitäten enthält. Die Einträge der Farbtabelle können geändert werden.
  • StaticGray: Dasselbe wie GrayScale, nur dass die Einträge der Farbtabelle von der Hardware vordefiniert sind und nicht geändert werden können.
• Pseudofarbe ( Chunky ): Ein Pixelwert indiziert eine einzelne Farbtabelle, die Farbintensitäten enthält. Einträge in der Farbtabelle können geändert werden.
  • StaticColor: Dasselbe wie PseudoColor, nur dass die Einträge der Farbtabelle von der Hardware vordefiniert sind und nicht geändert werden können.

Die meisten Clientprogramme kommunizieren über die Xlib -Clientbibliothek mit dem Server. Neben Xlib arbeitet die XCB -Bibliothek enger mit dem X-Protokoll. Insbesondere verwenden die meisten Clients Bibliotheken wie Xaw , Motif , GTK+ oder Qt, die wiederum Xlib für die Interaktion mit dem Server nutzen. Qt wechselte mit Version 5.0 von Xlib zu XCB , was Clientprogramme jedoch nahezu vollständig unberührt ließ.

Das X-Kernprotokoll stellt Mechanismen für die Kommunikation zwischen Clients bereit: Fenstereigenschaften und Ereignisse, insbesondere die Client-zu-Client-Nachrichtenereignisse. Es legt jedoch kein Protokoll für diese Interaktionen fest. Stattdessen regelt ein separater Satz von Konventionen für die Client-übergreifende Kommunikation diese Protokolle.

Das Handbuch zu den Inter-Client Communication Conventions (ICCC) spezifiziert das Protokoll für den Datenaustausch über Auswahlen und die Interaktion von Anwendungen mit dem Fenstermanager. Diese Spezifikation wurde von einigen als schwierig und verwirrend empfunden; ^{[ 3 ] [ 4 ]} die Konsistenz des Erscheinungsbilds und der Kommunikation von Anwendungen wird üblicherweise durch die Programmierung für eine bestimmte Desktop-Umgebung gewährleistet.

Das Inter-Client Exchange Protocol (ICE) definiert ein Framework für die Entwicklung von Protokollen zur Interaktion zwischen Clients, auf dem Programmierer spezifische Protokolle aufbauen können. Insbesondere das X Session Management Protocol (XSMP) basiert auf ICE und regelt die Interaktion zwischen Anwendungen und dem Session Manager . Dieser speichert den Status des Desktops nach Beendigung einer interaktiven Sitzung und stellt ihn beim Start einer neuen Sitzung mit demselben Benutzer wieder her.

Die Freedesktop- Spezifikationen beinhalten neuere Konventionen, darunter die Drag-and-Drop-Konvention Xdnd (die zum Übertragen von Daten durch Auswählen und Ziehen in ein anderes Fenster verwendet wird) und die Konvention für eingebettete Anwendungen Xembed (die detailliert beschreibt, wie eine Anwendung in einem Unterfenster einer anderen Anwendung ausgeführt werden kann).

Die Mechanismen für Auswahl, Ausschneidepuffer und Drag & Drop im X Window System ermöglichen es Benutzern, Daten zwischen Fenstern zu übertragen. Auswahl und Ausschneidepuffer werden (typischerweise) verwendet, wenn ein Benutzer Text oder andere Daten in einem Fenster auswählt und in ein anderes Fenster einfügt. Drag & Drop wird verwendet, wenn ein Benutzer etwas in einem Fenster auswählt, dann auf die Auswahl klickt und sie in ein anderes Fenster zieht.

Da zwei verschiedene Anwendungen die beiden Fenster verwalten können, erfordert die Datenübertragung die Interaktion verschiedener Clients, die mit demselben X-Server verbunden sind. Das X-Kernprotokoll beinhaltet zwar einige Anfrage- und Ereignistypen, die spezifisch für den Selektionsaustausch sind, die Übertragung selbst erfolgt jedoch hauptsächlich über die allgemeine Client-zu-Client-Ereignisübertragung und Fenstereigenschaften, die nicht spezifisch für die Selektionsübertragung sind.

Benutzer können Daten unterschiedlicher Art zwischen Clients übertragen: in der Regel handelt es sich um Text, es können aber auch Pixmaps, Zahlen, Listen von Objekten usw. sein.

Auswahlen und Drag & Drop sind aktive Mechanismen: Nachdem der Benutzer Daten in einem Fenster ausgewählt hat, muss der Client, der das Fenster verwaltet, aktiv ein Protokoll unterstützen, um diese Daten an die anfordernde Anwendung zu übertragen. Cut-Puffer hingegen bieten einen passiven Mechanismus: Wenn der Benutzer Text auswählt, wird dessen Inhalt in einen Cut-Puffer übertragen, wo er auch dann erhalten bleibt, wenn die Anwendung, die das Fenster verwaltet, beendet und das Fenster zerstört wird.

Ein Fenstermanager ist ein Programm, das das allgemeine Erscheinungsbild von Fenstern und anderen grafischen Elementen der grafischen Benutzeroberfläche steuert . Unterschiede im Aussehen des X Window Systems in verschiedenen Installationen resultieren hauptsächlich aus der Verwendung unterschiedlicher Fenstermanager oder aus unterschiedlichen Konfigurationen des Fenstermanagers.

Der Fenstermanager kümmert sich um die Festlegung der Position der Fenster, das Platzieren des dekorativen Rahmens um sie herum, die Verwaltung von Symbolen, die Behandlung von Mausklicks außerhalb der Fenster (im „Hintergrund“), die Behandlung bestimmter Tastatureingaben usw.

Aus Sicht des X-Servers verhält sich der Fenstermanager wie ein Client, genau wie jeder andere Client. Die Ausgangsposition und die dekorativen Rahmen um die Fenster werden vom Fenstermanager mithilfe der folgenden Anfragen gesteuert:

1. Eine Anwendung kann vom Server verlangen, dass er Anfragen zur Darstellung (Anzeige) von Unterfenstern eines bestimmten Fensters nicht erfüllt, sondern stattdessen ein Ereignis sendet;
2. Eine Anwendung kann anfordern, das übergeordnete Fenster zu ändern.

Der Fenstermanager nutzt die erste Anfrage, um alle Anfragen zur Zuordnung von Fenstern der obersten Ebene (Unterfenster des Stammfensters) abzufangen. Immer wenn eine andere Anwendung die Zuordnung eines Fensters der obersten Ebene anfordert, führt der Server diese Anfrage nicht aus, sondern sendet stattdessen ein Ereignis an den Fenstermanager. Die meisten Fenstermanager ordnen das Fenster neu zu: Sie erstellen ein größeres Fenster der obersten Ebene (das sogenannte Rahmenfenster) und ordnen das ursprüngliche Fenster diesem als Unterfenster zu. Grafisch entspricht dies dem Platzieren des ursprünglichen Fensters innerhalb des Rahmenfensters. Der vom ursprünglichen Fenster nicht belegte Platz des Rahmenfensters wird für den dekorativen Rahmen um das Fenster (den „Rahmen“ und die „Titelleiste“) verwendet.

Der Fenstermanager steuert Mausklicks im Fensterrahmen. Dadurch kann ein Benutzer beispielsweise das Fenster verschieben oder seine Größe ändern, indem er auf den Rahmen oder die Titelleiste klickt und zieht.

Der Fenstermanager verwaltet auch Symbole und verwandte visuelle Elemente der grafischen Benutzeroberfläche. Symbole existieren nicht auf der Ebene des X-Core-Protokolls. Sie werden vom Fenstermanager implementiert. Wenn beispielsweise ein Fenster als Symbol dargestellt werden soll, entfernt der FVWM- Fenstermanager die Zuordnung des Fensters und erstellt ein Fenster für den Symbolnamen und gegebenenfalls ein weiteres Fenster für das Symbolbild. Bedeutung und Handhabung von Symbolen werden daher vollständig vom Fenstermanager bestimmt: Einige Fenstermanager wie wm2 implementieren Symbole überhaupt nicht.

Grob gesagt entspricht der Sitzungsstatus dem Zustand des Desktops zu einem bestimmten Zeitpunkt: eine Gruppe von Fenstern mit ihrem aktuellen Inhalt. Genauer gesagt handelt es sich um die Anwendungen, die diese Fenster verwalten, sowie um die Informationen, die es diesen Anwendungen ermöglichen , den Zustand ihrer verwalteten Fenster bei Bedarf wiederherzustellen. Ein Programm namens X-Sitzungsmanager speichert und stellt den Sitzungsstatus wieder her.

Am bekanntesten ist wohl die Verwendung eines Sitzungsmanagers, der es einem Benutzer ermöglicht, sich von einer interaktiven Sitzung abzumelden und beim erneuten Anmelden genau dieselben Fenster im selben Zustand vorzufinden. Damit dies funktioniert, speichert der Sitzungsmanager die Namen der laufenden Anwendungen beim Abmelden und startet sie beim Anmelden neu. Damit auch der Zustand der Anwendungen wiederhergestellt wird (was für die Wiederherstellung des Fensterinhalts erforderlich ist), müssen die Anwendungen ihren Ausführungszustand auf Anfrage des Sitzungsmanagers speichern und beim erneuten Start wieder laden können.

Das X Window System enthält einen Standard-Sitzungsmanager namens X Window xsm. Entwickler haben weitere Sitzungsmanager für spezifische Desktop-Systeme geschrieben. Wichtige Beispiele sind X Window ksmserver, X Window xfce4-sessionund X Window gnome-sessionfür KDE , Xfce bzw. GNOME .

Das Programm X Display Manager zeigt die grafische Anmeldemaske im X Window System an. Allgemeiner gesagt, betreibt ein Display Manager einen oder mehrere X-Server auf dem lokalen Rechner oder nimmt Verbindungen von X-Servern auf entfernten Rechnern entgegen. Die lokalen Server werden vom Display Manager gestartet, der sich dann mit ihnen verbindet, um dem Benutzer den Anmeldebildschirm anzuzeigen. Die entfernten Server werden unabhängig vom Display Manager gestartet und verbinden sich mit diesem. In diesem Fall funktioniert der Display Manager wie ein grafischer Telnet- Server: Ein X-Server kann sich mit dem Display Manager verbinden, der eine Sitzung startet. Die Anwendungen, die diese Sitzung nutzen, laufen auf demselben Rechner wie der Display Manager, haben aber Ein- und Ausgabe auf dem Rechner, auf dem der X-Server läuft (dies kann der Rechner vor dem Benutzer oder ein entfernter Rechner sein).

Das X Window System wird standardmäßig mit XDM als Display-Manager ausgeliefert. Weitere Display-Manager sind GDM ( GNOME ), KDM / SDDM ( KDE ), WDM (unter Verwendung des in Window Maker verwendeten WINGs-Widget-Sets ) und Entrance (unter Verwendung der in Enlightenment v.17 verwendeten Architektur ).

Zu den frühen Widget-Toolkits für X gehörten Xaw (das Athena Widget Set, 1983), OLIT ( OPEN LOOK Intrinsics Toolkit, 1988), XView (1988), Motif (1980er Jahre) und Tk . OLIT und XView dienten als Basis-Toolkits für Suns ältere OpenWindows- Desktopumgebung.

Motif stellt das Basis-Toolkit für die Common Desktop Environment (CDE) bereit, die Desktop-Umgebung, die auf kommerziellen Unix- Systemen wie Solaris , AIX und HP-UX verwendet wird . (Solaris 10 enthält sowohl CDE als auch GNOME , wobei letzteres seit 2010 die bevorzugte Desktop-Umgebung ist.)

Zu den in jüngerer Zeit entwickelten Toolkits gehören Qt (1991– , verwendet von KDE ), GTK+ (1997– , verwendet von GNOME ), wxWidgets (1992– ), FLTK (1998– ), FOX (1997– ) und fpGUI (2005–heute).

Scheifler und Gettys entwarfen den X-Server so, dass er einfach, aber erweiterbar ist. Daher befindet sich ein Großteil der Funktionalität heute in Erweiterungen des Protokolls.

Auf Protokollebene können jeder Erweiterung neue Anfrage-, Ereignis- und Fehlerpakettypen zugewiesen werden. Clientanwendungen greifen über Erweiterungsbibliotheken auf die Funktionen der Erweiterungen zu. Berichten zufolge gestaltet sich das Hinzufügen von Erweiterungen zu aktuellen X-Server-Implementierungen aufgrund mangelnder Modularität im Serverdesign schwierig. ^{[ 5 ]} Ein langfristiges Ziel des XCB- Projekts ist die automatisierte Generierung sowohl der Client- als auch der Serverseite von Erweiterungen aus XML-Protokollbeschreibungen.

Die folgende Tabelle enthält einen Teilkatalog der entwickelten Erweiterungen, grob sortiert nach dem Datum ihrer Einführung:

• Xlib
• Intrinsische Eigenschaften (Xt)
• Kernprotokoll des X Window Systems
• X logische Schriftartbeschreibung

1. Manrique, Daniel (23. Mai 2001). „Die Architektur des X Window Systems: Überblick“ . X Window System Architecture Overview HOWTO . The Linux Documentation Project . Abgerufen am 13. Juli 2011 .
2. Maguolo, Filippo (16. Dezember 2005). „Die Architektur von X-Window“ . Lektionen in Linux . Mount Kisco, NY, USA: John F. Moore . Abgerufen am 13. Juli 2011 .
3. Stevens, W. Richard (1994). „30.5 X Window System“ (PDF) . TCP/IP Illustrated (PDF) . Addison-Wesley Professional Computing Series. Band 1, Die Protokolle (1. Auflage). Boston, MA, USA: Addison-Wesley . 30.5 X Window System . ISBN 978-0-201-63346-7OCLC 246049781.  Abgerufen am 13. Juli 2011 .
4. IBM Corporation, International Technical Support Center (Juli 1994). „1.2 X Concepts“ (PDF) . TCP/IP für MVS, VM, OS/2 und DOS: X Window System Guide (PDF) . IBM Redbooks (2. Auflage). Research Triangle Park, NC, USA: IBM . X Concepts . Abgerufen am 13. Juli 2011 .
5. Quercia, Valerie; O'Reilly, Tim (1993) [1988]. X Window System User's Guide: for X11 release 5. Definitive guides to the X Window System. Vol. 3. Sebastopol, CA, USA: O'Reilly & Assoc. ISBN 978-1-56592-014-9OCLC  682229836 . LCC  QA76.76.W56 Q47 . Abgerufen am 14. Juli 2011 . archive.org bietet die Ausgabe von 1990 an.

• Robert W. Scheifler und James Gettys: X Window System: Core and extension protocols, X version 11, releases 6 and 6.1 , Digital Press 1996, ISBN 978-1-55558-148-0
• „Eine Einführung in X11-Benutzeroberflächen“ . Archiviert vom Original am 3. Januar 2007.
• Einführung in X Windows [sic]
• Gettys, Jim (9. Dezember 2003). „Roadmap für Open-Source-Desktop-Technologien“ . Archiviert vom Original am 2. Januar 2006.

• X.Org Foundation (offizielle Homepage)
• X.Org Foundation Wiki
• Interna des X Window Systems, archiviert am 19.06.2024 im Internet Archive.
• Kenton Lees Seiten über X und Motif wurden am 20.05.2013 im Internetarchiv (Wayback Machine) archiviert .
• X11-Erweiterungs-Tutorial