Grafik für UNIX Linux User Group Mitterteich Jan Schampera <jan.schampera@web.de> 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 X in X............................................. 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
1 Einführung Grafische Oberflächen sind heutzutage normal und auf nahezu allen gängigen Betriebssystemen in verschiedenen 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 Applikationen 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 System, 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 Benutzercomputer, 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 Kommunikation können UNIX Sockets oder andere Techniken eingesetzt werden, was den Overhead der Netzwerkverbindung einspart, bei Fernverbindungen wird normalerweise das Internet Protokoll (IP) verwendet. X Server X Protokoll 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. 1 Ein 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
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 Extensions für 3D Rendering oder Xinerama 2. 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 konzentriert sich stattdessen auf ihre eigentliche Arbeit. Wirkliche Eingabegeräte sind kein Muss man denke an eine Videowand die über Netzwerk und X Protokoll 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 Unterdisplay betrachtet 3 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 unsicher 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öglichkeiten 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. 2 Extension um einen virtuellen Bildschirm über mehrere physikalische Displays zu erstellen 3 Ausnahme: Die schon erwähnte Xinerama Extension. LUG Mitterteich Seite 2 Jan Schampera
Die Angabe des Displays ist je nach Nutzung eine Kombination aus: Hostnamen oder Netzwerkadresse des entfernten X Servers. Ohne Angabe wird über Interprozesskommunikation 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öglichen 4 (einfachstes Beispiel: Zwischenablage) kann der X Server verwendet werden. Eine standardisierte Methodik dafür wird im ICCCM 5 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 X Terminal) angezeigt. Zur Koordination des Remotezugriffs wird neben dem X Protokoll selbst noch das XDMCP 6 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 Fenstersteuerung) 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 Anwendungen 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 beschrieben. 4 Normale 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. 5 Inter Client Communications Conventions Manual 6 X Display Manager Control Protocol LUG Mitterteich Seite 3 Jan Schampera
Display Manager Sitzungsstart X Programm X Server XDMCP (Anfrage) Displaygrafik (Anzeige) 00 11 00 00 11 11 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 Informationen (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 kommunizieren 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
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 minimieren 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 Programme 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 Anzeigesysteme 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 Eingabegerä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 besitzt ( 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 einem 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
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 verschiedenen 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 Internetverbindungen 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. 7 Natü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
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 Flexibilitä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 ersetzen 8. 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 Anwendungspaketen 9. 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 Displayserver angesprochen werden. In diesem Sinne ist eine der größten Stärken von X seine durchdringende Netzwerkfähigkeit gleichzeitig ein Schwachpunkt. 8 Eine 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. 9 Auch wenn vor ein paar Jahren die Zentralisierung wieder modern geworden ist. LUG Mitterteich Seite 7 Jan Schampera
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
Abbildung A-3: NX Sitzung zu einem entfernten GNOME Desktop LUG Mitterteich Seite 10 Jan Schampera