Das X Window System Grafik für UNIX Linux User Group Mitterteich Jan Schampera <[email protected]> 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 X Window System 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 „Xinerama” 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 X Terminal) 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