Das X System Grafik für UNIX

Linux User Group Mitterteich

Jan Schampera

August 2009 Inhaltsverzeichnis

1 Einführung 1

2 Entwicklungsgeschichte 1

3 Grundkonzept 1

4 Im Detail 2 4.1 X Server und Displays ...... 2 4.2 X Client ...... 2 4.3 Display Manager ...... 3 4.4 Window Manager ...... 3 4.5 Sitzungsverwaltung ...... 4 4.6 X Library ...... 4 4.7 Toolkit und Desktop Environment ...... 4

5 Möglichkeiten und Spezialitäten 5 5.1 XinX...... 5 5.2 Multihead ...... 5 5.3 X Proxies ...... 6 5.4 NX...... 6

6 Kritik 7 6.1 Einheitlichkeit der GUI ...... 7 6.2 Client/Server Architektur ...... 7

A Bildschirmfotos 8

Abbildungsverzeichnis

3-1 X Client/Server Modell ...... 1 4-1 Rolle des Display Managers bei Remoteverbindung ...... 4 5-1 Mehrere separate X Displays auf einem Computer (Multiseat) ...... 6 A-1 X in X: Xnest mit einer zweiten Benutzersitzung auf dem gleichen System ...... 8 A-2 DMX lokal simuliert mit Xephyr X Servern ...... 9 A-3 NX Sitzung zu einem entfernten GNOME Desktop ...... 10 Das

1 Einführung

Grafische Oberflächen sind heutzutage normal und auf nahezu allen gängigen Betriebssystemen in ver- schiedenen Varianten vorhanden. Im UNIX R Umfeld hat sich vor über 20 Jahren das X Window System R eingebürgert und durch seine durchgängige Modularisierung und Flexibilität bis heute gehalten. Das „X Window System”, „X11” oder einfach nur „X”, definiert ein einfaches Kommunikationsmodell zur Benutzung von grafischen Anzeigesystemen. Im Endeffekt ist es eine Weiterentwicklung der klassischen Textterminals: Spezialisierte Hardware oder Programme übernehmen die Ein- und Ausgabe, die Applika- tionen können sich auf ihre eigentliche Arbeit konzentrieren.

2 Entwicklungsgeschichte

Das X Window System wurde 1984 im Rahmen des Athena Projekts am MIT in Zusammenarbeit mit DEC und IBM entwickelt. 3 Jahre später erfolgte die Erweiterung auf X Window System Version 11, kurz X11. Das grundsätzliche Protokoll ist bis heute unverändert. In den folgenden Jahren wurde die Weiterentwicklung von X durch verschiedene Stellen vorgenommen, zuletzt von der X.Org-Foundation. Der Name „X” entstammt seiner Entwicklungsgeschichte: Eines der Vorbilder war das „W Window Sys- tem”, und X ist einfach der nachfolgende Buchstabe im Alphabet.

3 Grundkonzept

X definiert die Kommunikation zwischen einem grafischen Display mit Eingabegeräten („X Server”) und Programmen die diese Anzeige verwenden wollen („X Client”). Die umgekehrte Betrachtungsweise ist hier wichtig: Der X Server läuft normalerweise auf einem Benutzer- computer, der X Client auf einem Server (z.B. freigegebene Anwendung im Netzwerk). Da es sich bei X prinzipiell um ein Netzwerkprotokoll mit Client/Server-Architektur handelt, ist es völlig nebensächlich ob der X Client und der X Server auf dem gleichen System laufen. Bei lokaler Kommunika- tion können UNIX Sockets oder andere Techniken eingesetzt werden, was den Overhead der Netzwerkver- bindung einspart, bei Fernverbindungen wird normalerweise das Internet Protokoll (IP) verwendet.

X Protokoll X Server X Client

Abbildung 3-1: X Client/Server Modell

Das X Protokoll selbst definiert keine komplexeren Aktionen, nur einfache geometrische Elemente und Bitmaps auf einer rasterbasierten Anzeige und eine Verwaltung von rechteckigen Bildschirmausschnitten (z.B. Fenster, Buttons, Menüs)1. Dies bedeutet unter anderem dass das Aussehen von grafischen Elementen wie Schaltflächen oder Fensterrahmen vom X Client kommt – jede Anwendung kann also anders aussehen und anders funktionieren.

1Ein „X Window” ist nicht unbedingt immer ein „Fenster” im bekannten Sinne. Viele Elemente in X werden als X Window organisiert. Ein richtiges Fenster ist das, was man bei X „top level window” nennt.

LUG Mitterteich Seite 1 Jan Schampera Das X Window System

