X-Server Architektur

Transcription

BAKKALAUREATSARBEIT
(Seminar aus Betriebssysteme)
zur Erlangung des akademischen Grades
Bakkalaureus der technischen Wissenschaften
in der Studienrichtung
INFORMATIK
Eingereicht von:
Harald Roithmayr, 0155035
Lukas Leblhuber, 0156290
Angefertigt am:
Institut für Informationsverarbeitung und Mikroprozessortechnik - FIM
Betreuung:
o.Prof. Dr. Jörg R. Mühlbacher
Dipl. Ing. Andreas Putzinger
Linz, Juni 2005
Seminararbeit aus Betriebssysteme
Eidesstattliche Erklärung
Wir erklären an Eides statt, dass wir die vorliegende Bakkalaureatsarbeit selbstständig und
ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt
bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht haben.
Des weiteren versichern wir, dass wir diese Bakkalaureatsarbeit weder im In- noch im
Ausland in irgendeiner Form als Prüfungsarbeit vorgelegt haben.
Harald Roithmayr
Lukas Leblhuber
Seite 1
Inhaltsverzeichnis
Eidesstattliche Erklärung ........................................................................................................ 1
Inhaltsverzeichnis ..................................................................................................................... 2
1
Abstract ............................................................................................................................. 4
2
X-Protokoll........................................................................................................................ 5
3
4
5
6
7
8
2.1
Einführung.................................................................................................................. 5
2.2
Client-Server-Prinzip ................................................................................................. 5
2.3
Grafikprotokoll........................................................................................................... 6
2.4
Eingabeprotokoll ........................................................................................................ 6
2.5
Performance ............................................................................................................... 6
Xlib................................................................................................................................... 10
3.1
Einführung................................................................................................................ 10
3.2
Display Funktionen .................................................................................................. 13
3.3
Fenster Manipulation ............................................................................................... 14
3.4
Grafikfunktionen....................................................................................................... 15
XFree86 ........................................................................................................................... 16
4.1
Einführung................................................................................................................ 16
4.2
Lizenzstreitigkeiten und Abspaltung von XFree86................................................... 16
4.3
Architektur................................................................................................................ 17
Integration eines Windowmanager............................................................................... 20
5.1
Was ist ein Windowmanager? .................................................................................. 20
5.2
Bekannte Windowmanager....................................................................................... 20
5.3
Installation und Konfiguration ................................................................................. 21
Ausgabefenster auf anderen Rechner senden.............................................................. 23
6.1
Einleitung ................................................................................................................. 23
6.2
Voraussetzungen....................................................................................................... 23
6.3
Praktische Durchführung ......................................................................................... 23
Remote Desktop.............................................................................................................. 26
7.1
Remote Framebuffer Protokoll................................................................................. 26
7.2
Virtual Network Computing ..................................................................................... 27
7.3
KDE Desktop-Sharing .............................................................................................. 28
Mehrere X-Server auf einem Rechner......................................................................... 29
Seite 2
8.1
Motivation................................................................................................................. 29
8.2
Starten mehrerer X-Server ....................................................................................... 30
9
Résumé ............................................................................................................................. 32
10
Quellen............................................................................................................................. 33
Seite 3
1 Abstract
Dieses Paper befasst sich mit dem X-Server, seiner Architektur und seinem praktischen
Betrieb. Es beinhaltet unter anderem Beschreibungen des X-Protokolls und der Bibliotheken,
die vom X-Server verwendet werden. Weiters wird die Open-Source-Version des X-Servers,
XFree86 vorgestellt und ein Einblick in seine Konfiguration gegeben.
Die grundlegenden Technologien werden praktisch besprochen und angewandt, außerdem
erhält der Leser Einblick in moderne Techniken der vernetzen Kommunikation.
Zuletzt werden noch Anwendungsszenarien für mehrere X-Server aufgezeigt und Methoden
um weitere X-Server und Window Manager zu starten.
Seite 4
2 X-Protokoll
2.1 Einführung
Das X-Server Protokoll wurde Anfang der 80er Jahre entwickelt, um eine auch für
Netzwerkanwendungen brauchbare, graphische Benutzeroberfläche für UniX Betriebssysteme
zu definieren.
Ein Großteil der Entwicklung wurde am Massachusetts Institute of Technology (MIT) unter
dem Projektnamen Athena durchgeführt. Die Verantwortlichen für dieses Projekt waren vor
allem Robert W. Scheifler und Jim Gettys. Unterstützt wurde die Entwicklung von einigen
namhaften Konzernen wie DEC und IBM, die sowohl als Sponsor auftraten, als auch eigene
Entwicklungen in das Projekt mit einfließen ließen. Mit diesen beiden Firmen wurde – in
enger Zusammenarbeit mit dem MIT – das Xt-Toolkit entwickelt.
Ab dem Release 2 der Version 11 des X-Window-Systems (X11R2) wurde die Entwicklung
dem XConsortium übertragen.
Schon ab den ersten Entwürfen des Protokolls wurde darauf Wert gelegt, einen portablen
Standard zu scha ffen, der es erleichtern sollte, graphische Benutzeroberflächen für
Programme zu schaffen. Dies sollte vor allem durch die Verwendung von Bibliotheken und
generischem Code ermöglicht werden. Eine plattformübergreifende Verfügbarkeit sollte die
Entwicklungs- und besonders die Portierungszeit erheblich verkürzen. Weiters wurde eine
normierte Schnittstelle für die Softwareentwicklung für einen Wettbewerbsvorteil sorgen.
2.2 Client-Server-Prinzip
Im Gegensatz zu graphischen Oberflächen anderer Hersteller wie Microsoft oder IBM, die nur
dazu dienen, grafische Applikationen auf einem lokalen Rechner anzuzeigen, ist es mit dem
X-Server möglich, die Datenverarbeitung auf einem Rechner von der Steuerung und Anzeige
auf einem anderen Rechner zu trennen. Daraus ergibt sich der Vorteil, dass die Bedienung
identisch ist, egal ob lokal oder remote berechnet wird.
Im X-Protokoll scheint die Einteilung in Client und Server umgekehrt, da der Server lokal und
der Client remote betrieben wird. Die Logik dahinter wird klar, wenn man das Ganze so
betrachtet, dass der X-Server Darstellungsfunktionalität zur Verfügung stellt und auf
Seite 5
eingehende Verbindungen von Nutzern wartet, die sich ein- und ausloggen können. Das XProtokoll stellt die plattformunabhängige Schnittstelle zwischen unserem Server und dem
Client dar.
Für die Übertragung der Daten zwischen Client und Server werden bekannte
Netzwerkprotokolle wie IP oder X.25 verwendet. Die Sicherung der Datenübertragung wird
auch von den Netzwerkprotokollen wie TCP gewährleistet. Somit muss sich das X-Protokoll
selbst nicht darum kümmern, wie die Daten von einem Rechner zum anderen gelangen.
Deshalb bleibt auch der eigentliche Informationsaustausch für die Anwendung verborgen und
es muss nicht unterschieden werden, ob sich der Server auf dem gleichen Rechner oder auf
einem anderen Gerät befindet.
2.3 Grafikprotokoll
Das X-Protokoll besitzt neben der Kommunikation zwischen Client und Server auch noch die
Methoden zur Grafikdarstellung. Über die Bibliotheken des X-Protokolls werden Funktionen
und Parameter, die zur Darstellung benötigt werden, zu semantischen Objekten
zusammengefasst und an den Server geschickt. Dieser versucht die Objekte in graphische
Grundfunktionen zu zerlegen und auszuführen.
2.4 Eingabeprotokoll
Weiters besitzt das X-Protokoll die Möglichkeit auf Benutzereingaben zu reagieren. Diese
Eingaben, egal ob über Tastatur oder Maus, werden in einer Warteschlange zusammengefasst
und an die Applikation gesendet. Wie die Eingaben abgearbeitet werden, wird dem jeweiligen
Programm überlassen. Sie können in ihrer Eingangsreihenfolge behandelt werden, oder es
können beispielsweise die Mauseingaben vorgezogen werden. Dies ist dadurch möglich, dass
aus der Liste der Eingaben eine Teilmenge mit einer bestimmten Eigenschaft selektiert
werden kann.
2.5 Performance
Bei der Entwicklung des X-Protokolls wurde auf eine hohe Leistungsfähigkeit des Systems
geachtet. Eine wichtige Methode, um die Effizienz zu erhöhen, ist das Buffering. Auf beiden
Seiten des Systems, werden die Befehlfolgen gepuffert. Dies wirkt sich positiv auf die
Performance aus, da alle Daten über Netzwerkprotokolle übertragen werden. Wenn eine große
Seite 6
Menge an Daten verschickt werden muss, ist es für das System nicht förderlich, wenn jeder
Befehl einzeln verschickt wird, da an jedes Datenpaket, das übertragen werden muss, ein
Header für das entsprechende Netzwerkprotokoll angehängt wird. Dieser Header besteht unter
anderem aus der Ziel- und Senderadresse, sowie weiteren für den Netzwerkverkehr wichtigen
Daten.
Das Buffern wirkt sich vor allem positiv bei größeren Strecken aus, die über mehrere
Netzwerkknoten gehen, weil es ja sein kann, dass bei jedem Knoten eine Prüfung des Paketes
durchgeführt wird. Durch die Zusammenfassung mehrerer Befehle müssen weniger Daten
über das Netzwerk gesendet werden. Dadurch verringert sich der Traffic, der durch die XServer Kommunikation entsteht.
Ein weiterer Performancevorteil wird dadurch bewirkt, dass sich die Grafikbefehle nicht nur
auf Grundbefehle wie Linie und Punkt beziehen, sondern komplexere Objekte wie Rechtecke
erzeugt werden können.
Um ein Rechteck durch Linien Darzustellen müssen vier Linien mit jeweils zwei Punkten
angegeben werden. Mit einer Funktion zum Zeichnen eines Rechtecks müssen nur 2 Punkte
angegeben werden (links-oben/rechts-unten), und das Rechteck kann genau bestimmt werden.
Somit muss nur ein Viertel der Datenmenge übertragen werden, die für vier Linien benötigt
werden würde. Da die meisten Grafikkarten auch noch Funktionen besitzen, die ein Rechteck
schneller zeichnen als die einzelnen Linien, entsteht auf der Seite des Servers einen weiterer
Performancegewinn.
2.5.1
Der Server
Der X-Server stellt die Anzeige- und Steuerungsfunktionalität dar, sozusagen das Terminal.
Er läuft immer auf der lokalen Maschine und ist zweigeteilt in einen geräteunabhängigen Teil,
der Darstellungsdaten von Anwendungen entgegennimmt und verarbeitet und einen
geräteunabhängigen Teil, der die eigentliche Darstellung der Graphiken der Anwendungen
übernimmt. Die Kommunikation zwischen den beiden Schichten erfolgt über „Events, die
zwischen den einzelnen Schichten ausgetauscht werden, also Nachrichtenpakete, die von
einer Schicht an die nächste gesendet und dort weiterverarbeitet werden.“ [Linux Magazin]
Seite 7
Geräteunabhängige Schicht:
Der DIX (DeviceIndependentXserver-Layer) stellt im Wesentlichen die Implementierung des
X-Protokolls dar. Diese Schicht ist in allen X-Servern gleich, um größtmögliche
Kompatibilität und die strikte Trennung von Client- und Serverprogrammierung zu
gewährleisten.
Geräteabhängige Schicht:
“DDX (DeviceDependentXserver-Layer) ist der Sammelbegriff für alle geräteabhängigen
Teile des X-Servers. Es ist über mehrere Verzeichnisse unterhalb des Server-Verzeichnisses
xc/programs/Xserver/ verteilt und enthält sowohl einige Bibliotheken zur Vereinfachung
der Hardwareprogrammierung als auch die schließlich damit realisierten Routinen.“ [Linux
Magazin] Eingehende X-Events vom DIX werden in Hardwareroutinen umgesetzt um
Darstellungen auf dem Bildschirm vorzunehmen. Hardwareaktivität, wie Maus- und
Tastaturkommandos werden in plattformübergreifend Form gebracht und ans DIX
weitergegeben.
Extensions:
Erweiterungen (Extensions) wie die Phigs Extension to X - PEX und die XInput Extension
erweitern den X-Server mit zusätzlicher Funktionalität, wie eigenen Extension-spezifischen
Requests, Events und Errors. Dabei wird auch das X-Protokoll erweitert, so dass auch auf der
Client-Seite des X-Window Systems zusätzliche Bibliotheken erforderlich sind, um das
erweiterte Protokoll auswerten und generieren zu können. Im Falle der erwähnten Extensions
sind das die libPEX5 und libXi. Extensions sind intern oft, ähnlich wie der X-Server, in
einen DIX/OS/DDX- Teil aufgeteilt und als größtenteils eigenständiger Teil in den Server
integriert.“ [Anheyer]
[x.org]
Seite 8
2.5.2
Der Client
Jede Anwendung, die auf die X-Bibliothek (Xlib s.u.) zurückgreift und zur Darstellung mit
einem X-Server kommuniziert, wird X-Client genannt. Ein solches Programm sollte in „etwa
wie folgt aussehen:
§
Initialisierung:
o Verbindung zum Server aufbauen
o Fenster öffnen
o Ressourcen (z.B. Zeichenmodus, Schrift, …) definieren
§
Hauptschleife:
o Events abfragen
o Events bedienen
o eigentlicher Programm Code
§
Ende:
o eigener Code
o Fenster schließen
o Ressourcen freigeben
o Verbindung zum Server schließen“ [Lueders]
Seite 9
3 Xlib
3.1 Einführung
Unter XLib versteht man eine Sammlung von Bibliotheken, die benötigt werden, um grafische
Anwendungen für den X-Server zu erstellen und die Kommunikation zwischen Server und
Client zu ermöglichen. Diese Kommunikation findet auf einem lokalen System über UnixDomain-Sockets (/tmp/.X11-unix/X0) und zwischen verschiedenen Rechnern über
TCP/IP oder DECnet statt. Sie wird immer mittels Paketen realisiert, wobei zwischen vier
Arten von Paketen unterschieden wird:
[Bräuner]
3.1.1
Request
Der Client schickt Zeichenbefehle an den Server immer mit einem Request Paket. Um die
Geschwindigkeit des Systems zu erhöhen, wartet der Client nicht auf die Antwort, die in
Form eines Reply Pakets vom Server kommt, ausgeno mmen es wird von der momentan
ausgeführten Operation ausdrücklich gefordert.
Bei diesem System verlässt man sich darauf, dass die darunter liegende Netzwerkschicht (in
den meisten Fällen Layer 4 des ISO/OSI-Schichtenmodell) das korrekte Senden eines Paketes
überwacht und es bei einem Fehler noch einmal gesendet wird. Die Größe eines Request
Pakets muss immer ein Vielfaches von 4 Byte betragen. [Scheifler Gettys]
Seite 10
3.1.2
Reply
Die vom Client erwarteten Aktionen werden am Server ausgeführt. Sobald dies geschieht,
schickt der Server ein Reply-Paket an den Client zurück. Es wird jedoch nicht auf jeden
Request ein Reply geschickt, sondern nur auf solche, die Informationen vom Server
anfordern. So wird zum Beispiel einen Request zum Zeichnen einer Linie kein Reply
gesendet. Auf ein Request aber, das die aktuelle Fenstergröße erfragt, wird sehr wohl mit
einem Reply geantwortet. Die Größe eines Antwortpakets muss wie das Request Paket selbst
wieder ein Vielfaches von 4 Bytes betragen und zusätzlich noch eine Mindestgröße von 32
Bytes aufweisen.
3.1.3
Events
Events teilen dem Client mit, ob sich am Zustand des Bildschirms (z.B. ein verdecktes Fenster
wurde freigelegt), der Tastatur oder der Maus etwas geändert hat. Der Client kann dann mit
Hilfe von Xlib-Funktionen auf diese Events reagieren. Diese Ereignisse werden vom XServer selber registriert und Events werden somit nur vom Server an den Client geschickt.
Der Client verarbeitet die Benutzereingabe und führt die daraus resultierende Aktion aus.
Danach schickt er die Daten für die geänderte Bildschirmausgabe an den Server, der diese
dann auf den Monitor überträgt.
Abhängig vo m Programm kann es vorkommen, dass ein Event für den Client keine wichtigen
Informationen enthält. Wenn dem Server bekannt ist, welche Events der Client nicht benötigt,
werden diese gleich vom Server wieder verworfen, was gerade bei einer Client-ServerVerbindung, die über ein Netzwerk hergestellt wurde, einen Performancegewinn bringt.
Die Entscheidung, welches Event der Server an den Client schickt und welches verworfen
wird, wird natürlich nicht willkürlich vom Server getroffen, sondern ist in dem ServerAttribut event mask genau festgelegt. Weiters befindet sich in der event mask noch eine
Liste mit Events, die immer wieder das gleiche Request vom Client erze ugen. Um in diesem
Fall nicht erst ein Event an den Client schicken zu müssen und zu warten, bis dieser eine
passende Request Sequenz erzeugt und gesendet hat, kann der Server für diese Events selbst
das
Request
erzeugen
und
sofort
in
die
Warteschlange
einreihen.
Alle Event Pakete haben eine fixe Größe von 32 Bytes, um die Struktur der Warteschlange
und das Eventhandling zu vereinfachen.
Seite 11
3.1.4
Error
Wenn eine Operation nicht durchführbar ist, so antwortet der X-Server dem Client mit einer
Error Message. Gründe für einen Fehler liegen meist darin, dass entweder der Server nicht
genug Speicher zur Verfügung stellen kann, um den Request richtig zu bearbeiten, oder
falsche bzw. fehlende Parameter im Request. Der Server überprüft bei der Ankunft eines
neuen Request, ob alle Parameter vorhanden sind, indem er die Länge des ganzen
übertragenen Befehls kontrolliert. Diese Prüfung wird nur vom Server durchgeführt, da der
Client keinen Zugriff auf die nötigen Daten hat, um die Befehlslänge zu kontrollieren.
Obwohl eine Error Message auf den ersten Blick ein Event ist, wird diese anders behandelt.
Events kommen beim Client in eine Warteschlange und werden nacheinander vom Client
abgearbeitet. Eine Error Message entspricht eigentlich einem Event mit höchster Priorität. Sie
überspringt die ganze Warteschlange und wird sofort von einem Fehlerbehandlungsprozess
bearbeitet.
Ein an den Client gesendeter Error kann verschiedene Aufgaben erfüllen. Zum einen kann er
einfach nur als Mitteilung über einen aufgetretenen Fehler dienen, zum anderen stellt er auch
eine Reparaturroutine dar. Im zweiten Fall können jedoch erhebliche Probleme auftreten, es
kann nämlich vorkommen, dass ein Fehler in einem Request nicht sofort entdeckt wird, wenn
dieser zum Beispiel dadurch ausgelöst wird, dass zu wenig Speicher zur Verfügung steht. Es
ist anzunehmen, dass bis zum Entdecken des Fehlers schon weitere Requests vom Client an
den Server gesendet wurden und der Server diese auch abgearbeitet hat, nachdem eine Error
Message erzeugt wurde. Im X-Server System gibt es keine Möglichkeit, bereits abgearbeitete
Requests wieder rückgängig zu machen. Um weitere Fehler zu vermeiden, ist es dem Client
nicht erlaubt, auf Errors, die eine Fehlerbehandlungsroutine enthalten, direkt mit einem neuen
Request zu antworten.
Die Standardvorgehensweise des Client besteht in diesem Fall darin, eine Fehlermeldung an
den Server zu senden und den Clientprozess, der den Fehler verursacht hat, zu beenden. Die
gleiche Vorgehensweise wird auch dann verwendet, wenn die Verbindung zwischen Client
und Server unterbrochen wird.
Da eine Error Message eine spezielle Art eines Events darstellt, hat diese auch wie ein Event
eine fixe Größe von 32 Bytes, obwohl nur die Ersten 11 Bytes benötigt werden. [Scheifler
Gettys]
Seite 12
Beispiel für eine Error Message (Bad Window):
# of Bytes
Type
Values
Description
1
0
error (always zero for errors)
1
3
code (Bad Window)
2
unsigned integer
sequence number
4
unsigned integer
bad resource id
2
unsigned integer
minor opcode
1
unsigned integer
major opcode
21
unused
[X-Protocol]
3.2 Display Funktionen
Unter einem Display versteht man eine Verbindung, die eine Client-Applikation zur
Workstation aufbaut. Über das Display können Ressourcen auf der Workstation belegt
werden. Bei diesen Ressourcen handelt es sich um Fenster, Farben, Zeichensätze, Muster
(Pixmaps), etc.
3.2.1
Erzeugen einer Verbindung zum Display
Die Verbindung zum X-Server ist die erste Aufgabe, die der X-Client nach dem Start (meist
direkt mir dem Start des Betriebssystems verbunden) ausführen muss. Nachdem diese
Verbindung erfolgreich erstellt wurde, kommt es zu einer Authentifizierungsphase, in der der
Server prüft, ob es dem Client gestattet ist, sich an diesem Server anzumelden.
Sobald die Anmeldung erfolgt ist, wird die Verbindung zum Display aufgebaut. Dies
geschieht über den Xlib-Befehl XOpenDiaplay(). Dabei wird der Bibliothek ein Zeiger auf
einen Identifikationsstring übergeben, in dem die Informationen über das zu öffnende Display
stehen.
An dieser Stelle kann auch ein Zeiger übergeben werden der auf null zeigt. In diesem Fall
wird vom X-Server ein Standarddisplay mit den Werten, die in der Environment-Variable
$DISPLAY zu finden sind, erstellt.
Seite 13
3.2.2
Schließen der Verbindung
Um ein Display zu schließen sind drei Schritte notwendig. Zuerst muss mit dem Befehl
XFreeGC(dp,gc) der angeforderte Graphics Context wieder freigegeben werden. Danach
wird mit XDestroyWindow(dp,win) das erzeugte Fenster geschlossen und zum Schluss
mit XCloseDisplay(dp) die Displayverbindung geschlossen.
3.3 Fenster Manipulation
3.3.1
Fenster erzeugen
Um ein neues Fenster zu erzeugen, muss zuerst die oben beschriebene Displayverbindung
hergestellt werden. Danach müssen die einzelnen Parameter des Fensters festgelegt werden
und das Fenster erzeugt werden.
Display *mydpy;
Window mywin;
…
myscreen = DefaultScreen(mydpy);
bg = WhitePixel(mydpy, myscreen);
fg = BlackPixel(mydpy, myscreen);
myhint.x = 200;
myhint.y = 100;
myhint.width = 256;
myhint.height = 256;
myhint.flags = PPosition | PSize;
mywin = XCreateSimpleWindow(mydpy, DefaultRootWindow(mydpy),
myhint.x, myhint.y, myhint.width, myhint.height,5, fg, bg);
Es wird ein Display mydpy erzeugt. Weiters muss ein Screen definiert werden, in dem das
Fenster geöffnet werden soll. Nachdem Farbe und Position bestimmt wurden, kann das
Fenster an der gewünschten stelle mit XCreateSimpleWindow() erzeugt werden.
Seite 14
3.3.2
Fenster schließen
Um das Fenster wieder zu schließen, muss der schon erwähnte XDestroyWindow(dp,win)
Befehl verwendet werden Die Parameter stehen dabei für das Display, in dem das Fenster
erzeugt wurde (dp) und das Fenster selbst (win).
3.3.3
Weitere Befehle
Weitere wichtige Befehle, um ein Fenster zu manipulieren sind folgende:
§
XMoveWindow(pd,win,x,y) dient dazu, das Fenster an die Stelle mit den
Koordinaten x und y zu setzen.
§
Mit dem Befehl XResizeWindow(dp,win,width,height) wird die Größe des
Fensters verändert.
3.4 Grafikfunktionen
Um freie Objekte mit Xlib zu erstellen, gibt es eine Vielfalt von Befehlen, die von einem
einfachen Punkt zu komplexen Polygonen reichen.
3.4.1
XDrawPoint
Mit XDrawPoint(dp,d,gc,x,y) wird ein einzelner Punkt an die Stelle x y im Display dp
gezeichnet. Die Variable gc beschreibt den Graphics Content und mit d wird eine drawable
Variable übergeben.
3.4.2
XDrawLine
Die Funktion XDrawLine(dp,d,gc,points,npoints,mode) dient dazu, eine Linie aus
einem Array von Punkten points zu erstellen. Die Variable npoints gibt die Anzahl der
Punkte im Array an.
3.4.3
XDraw
Mit XDraw(dp,d,gc,vlist,vcount) kann ein Polygon oder eine Kurve dargestellt
werden, die durch eine Liste von Vertex-Elementen bestimmt wird.
Seite 15
4 XFree86
4.1 Einführung
Unter XFree86 versteht man eine OpenSource-Version des X-Window-Systems, die auf
verschiedenen Betriebssystemen wie Unix, Linux, Open BSD, Windows NT (z.B. innerhalb
der Cygwin Umgebung) läuft.
Das XFree86 Projekt wurde 1991 von David Wexelblat, Glenn Lai, David Dawes und Jim
Tsillas ins Leben gerufen, um die Fehler im Quellcode von X11 X386 zu beheben. Anfangs
wurde es noch als X386 1.2e bezeichnet, als jedoch X386 nur noch kommerziell vertrieben
wurde, wurde das Projekt in XFree86 umbenannt und als Open Source verbreitet.
4.2 Lizenzstreitigkeiten und Abspaltung von XFree86
Ab der Version 4.4 von XFree86 wurde die Lizenz durch eine Werbungsklausel erweitert, wie
sie schon aus diversen FreeBSD Distributionen bekannt war. Durch diese Klausel kam es zu
Streitigkeiten unter den Entwicklern, da manche von ihnen behaupteten, dass XFree86 keine
freie Software mehr sei. Dies führte zum Ausschluss aus diversen Linux- und FreeBSDDistributionen. Benutzer von OpenBSD blieb bei der letzten Version, die unter der alten
Lizenz veröffentlicht wurde (V4.4 Release Candidate 2) und entwickelten diese selbstständig
fort.
Im Jahr 2003 wurde Keith Packard – ein anerkannter X-Window-Entwickler – unter dem
Vorwurf der Verschwörung, aus dem XFree86 Kernteam ausge schlossen. Er war unter den
Verdacht geraten, XFree86 spalten zu wollen. Da es sich um ein Open Source Projekt
handelte, arbeitete Packard weiter an XFree86 und versuchte Entwickler aus dem Projekt für
seine neue Version abzuwerben. Als diese Vorgänge jedoch bekannt wurden, musste sich
Packard vollkommen vom XFree86 Projekt zurückziehen.
Keith Packard begann danach mit freedesktop.org an einem völlig neuen Projekt namens
Xserver zu arbeiten, welches heute von diversen Quellen schon als nächste X-Server
Generation bezeichnet wird.
Seite 16
Das XFree86 Kernteam existierte, nachdem Packard gegangen war, noch bis zum 30
Dezember 2003. An diesem Tag wurde von den Entwicklern, die dem Kernteam angehörten,
beschlossen, sich wegen der stark gesunkenen Innovationskraft am nächsten Tag aufzulösen.
Sofort schlossen sich einige Entwickler mit der alten X.org Foundation zusammen und
schufen ein Open Source Projekt, um auch zukünftig eine freie Version eines X-Servers
gewährleisten zu können.
X.org schloss sich wiederum mit freedesktop.org zusammen und entwickelte einen X-Server
auf Basis von XFree86 Version 4.4 RC2. Im darauf folgenden Jahr, beschlossen große Linux
Distributionen wie Gentoo, Slackware oder Suse sich von XFree86 abzuwenden und auf den
neuen X-Server von freedesktop.org und X.org zu setzen. Dies brachte dem neuen Server
einen gewaltigen Schub an neuen Entwicklern. Neben diesem X-Server Projekt gibt es noch
eine zweite, auch auf XFree86 aufbauende Implementierung namens Xouvert, die aber fast
keine Anhänger findet.
4.3 Architektur
Die Kommunikation mit I/O-Geräten erfolgt mit Ausnahme der Grafikkarte über den
Betriebssystemkernel. Um die Grafikkarte anzusprechen wird der Kernel übergangen, was
über eigene von XFree86 erstellte Treiber geschieht.
Bis zur Version 4 von XFree86 hatte der X-Server ein monolithisches Design, was zu sehr
großen und unhandlichen Server-Binaries führte. Es ergab sich das Problem, dass bei der
Entwicklung neuer Treiber ein völlig neuer X-Server erstellt werden musste, obwohl sich nur
ein kleiner Teil des Codes änderte. [Steinmetz]
Ab der Version 4 von XFree86 wurde das Design geändert und eine modularisierte Struktur
erzeugt. Es entsteht eine strikte Trennung zwischen dem eigentlichen X-Server und Modulen,
die bei Bedarf geladen werden können. Durch diese Trennung muss nur noch der „kleine“ XServer an das bestehende System angepasst werden, was zu einer einfacheren Konfiguration
führt. Auch die Entwicklung von Treibern wird durch diese neue Architektur beschleunigt
und es ist sogar für kommerzielle Anbieter möglich Treiber oder Zusatzmodule zu erzeugen,
ohne den Sourcecode ihrer Module freigeben zu müssen. Das Laden der einzelnen Module ist
sowohl während des Programmstarts, als auch während der Laufzeit möglich, obwohl zweite
Möglichkeit eher selten eingesetzt wird.
Seite 17
4.3.1
Beispiel für das Laden von Modulen beim Programmstart:
Um ein Modul zu laden, werden von einem Parser aus der Datei die ausführbaren
Codefragmente gelesen und in den Speicherbereich des X-Servers geladen um ihn für den
Server verfügbar zu machen. Innerhalb des Moduls werden symbolische Adressen verwendet,
welche noch entsprechend aufgelöst werden müssen und dann in die Symboltabellen des
Loaders gespeichert werden. [Steinmetz]
Die Konfiguration erfolgt meist über die Datei /usr/X11R6/lib/X11/XF86Config oder
über diverse graphische Tools wie SaX. Um XFree86 ohne die Verwendung eines graphischen
Tools zu konfigurieren, ist es ratsam, sich zuerst die Datei XF86Config.eg anzusehen, die
eine Beispielkonfiguration enthält.
4.3.2
Aufbau der XF86Config Datei:
Die Datei ist in Abschnitte gegliedert, die immer mit folgenden Zeilen umgeben sind:
Section “section-name“
…
EndSection
In einer Section befinden sich logisch zusammengehörende Parameter, wie die benötigten
Dateien, Einstellungen für Monitor, Maus, Keyboard oder die Auflösung.
Beispiel für die Section Files:
Section "Files"
RgbPath
"/usr/X11R6/lib/X11/rgb"
FontPath
"/usr/X11R6/lib/X11/fonts/misc:unscaled"
FontPath
"/usr/X11R6/lib/X11/fonts/misc"
FontPath
"/usr/X11R6/lib/X11/fonts/75dpi:unscaled"
Seite 18
FontPath
"/usr/X11R6/lib/X11/fonts/75dpi"
EndSection
Diese Section beschreibt, wo sich die RGB-Farbtabelle von X11 befindet und auf welche
Schriftarten zugegriffen werden soll. Die Parameter für die einzelnen Hardwarekomponenten
werden meist in den Bedienungsanleitungen angegeben und können relativ leicht
übernommen werden. Die einzige Ausnahme bildet die Grafikkarte. Der X-Server selbst stellt
Methoden zur Verfügung, um die richtigen Daten über die Grafikkarte zu ermitteln. Mit dem
Befehl X –showconfig können die benötigten Werte angezeigt werden.
Beispiel für die Ausgabe von X –showconfig bei einer S3 Graphikkarte
XFree86 Version 3.3.2 / X Window System
(protocol Version 11, revision 0, vendor release 6000)
Operating System: Linux
Configured drivers:
S3: accelerated server for S3 graphics adaptors (Patchlevel 0)
mmio_928, s3_generic
Die Bezeichnung der Graphikkarte, die in der XF86Config-Datei eingetragen werden muss,
ist entweder mmio_928 oder s3_generic. Um nun herausfinden zu können, um welchen
Kartentyp es sich wirklich handelt, muss in der XF86_S3-Manual-Seite kontrolliert werden,
welche Karte welchen Chipsatz verwendet.
Weiters müssen noch weitere Parameter wie die Taktfrequenz und der Arbeitsspeicher
ermittelt und eingetragen werden. Nachdem die Konfigurationsdatei fertig erstellt wurde,
kann der X-Server mit dem befehl startx gestartet werden. [Kofler]
Seite 19
5 Integration eines Windowmanager
5.1 Was ist ein Windowmanager?
Durch die Client-Server Architektur von X werden alle Programme, die eine grafische
Benutzeroberfläche besitzen, als Clients auf dem X-Server ausgeführt. Genau wie alle
anderen grafischen Programme, ist auch der Windowmanager eine einfache Client
Anwendung. Es ist sogar möglich, Programme ohne den Windowmanager laufen zu lassen,
was jedoch den Nachteil hat, dass Änderungen der Fenstergröße oder das Schließen eines
Fensters nicht mehr komfortabel über einen Button erledigt werden können.
Neben einem gewissen Komfort, was die Bedienung der Programme angeht, wird auch das so
genannte Look&Feel des Arbeitsplatzes durch den Windowmanager gesteuert. So kann zum
Beispiel der Rahmen eines Fensters aus normalen Rechecken durch einen Rahmen im 3D Stil
ersetzt werden, und es können Schatten und dergleichen hinzugefügt werden. Diese Vorgänge
werden vom Windowmanager unabhängig von den anderen Applikationen durchgeführt.
Neuere Windowmanager wie Enlightenment verwenden sogar OpenGL-Funktionen um
„echte“ dreidimensionale Objekte darzustellen.
Historisch gesehen bauen alle Windowmanager auf die Programme wm und twm auf. Vor
allem der noch heute gängige fvwm ist ein direkter Nachfolger dieser Programme.
5.2 Bekannte Windowmanager
5.2.1
Gnome
Mit der Entwicklung des GNU Network Object Model Environment wurde 1997 begonnen,
um einen hundertprozentig freien Windowmanager zu schaffen. KDE wurde von vielen
Entwicklern als nicht freie Software angesehen, da es mit dem kommerziellen Tool Qt erstellt
wird.
1999 wurde Version 1.0 von Gnome veröffentlicht und im August 2000 wurde die Gnome
Foundation gegründet, der bekannte Firmen wie IBM, Sun und HP angehören, um Gnome zu
stärken.
Seite 20
5.2.2
KDE
Das K Desktop Environment ist neben Gnome einer der bekanntesten frei verfügbaren
Windowmanager. KDE kann unter Linux, Unix, BSD, und sogar unter Windows betrieben
werden.
Das Projekt wurde 1996 ins Leben gerufen und 1998 wurde KDE 1.0 der Weltöffentlichkeit
vorgestellt.
5.3 Installation und Konfiguration
Die Installation eines Windowmanager hängt vom jeweiligen Betriebssystem ab. Für
verschiedene Linux Distributionen wie RedHat, Suse oder Mandrake erfolgt die Installation
(für viele Windowmanager) automatisch über RPM-Installationsdateien.
Will man einen Windowmanager aber zum Beispiel unter Windows installieren, wird ein
Programm wie Cygwin benötigt, welches eine Unix- API und einen X-Server für Windows
Rechner bereitstellt.
Um den Windowmanager gleichzeitig mit dem X-Server zu starten, muss ein Verweis in die
Datei .xinitrc eingetragen werden, welche sich im Verzeichnis /home/username/
befindet. Wenn noch keine eigene .xinitrc-Datei definiert wurde, befindet sich die
default-Datei in /usr/lib/X11/xinit/xinit. Will man Änderungen vornehmen, ist zu
empfehlen, die Datei nicht direkt zu verändern, sondern eine Kopie im home Verzeichnis
anzulegen. Dabei darf aber nicht vergessen werden, dass die Datei im home Pfad des
Benutzers versteckt werden muss, also mit einem Punkt am Anfang versehen wird. Die Datei
.xinitrc
wird immer mit dem Befehl startx aufgerufen und beinhaltet die
Starteinstellungen für den Windowmanager. Es wird immer zuerst die Datei im Verzeichnis
des Benutzers gesucht und erst dann auf die default-Datei zurückgegriffen. In diese Datei
können neben Einstellungen wie Hintergrundfarbe und Schriftart auch beliebige Aufrufe für
Programme, die mit dem X-Server gestartet werden, eingetragen werden. Ebenso wird in
diese Programmaufrufe der Befehl zum Starten des Windowmanagers eingetragen, da dieser
wie schon in den vorherigen Kapiteln beschrieben wie jedes andere Programm vom X-Server
verwendet wird.
Seite 21
Zur Veranschaulichung:
# start some nice programs
clock &
# gimme time
xeyes &
# Watch my Mouse
xearth &
# what already that late???
xsetroot -solid Grey40
# give me a grey background
xterm -sb -sl 500 -j -ls -fn 10x20 &
# my favorite terminal
mwm
# my Windowmanager
[Kammann]
Der Windowmanager muss nicht das letzte aufgerufene Programm sein. Es ist nur wichtig,
dass sich das letzte Programm, das aufgerufen wird, nicht in einen eigenen von der Shell
“losgelösten” Hintergrundprozess verwandelt, da sonst der X-Server sofort wieder
geschlossen würde. Dies wäre zum Beispiel bei Programmen der Fall, die im Hintergrund
ausgeführt werden.
Die Shell kann immer nur eine einzige Anweisung ausführen und beginnt die nächste
Anweisung erst, sobald die vorherige abgeschlossen wurde. Um es nun zu ermöglichen,
weitere Programme beim Start des X-Servers auszuführen und nicht die Shell zu blockieren,
müssen diese Programme im Hintergrund laufen. Dies wird bewerkstelligt, indem der
Programmaufruf mit dem Parameter & versehen wird.
Würden in dem oben angeführten Beispiel die einzelnen Programmaufrufe nicht mit diesem
Parameter ausgeführt, müsste erst der Prozess clock beendet werden, bevor der Prozess
xeyes gestartet würde.
Seite 22
6 Ausgabefenster auf anderen Rechner senden
6.1 Einleitung
XFree86 und kommerzielle Implementierungen unterstützen gemäß den Prinzipien des XProtokolls das Darstellen eines Programmfensters auf einem anderen Rechner, der es dann
auch steuern kann. Dabei bietet im ein X-Server im Netz seine Darstellungs- und
Steuerungsfunktionalität an, und ein Client, also ein Programm, das die Xlib unterstützt,
verbindet sich auf den X-Server und stellt darauf seinen Output dar und nimmt die
Steuerungsdaten entgegen. Daher wird streng genommen kein Ausgabefenster auf einen
anderen Rechner gesendet, sondern eines von einem Berechnungsrechner empfangen.
6.2 Voraussetzungen
Auf der Server-Seite wird nicht zwingend ein Linuxrechner benötigt, weil mittlerweile auch
z.B. für Windows etliche Implementierungen des X-Protokolls zur Verfügung stehen
(Cygwin, X-Deep32, etc.).
Auf der Client-Seite läuft einfach ein Programm, das die Xlib unterstützt. Theoretisch ist es
egal, auf welchem Betriebssystem diese Applikation läuft, in der Praxis wird das aber mit
ziemlicher Sicherheit ein Unix-System sein. Wie schon erwähnt verbindet sich jeder X-Client
beim Start mit dem X-Server, der ihm in der Systemvariable $DISPLAY zugewiesen wird,
standardmäßig ist das der lokale. Hier ist anzumerken, dass sich Änderungen der Variable nur
auf zukünftige, nicht bestehende Verbindungen auswirken.
Man stößt aber auf Grenzen, wenn man Versucht, einen ganzen Desktop mit mehreren
Programmfenstern remote darzustellen; das wird vom X-Protokoll nicht direkt unterstützt,
man muss auf zusätzliche Software zurückgreifen.
6.3 Praktische Durchführung
6.3.1
Vorbereitung des Servers
Wie schon erwähnt muss der Rechner, der die Darstellung und Steuerung übernimmt, nicht
zwangsläufig ein Linux-/Unix-System sein. Mittlerweile kann auch ein Windows-Rechner
verwendet werden, da es ausgereifte X-Server gibt. In jedem Fall muss man den Rechner, der
Seite 23
eine Verbindung zum Server aufbauen soll, autorisieren. Unter Linux geschieht das mittels
des Befehls xhost.
gibt Informationen zur derzeitigen Berechtigungslage
xhost
aus
xhost +
berechtigt alle Computer, sich zu verbinden
xhost -
nimmt allen Computern die Berechtigung, sich zu
verbinden
xhost + 192.168.0.1
fügt
den
Rechner
mit
der
IP 192.168.0.1
der
Berechtigungsliste hinzu
xhost - 192.168.55.177
löscht den Rechner mit der IP 192.168.55.177 aus der
Berechtigungsliste
6.3.2
Vorbereitung des Clients:
Unter Linux ist es nötig, die Ausgabe auf den anderen Rechner, auf dem der X-Server läuft,
umzuleiten. Das geschieht, indem man die Systemvariable $DISPLAY dementsprechend setzt.
Bei manchen Programmen muss die Variable nicht geändert werden, es reicht auch ein Aufruf
nach dem Schema: xcalc –display 192.168.0.1:0.0 um hier z.B. das Programm
xcalc auf den X-Server auf 192.168.0.1 zu lenken.
Man startet eine neue Shell und gibt den Befehl DISPLAY=192.168.0.1:1.0 ein. Das
bewirkt, dass alle ab jetzt in der Shell gestarteten Programme sich auf das Display 1 auf
Screen 0 auf dem X-Server verbinden, der auf dem Rechner mit der IP 192.168.0.1 läuft.
Startet man jetzt ein Programm auf die gewohnte Weise, kann man es vom Server aus
bedienen. Wird die Shell nun beendet, gehen die Einstellungen verloren, sie sind nur
innerhalb der Sitzung gültig.
Sehr komfortabel ist es, eine SSH-Verbindung auf einen Rechner aufzubauen, um dort mit
dem Befehl xterm –display 192.168.0.1:0.0 eine Shell zu starten, die wieder auf
dem lokalen X-Server angezeigt wird. Auf dem lokalen X-Server sieht man dann die xtermSitzung, die gerade per SSH gestartet wurde. Alle in dieser xterm-Shell gestarteten
Anwendungen stellen sich nun auf dem lokalen X-Server dar.
Seite 24
Schritt 1:
Man startet eine neue Instanz eines X-Servers und berechtigt den gewünschten Client,
Verbindungen aufzubauen.
Schritt 2:
Mittels einer SSH-Shell verbindet man sich auf dem Remote-Host. Dort wird eine xterm-Shell
gestartet, die sich wieder auf den lokalen X-Server verbindet.
Seite 25
Schritt 3:
Starten eines beliebigen Windowmanagers und etwaiger Anwendungen.
7 Remote Desktop
7.1 Remote Framebuffer Protokoll
Das RFB ist ein einfaches Protokoll, das die Übertragung der Maus- und Tastaturereignisse
eines steuernden Clients und die Übertragung des Displayinhalts des gesteuerten Servers zum
Client definiert. Es baut auf TCP/IP auf und ist mehrbenutzerfähig. Grundsätzlich basiert es
auf folgenden Prinzipien:
7.1.1
Handshaking
Sobald die Verbindung zwischen Client und Server hergestellt wurde, tauschen sie die RFBProtokollversion aus, um sich auf einen für beide Seiten verständlichen Dialekt zu einigen.
Dann erfolgt die Authentifizierungsprozedur zur Anmeldung mit Passwort und die
eigentliche, zustandslose Verbindung beginnt.
7.1.2
Adaptive Updates
Nur, wenn es der Client verlangt und einen UpdateRequest absetzt, schickt der Server ein
Framebuffer-Update. Dieses enthält die Ausschnitte, die sich seit dem letzen Update geändert
Seite 26
haben. Dadurch richtet sich die Updategeschwindigkeit nach den Aktivitäten am Desktop,
nach der zur Verfügung stehenden Bandbreite des Netzes und der Geschwindigkeit des Client.
7.1.3
Rechteckige Updates
Der Displayinhalt wird nicht im Stück versendet. Es werden Rechtecke ausgeschnitten, deren
Inhalt und Position übertragen werden, um an der richtigen Stelle beim Client eingefügt zu
werden. Diese Framebuffer können nun einzeln unabhängig von einander komprimiert
werden. Es ist auch möglich, nur die neue Position eines rechteckigen Ausschnittes zu
übertragen, falls dieser dem Client schon bekannt ist, was zum Beispiel beim Drag&Drop –
also dem Ziehen von Objekten am Bildschirm – vorkommt. Wie mit den Pixeldaten des
Framebuffers verfahren wird, stellt das RFB-Protokoll aber frei.
7.2 Virtual Network Computing
Das ursprünglich von den AT&T Laboratories Cambridge entwickelte VNC implementiert
das RFB-Protokoll als VNC-Server und -Client. Es existieren frei verfügbare Versionen für
die unterschiedlichsten Plattformen wie Unix, Windows, MacOs und andere. Hier hebt sich
die Unix-Variante Xvnc besonders hervor, da sie gegenüber ihren Programmen als X-Server
auftritt, der die Darstellung auf einem virtuellen Bildschirm übernimmt, und als ein eigener
VNC-Server, der mit dem steuernden VNC-Client korrespondiert. Daher wird nicht das Bild
übertragen, das am Display angezeigt wird, sondern das eines virtuellen Desktops, der
zusätzlich zum angezeigten im Hintergrund läuft.
Seite 27
In der Praxis:
Will man Xvnc benutzen, um remote auf den Rechner zuzugreifen, ist es zuerst notwendig,
dem Server ein Display zuzuweisen. Dies geschieht, indem man das Wrapper-Script
vncserver
aufruft, gegebenenfalls mit den entsprechenden Parametern, wie der
Bildschirmauflösung oder der Farbtiefe. Nach der Eingabe von vncserver –geometry
800x600 –depth 34 :1 läuft der Server auf Display 1.
Möchte man sich nun von einem Client aus verbinden, ruft man seinen VNC-Viewer mit der
IP-Adresse des Servers auf, gefolgt von einem Doppelpunkt und der Displaynummer, in
unserem Fall 1. Wieder ist es nötig, nun manuell einen Windowmanager zu starten, um
komfortabel arbeiten zu können, falls dieser nicht schon läuft. Das virtuelle Display wird mit
dem Befehl vncserver –kill :1 wieder geschlossen.
7.3 KDE Desktop-Sharing
Auch KDE Desktop-Sharing ist ein VNC-Server für Linux, der es ermöglicht, den
Bildschirminhalt auf anderen Rechnern darzustellen. Der große Vorteil des ab Version 3.1 im
Lieferumfang von KDE enthaltenen Werkzeugs ist der, dass im Gegensatz zu seinem Pendant
Xvnc die laufende X-Session gesteuert wird und daher auch die Anzeige am Bildschirm der
am VNC-Client entspricht. Darüber hinaus ist Desktop-Sharing komplett in die Oberfläche
von KDE integriert und bietet dadurch größtmöglichen Komfort bei der Konfiguration und im
Einsatz.
Aktivierung unter KDE:
Man erreicht das Konfigurationswerkzeug des KDE Desktop-Sharing am besten im
Kontrollzentrum unter „Arbeitsplatz freigeben“. Der Zugriff ist schnell freigeschaltet, wenn
man uneingeladene Verbindungen zulässt und ein Passwort setzt. Blockiert die Firewall die
eingehende Verbindung nicht, so kann sich nun ein Client über das Netzwerk anmelden. Der
Aufruf lautet vncviewer
–shared
192.168.155.33:0. Um schon bestehende
Verbindungen zum nicht zu trennen, fügt man das Attribut shared hinzu.
Seite 28
Rückgekoppelte VNC-Verbindung
8 Mehrere X-Server auf einem Rechner
8.1 Motivation
Bei dem Thema mehrere X-Server auf einem System laufen zu lassen stellt sich zuerst die
Frage nach der Motivation. Warum sollte man auf einem System mehrere X-Server laufen
lassen?
Eine Begründung für mehrere X-Server ist die gleichzeitige Verwendung verschiedener
Windowmanager. Die kann notwendig sein, wenn bestimmte Programme einen bestimmten
Windowmanager benötigen um korrekt dargestellt zu werden. Eine andere Motivation besteht
darin, Ausgaben auf Verschiedene Monitore aufzuteilen.
KDE nutzt die Möglichkeit mehrere X-Server zu starten um es verschiedenen Benutzern zu
ermöglichen, gleichzeitig KDE zu verwenden, ohne sich gegenseitig auf irgendeine Weise zu
behindern. Sobald man unter KDE den Benutzer wechselt, erscheint automatisch ein Hinweis,
dass die aktuelle Sitzung nicht geschlossen wird und zusätzlich eine neue Sitzung mit einem
neuen X-Server gestartet wird.
Seite 29
8.2 Starten mehrerer X-Server
Es gibt verschiedene Möglichkeiten, einen neuen X-Server zu starten. Um einen neuen XServer für einen bereits angemeldeten Benutzer zu starten, kann direkt im Windowmanager
ein Konsolenfenster geöffnet werden und mit dem Befehl startx -- :1 ein zweiter XServer gestartet werden.
Für diesen neuen Server wird automatisch der default Windowma nager gestartet. Um einen
anderen WM zu verwenden kann muss dieser als Parameter angegeben werden.
§
startx startet den ersten Windowmanager (wird meist schon beim Systemstart
ausgeführt)
§
startx -- :1 startet den zweiten Windowmanager
§
startx twm -- :1 startet den Windowmanager TWM
Es können jedoch nicht alle Windowmanager parallel zu einem anderen gestartet werden. So
überprüft zum Beispiel Gnome, ob schon ein Windowmanager läuft. Falls Gnome als zweiter
Windowmanager gestartet werden sollte, liefert er eine Fehlermeldung und lässt sich nicht
ausführen.
Wie schon in den vorigen Kapiteln beschrieben, ist der Windowmanager ein Programm, das
auf dem X-Server läuft und nicht unbedingt benötigt wird. Der Windowmanager bietet
lediglich einige Hilfen um Programmfenster graphisch verändern zu können.
Neben dem X-Server, auf dem ein Windowmanager läuft, kann also auch ein zweiter Server
ohne WM gestartet werden. Dies ist mit dem Befehl xinit möglich, welcher die gleichen
Parameter benötigt, wie der Befehl startx.
§
xinit startet einen X-Server und legt ihn auf Display 0, wenn noch kein X-Server
läuft. Sonst wird eine Fehlermeldung ausgegeben.
§
xinit -- :1 öffnet einen neuen X-Server mit einem Terminal Window
Seite 30
Die graphische Ausgabe des X-Servers besteht lediglich aus einem grauen Hintergrund in
dem ein Terminalfenster geöffnet wird. Über dieses Terminal kann dann genau ein Programm
gestartet werden.
Wenn ein Programm gestartet wird, fällt sofort auf, dass dieses über keinen einen Rahmen
verfügt und dadurch auch nicht verschoben oder in der Größe verändert werden kann.
Sobald ein neuer X-Server gestartet wurde, wird automatisch auf die Konsole gewechselt, in
welcher der neue Server läuft. Der erste X-Server befindet sich immer auf der Konsole 7, die
in den meisten Linux Distributionen mit Strg+Alt+F7 angesprochen werden kann. Die
weiteren X-Server werden dann in den nächst höheren Konsolen geöffnet.
Neben der Möglichkeit einen neuen X-Server für den bereits angemeldeten Benutzer zu
erzeugen, kann auch ein weiterer Benutzer am System angemeldet und für diesen ein neuer XServer gestartet werden. Dazu muss man zuerst in eine Konsole wechseln und sich dort
einloggen.
Ein neuer Benutzer kann das auf den Konsolen 1 bis 6 tun. Wenn sich ein neuer Benutzer
anmeldet und schon für einen anderen Benutzer ein X-Server läuft, muss der neue Server auch
mit den oben genannten Parametern gestartet werden.
§
User 1 meldet sich am System an und startet einen X-Server mit startx.
§
User 2 meldet sich am System an und versucht einen X-Server mit startx zu starten.
Ausgabe:
§
Fatal Error: Server is already Runnig for display 0
§
User 2 muss den neuen X-Server mit dem Befehl startx -- :1 starten.
Seite 31
9 Résumé
Zusammenfassend kann gesagt werden, dass sich die X-Window-Technologie sicherlich
besonders dadurch auszeichnet, dass das Konzept der Modulkapselung und der Trennung der
Schichten wirklich konsequent durchgezogen wurde. Die sich dadurch ergebende Flexibilität
und Portabilität bleibt bis heute beispiellos.
Zukünftig kann sicherlich mit einer Ausdehnung des X-Konzepts auf immer mehr
unterschiedliche Plattformen gerechnet werden. Diese Entwicklung zeichnet sich jetzt schon
mit Produkten wie X-Deep32 oder Omni-X ab.
Seite 32
10 Quellen
[Linux Guide]
http://linuxguide.automatedshops.com/LinuxGuide/
[x.org]
http://www.x.org
[XFree86]
http://www.xfree86.org
[XFreeHowTo]
http://www.linuxhaven.de/dlhp/
HOWTO/DE-XFree86-HOWTO.html
[Kammann]
Rechenzentrum Universität Hamburg
http://www.informatik.uni-hamburg.de/RZ/software/X
[Kofler]
Michael Kofler „Linux Installation, Konfiguration und Anwendung“
7. Auflage
[X-Protocol]
O’Reilly - The Definitive Guides to the X-Windows System
X-Protocol Reference Manual 2nd Edition
[XWin]
O’Reilly - The Definitive Guides to the X-Windows System
X-Window System User’s Guide
[Scheifler Gettys]
R. Scheifler, J. Gettys – X-Window System 2nd Edition
[Linux Magazine]
https://www.linux- magazin.de/
Artikel/ausgabe/1997/08/Xfree/xfree.html
[Anheyer]
Diplomarbeit
http://www.tay-tec.de/diplom/node8.html
[Lueders]
Xgraphics, Martin Lueders
http://theorie.physik.uni- wuerzburg.de/~lueders/
Xgraphics/deutsch/node3.html
[Steinmetz]
Seminararbeit – Architektur und Modularisierung von X-Servern
Bettina Steinmetz
http://www.fh-wedel.de/~si/seminare/ws01/Ausarbeitung/4.xfree/
ArchitekturModularisierung.htm
[Bräuner]
NX - Turbolader für Linux- und Windows-Terminalserver
Vortrag auf dem Business- & Behördenkongress des LinuxTag 2004
Horst Bräuner, Kurt Pfeifle
Seite 33

X-Server Architektur

Transcription

Similar documents

Kommentar US-Recht auf Deutsch

Crash−Kurs Linux v3.9.1 © 1994−2000 Winfried Trümper

Einf ¨uhrung in C/C++

Einführung in C/C++ - alex