Neben der Ansteuerung der Grafik gibt es natürlich auch Steuer- und Ereignisfunktionen für Tastatur, Maus und ähnliche Geräte. Um Erweiterungen ohne Änderung der X Protokollarchitektur zu ermöglichen wurden sog. „X Extensions” vorgesehen, die der X Client bei Bedarf nutzen kann. Bekannte Beispiele hierfür sind spezielle Extensi- ons für 3D Rendering oder Xinerama2. Selbst Stolpersteine im X Kernprotokoll können leicht durch die Nutzung von Extensions behoben werden ohne das Protokoll selbst zu verändern („XFixes” Extension).

4 Im Detail

4.1 X Server und Displays

Der X Server steuert sowohl die grafischen Anzeigen als auch Eingabegeräte (Maus, Tastatur, Lightpen, . . . ) an und kommuniziert auf der anderen Seite mit den X Client Programmen, den eigentlichen Anwendungen. Er hat hierbei eine ähnliche Aufgabe wie klassische Textterminals und ihre Treiber – eine Textanwendung auf einem Terminal kümmert sich nicht um die Details der Tastatur oder des Bildschirms, sondern konzen- triert sich stattdessen auf ihre „eigentliche Arbeit”. Wirkliche Eingabegeräte sind kein Muss – man denke an eine Videowand die über Netzwerk und X Pro- tokoll angesprochen wird: Der Player läuft auf einem „normalen” Computer von dem aus man ihn auch steuern kann, das Video gibt der Player allerdings direkt auf der Videowand aus. Ein solches Gerät bräuchte keine Tastatur. Der X Server gruppiert die Geräte die er steuert in sogenannten Displays. Ein Display ist in der Regel eine Einheit von Tastatur, Maus und Grafikhardware (Monitor). Falls mehrere Grafikausgabegeräte für das Display verfügbar sind, wird jedes einzelne von ihnen als eine Art „Unterdis- play” betrachtet3 – ein sogenannter Screen. Ein Display hat also mindestens einen Screen. In der Theorie ist der X Server ein ganz normales Programm ohne Sonderstatus. Deshalb darf ein Fehler oder Absturz direkt im X Server keinerlei Auswirkungen auf das darunterliegende Betriebssystem haben. In der Praxis, z.B. ersichtlich auf dem Linux Betriebssystem mit der „X.org” X Server Software, laufen manche X Server mit Administratorprivilegien und greifen unter Umständen direkt auf die Hardware zu. So kann ein Fehler in der grafischen Oberfläche durchaus die Systemstabilität beeinflussen. Natürlich gibt es auch vollintegrierte X Server, kleine Computer die nur aus einem X Server bestehen. Sie laufen als X Terminals und erfüllen die Anforderung an moderne „thin clients”. Zugriffskontrolle ist natürlich wichtig: Die Authentifizierung der Benutzer erledigt ja das Betriebssystem bzw. wie später noch zu lesen ist der Display Manager. Der Zugriff auf die Anzeige selbst kann aber auch eingeschränkt werden, zum Beispiel • Hostbasiert: Simpler Mechanismus der auf Netzwerkadressen beruht → sehr unsicher • MIT Magic Cookie: Text „Cookies” die sowohl dem Server als auch dem Client bekannt sind → un- sicher • MIT Kerberos 5: Standard Kerberos 5 zum Einsatz in „kerberisierten” Netzen → sehr sicher

4.2 X Client

Der X Client, die eigentliche Endanwendung, benutzt über das X Protokoll die Fähigkeiten und Möglich- keiten eines X Servers bzw. die seines Displays. Welcher X Server zu benutzen ist, wird dem Programm als Parameter oder über die Prozessumgebung bekannt gemacht. Wenn dieser X Server beim Starten nicht erreichbar ist oder die X Verbindung mittendrin abbricht, kann der X Client nicht funktionieren und beendet sich.

2Extension um einen „virtuellen” Bildschirm über mehrere physikalische Displays zu erstellen 3Ausnahme: Die schon erwähnte „” Extension.

LUG Mitterteich Seite 2 Jan Schampera Das X Window System

Die Angabe des Displays ist je nach Nutzung eine Kombination aus: • Hostnamen oder Netzwerkadresse des entfernten X Servers. Ohne Angabe wird über Interprozess- kommunikation ein lokaler X Server kontaktiert. • Displaynummer auf dem jeweiligen Server, beginnend ab 0. • Screennummer auf dem jeweiligen Display, beginnend ab 0. Eine vollständige Displayadresse wäre zum Beispiel wkst1.users.example.net:0.0 (erster Screen auf dem ersten Display des X Servers wkst1.users.example.net). Um die Kommunikation zwischen X Clients untereinander zu ermöglichen4 (einfachstes Beispiel: Zwi- schenablage) kann der X Server verwendet werden. Eine standardisierte Methodik dafür wird im ICCCM5 beschrieben.

4.3 Display Manager

Der Display Manager (DM) ist für den Start von Sitzungen auf X Displays verantwortlich. Weithin bekannt als „Login Bildschirm” fragt der DM Benutzername und Passwort ab und erlaubt dem Anwender bestimmte Aspekte der Sitzung einzustellen (z.B. verschiedene Window Manager oder Desktop Umgebungen). Da die Software selbst ein grafisches X Programm ist, muss bereits ein arbeitsfähiges Display existieren um den Display Manager anzuzeigen: • Im Falle eines lokalen X Servers wird vor Ausführung des DM normalerweise ein (oder mehrere) Displays gestartet und der Manager darauf angezeigt. • Im Falle des Remotezugriffs wird der Display Manager auf dem Display des entfernten Rechners (z.B. ein ) angezeigt. Zur Koordination des Remotezugriffs wird neben dem X Protokoll selbst noch das XDMCP6 benötigt um den Display Manager zu aktivieren (Abb. 4-1). Bei einem Remotezugriff mittels XDMCP können das Display, der Display Manager und die X Programme auf unterschiedlichen Systemen laufen (Netzwerktransparenz). Auch kann ein Display Manager eine Liste anderer DM zur Auswahl anbieten mit denen sich der Benutzer verbinden kann („Chooser”). Der X Server der auf dem Benutzersystem läuft verbindet sich dann jeweils mit dem ausgewählten Display Manager. Ist ein DM nicht XDMCP-fähig, beschränkt er sich auf lokale Sitzungen.

4.4 Window Manager

Der Window Manager (WM) kümmert sich um Dekoration, Standardbestandteile (z.B. Buttons zur Fens- tersteuerung) und Verwaltung (Verschieben, Verändern, . . . ) von Fenstern. Aus Sicht des X Servers ist er ein ganz normaler Client, aus Sicht des X Clients ist er eine zusätzliche Komponente mit der kommuniziert werden muss. Auf Ebene der Window Manager werden auch virtuelle Arbeitsflächen oder das Umschalten zwischen An- wendungen realisiert. Auch das „Minimieren” von Fenstern ist ein Service des WM: Das Fenster des X Clients wird übergangsweise vom Display genommen („unmapped”) und stattdessen etwa ein Icon oder eine Schaltfläche gezeigt. Da der Window Manager „nur” ein X Client ist kann er auch ohne Probleme ausgetauscht werden ohne die laufenden Anwendungen zu beenden. Sein Fehlen ist keine kritische Situation an sich, allerdings wird dem Benutzer dadurch eine Fenstersteuerung unmöglich gemacht. Der Mindestgehalt an Funktionalität und die genaue Kommunikation wird wiederum im ICCCM beschrie- ben. 4Normale Interprozesstechniken sind hier völlig unsinnig, da die X Clients nicht unbedingt auf dem gleichen System laufen müssen. In der Praxis vergessen manche Programmierer leider diesen Umstand und betreiben „host-lokale Interprozesskommunikation” die unwirksam wird wenn man im Netzwerk verschiedene X Clients auf verschiedenen Systemen am gleichen X Server laufen lässt. 5Inter Client Communications Conventions Manual 6X Display Manager Control Protocol

LUG Mitterteich Seite 3 Jan Schampera Das X Window System

Sitzungsstart Display Manager

X Programm

XDMCP (Anfrage) X Server Displaygrafik (Anzeige)

 

Abbildung 4-1: Rolle des Display Managers bei Remoteverbindung

4.5 Sitzungsverwaltung

Der „Zustand der Sitzung” ist gleichbedeutend mit dem „Zustand des Desktops”. Wird dieser abgespeichert, kann die Umgebung beim erneuten Login wieder hergestellt werden. Erreicht wird dies, indem X Programme über Client/Client Kommunikation einen bestimmten Satz an In- formationen (Fensterpositionen und -größen, laufende Anwendungen, . . . ) vom Session Manager (SM) speichern lassen und wieder abrufen können.

4.6 X Library

Die X Library implementiert Funktionen mit denen X Clients relativ einfach mit dem X Server kommunizie- ren können. Es ist das gängige API zur X Programmierung und erspart dem Programmierer, das komplette X Protokoll zu implementieren. Standardkomponenten zur GUI Programmierung gibt es auch hier nicht.

4.7 Toolkit und Desktop Environment

Eine Programmierung bur mit der X Library birgt Komplexität und ist umständlich. Man muss sich trotzdem um das Aussehen kümmern, man muss trotzdem jeden Teil der Kommunikation mit dem X Server selbst machen.

LUG Mitterteich Seite 4 Jan Schampera Das X Window System

Aus diesem Grund haben sich im Laufe der Zeit Programmierframeworks („X Toolkits”) herausgebildet die beispielsweise folgende Funktionen übernehmen: • Bereitstellung von Standardelementen für eine Benutzeroberfläche (Buttons, Icons, Rahmen, . . . ) und somit ein Vereinheitlichung • Zusammenfassung von mehreren technisch nötigen Schritten zu logischen Schritten („Fenster mini- mieren” statt alle Schritte zum unmappen selbst zu programmieren) • Einheitliche Kommunikation mit Window und Session Manager • Sonstige integrierte Systeme (gemeinsame Konfigurationsdatenbank, . . . ) Eine Sammlung von Anwendungen die das gleiche Toolkit benutzen und voll integriert sind nennt man „Desktop Environment”. Die bekanntesten Vertreter sind wohl KDE und GNOME. Desktopumgebungen stellen einheitliche Pro- gramme und Schnittstellen für alle Aspekte einer Benutzerumgebung bereit, vom „Login Bildschirm” zum Start der X Sitzung über den Window Manager bis zur Druckerverwaltung. Für den Benutzer ist dies heute die übliche und beste Art, X Applikationen zu nutzen.

5 Möglichkeiten und Spezialitäten

5.1 X in X

Technisch einfach und nett anzusehen ist „X in X”. Ein solcher X Client, der gleichzeitig X Server ist, steuert keine Hardware an sondern verwendet zur Ein- und Ausgabe den X Server auf dem er selbst läuft. Beispiele für solche Programme sind Xnest (Abb. A-1, Seite 8) oder Xephyr.

5.2 Multihead

Natürlich kann ein Computer mehrere Anzeigesysteme (Heads) besitzen. Sie können in mehreren Varianten in X abgebildet werden. Diese Varianten unterscheiden sich nur dadurch, wie die physikalischen Anzeige- systeme organisiert werden und wie sie angesprochen werden. Die einfachste Version besteht darin, einfach mehrere X Server zu betreiben, wobei jeder X Server für ein Anzeigesystem zuständig ist. Idealerweise sollte dann für jeden X Server auch ein separater Satz Einga- begeräte vorhanden sein. In einem solchen Szenario können mehrere Benutzer ohne weiteres gleichzeitig an einem einzigen Computer arbeiten, da jeder Benutzer seine unabhängigen Ein- und Ausgabegeräte be- sitzt („Multiseat”). Die X Displays sind in diesem Fall komplett voneinander unabhängig, so als ob sie auf eigenständigen Systemen laufen würden (Abb. 5-1). Eine andere Möglichkeit bieten Screens. Im Normalfall wird eine Ausgabe nicht nur auf einem bestimmten X Display gemacht, sondern auf ei- nem Screen dieses Displays. Man kann einen X Server mit einem Display starten, wobei das Display aus mehreren Screens besteht. Diese Screens können separat angesprochen werden, verhalten sich eigentlich wie eigene Displays, gehören aber zusammen (man kann je nach Einsatzzweck zum Beispiel auch Fenster zwischen ihnen verschieben). Weiterhin kann ein X Server einzelne Anzeigen zu einem grossen virtuellen Display mit einem Screen zusammenfassen. Aus Sicht des X Clients verhält sich der Server, als ob er nur einen Monitor (und damit einen Screen) hätte. Solche Möglichkeiten sind dank Distributed Multihead X (DMX) auch als Netzwerkvariante verfügbar. Dabei sind die einzelnen Heads nicht physikalische Anzeigesysteme, sondern Displays im Netzwerk. Man könnte somit mittels DMX in Kombination mit Xinerama einen Desktop über mehrere Computer (genauer: Ihre Anzeigesysteme) verteilen und wie einen einzigen Computer mit mehreren Grafikkarten nutzen. Auf einem einzelnen System kann man DMX auch testen: Die Remote Displays sind mit „X in X” simulierbar (Abb. A-2, Seite 9).

LUG Mitterteich Seite 5 Jan Schampera Das X Window System

X Server 1 X Programm

X Server 2 X Programm

X Server 3 X Programm

Abbildung 5-1: Mehrere separate X Displays auf einem Computer (Multiseat)

5.3 X Proxies

Ein X Proxy ist, ähnlich wie ein HTTP Proxy, ein „Zwischenserver” für die Displayverbindung. Der X Client verbindet sich dabei nur mit dem Proxy und kommuniziert ausschliesslich mit diesem. Der Proxy verbindet sich dann zu einem „echten” Display und ist nur Durchgangsstation. In gewisser Weise stellt ein X Proxy somit ein virtuelles Display für das X Programm dar. Eine mögliche Anwendung für einen solchen Proxy ist das Verschieben von Programmen zwischen ver- schiedenen X Servern, wodurch man zum Beispiel seine Programme auf andere Computer „mitzunehmen” kann(Programm: XMove)7.

5.4 NX

NX ist eine Remote Desktop Software des italienischen Herstellers NoMachine. Eine NX Verbindung ist eigentlich eine X Verbindung über einen speziellen Proxy. Dieser sorgt dabei für Verschlüsselung und hochgradige Kompression, sowie eine eigene Authentisierung. NX Sitzungen können sowohl komplette Desktops (Abb. A-3, Seite 10) als auch einzelne Anwendungen verfügbar machen. Änderungen an den X Clients oder Desktopsystemen sind nicht notwendig. Serverseitig ist NX clusterfähig und kann als zentraler Dienst für die Freigabe von Applikationen auf Thin Clients verwendet werden (in etwa vergleichbar mit Citrix Farmen). Die Protokollkompression und Latenzverringerung ist so stark, dass bei heutzutage üblichen Internetver- bindungen nur wenig Unterschied zu einem lokalen Desktop besteht. Laut Hersteller ist ab 40 KBit/s ein einigermassen flüssiges Arbeiten möglich. Beim Einsatz in schnelleren Netzwerken wie gängigen LAN kann man die Kompression verringern oder ganz abschalten. Neben der Verwaltung der X Verbindungen kann NX noch desktopverwandte Dienste wie Druck, Audio oder Dateifreigaben „durchreichen”.

7Natürlich ist alles was „Zwischenserver” beinhaltet eine Proxyverbindung, somit auch das schon angesprochene DMX. Der DMX Server ist eigentlich ein X Proxy, nur mit anderen Aufgaben.

LUG Mitterteich Seite 6 Jan Schampera Das X Window System

6 Kritik

6.1 Einheitlichkeit der GUI

Aufgrund der Tatsache dass X an sich keinerlei Vorgaben über Optik und Inhalte macht, haben sich viele Desktop Systeme und Toolkits entwickelt die teilweise sehr unterschiedliches Look and Feel aufweisen. Dies ist nicht direkt ein Problem des X Systems selbst, eher eine Folge seiner eigentlich recht hohen Flexi- bilität. Dafür gibt es Lösungsansätze. Das freedesktop.org Projekt beispielsweise entwickelt Richtlinien für Benutzerschnittstellen und deren Funktionsweise. Andere Ansätze versuchen, X selbst zu ersetzen8. Im gängigen UNIX-Bereich kann man davon ausgehen dass ein möglicher Nachfolger von X kompatibel sein muss um akzeptiert zu werden.

6.2 Client/Server Architektur

Viele Computer sind heutzutage selbstständige Workstations mit kompletten Betriebssystemen und Anwen- dungspaketen9. Auf solchen Systemen ist die Netzwerkkommunikation von X eher ein Hindernis. Auch wenn die Latenzzeiten durch die Nutzung von IPC-Techniken minimal sind, muss trotzdem ein Displayser- ver angesprochen werden. In diesem Sinne ist eine der größten Stärken von X – seine durchdringende Netzwerkfähigkeit – gleichzeitig ein Schwachpunkt.

8Eine dieser Lösungen ist das Y Window System, das viele Bestandteile der Oberflächen in den Server-Teil verlagert und andere Schwächen von X eliminiert. Die Y Window Entwicklung ist seit einigen Jahren eingeschlafen. 9Auch wenn vor ein paar Jahren die Zentralisierung wieder modern geworden ist.

LUG Mitterteich Seite 7 Jan Schampera Das X Window System

A Bildschirmfotos

Abbildung A-1: X in X: Xnest mit einer zweiten Benutzersitzung auf dem gleichen System

LUG Mitterteich Seite 8 Jan Schampera Das X Window System

Abbildung A-2: DMX lokal simuliert mit Xephyr X Servern

LUG Mitterteich Seite 9 Jan Schampera Das X Window System

Abbildung A-3: NX Sitzung zu einem entfernten GNOME Desktop

LUG Mitterteich Seite 10 Jan Schampera