![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Zum Kapitel 10 - Systemverwaltung] [Zum Kapitel 12 - Hardware- und Plattformspezifische Fragen]
X wird als »Client-Server«-strukturiertes Protokoll aufgefasst, obwohl die Terminologie manchmal etwas verwirrend ist. Der Computer, der die Grafik auf dem Bildschirm anzeigt, ist der »X-Server«. Die Anwendung, die dem X-Server mitteilt, was auf dem Bildschirm angezeigt werden soll, ist der »X-Client«, selbst wenn es sich hierbei um einen leistungsstärkeren Computer in einem Rechenzentrums handelt. Dieses Modell kann genutzt werden, um rechenintensive Anwendungen (X-Clients) auf sehr leistungsstarken Maschinen auszuführen, die den X-Server als Benutzerschnittstelle verwenden, der auf einer kleinen und stromsparenden Maschine auf deinem Schreibtisch läuft.
Es ist möglich, X-Clients auf einem System auszuführen, das über keine grafische Ausgabemöglichkeit verfügt. Man könnte zum Beispiel eine Anwendung (den X-Client) auf einer mvme88k ausführen und die Ausgabe auf einem Bildschirm einer Alpha anzeigen lassen (der X-Server). Da X ein klar definiertes und plattformübergreifendes Protokoll ist, ist es sogar möglich, eine X-Anwendungen auf einer (beispielsweise) Solaris-Maschine auszuführen und auf einer OpenBSD-Maschine anzeigen zu lassen.
Der Client und der Server können auch auf dem gleichen System laufen. Im Rest dieses Kapitels gehen wir hiervon aus.
Soweit zur Grundlage. X wird normalerweise gestartet, um X-Anwendungen aufrufen zu können. Einige X-Applikationen sind sehr genügsam, andere scheinen sich hingegen alle Rechenleistung und verfügbaren RAM unter den Nagel zu reißen. Selbstverständlich gibt es auch Leute, die X verwenden, um eine große Anzahl xterm(1)s aufzurufen - hierfür reicht auch sehr schlichte Hardware.
Die Details der manuellen Konfiguration von X unterscheidet sich deutlich zwischen den einzelnen Plattformen. In allen Fällen gibt es aber Anleitungen und andere plattformspezifische Informationen in /usr/X11R6/README, die auf einem installierten System vorgefunden werden kann.
Viele Plattformen benötigen den X-Aperturetreiber xf86(4), der direkten Zugriff auf den Speicher und die Ein-/Ausgabeports des VGA-Boards und der PCI-Konfigurationsregister ermöglicht, was für die X-Server eine Voraussetzung ist. Dieser Treiber muss aktiviert werden, bevor er genutzt werden kann - entweder indem mit »Yes« auf die Frage
geantwortet wird (diese ist während der Installation zu sehen) oder indem man machdep.allowaperture in der /etc/sysctl.conf auf einen der Plattform entsprechenden Wert setzt (dieser darf nicht 0 sein) und neustartet, da diese Sysctl aus Sicherheitsgründen nach dem Bootvorgang nicht mehr geändert werden kann. Die Verwendung des Treibers zieht Sicherheitsbedenken nach sich. Du solltest ihn nicht aktivieren, wenn du nicht unbedingt auf ihn angewiesen bist.Do you expect to run the X window System [no]
Setze machdep.allowaperture=1 in /etc/sysctl.conf.
Die TGA- und einige VGA-Karten werden unterstützt. Es sollte keine weitere Konfiguration notwendig sein.
Setze machdep.allowaperture=2 in /etc/sysctl.conf.
Für die überwiegende Mehrheit von Benutzern wird X auf amd64 erfolgreich automatisch konfiguriert, sodass keinerlei weitere Konfiguration nötig ist. WENN eine weiterführende Konfiguration nötig ist, benutze X -configure wie weiter unten beschrieben.
Setze machdep.allowaperture=2 in /etc/sysctl.conf.
Für die überwiegende Mehrheit von Benutzern wird X auf i3864 erfolgreich automatisch konfiguriert, sodass keinerlei weitere Konfiguration nötig ist. WENN eine weiterführende Konfiguration nötig ist, benutze X -configure wie weiter unten beschrieben.
Setze machdep.allowaperture=2 in /etc/sysctl.conf.
Unterstützte Macintosh-PPC-Systeme können auf zwei unterschiedliche Weisen verwendet werden: »beschleunigt« oder »Framebuffer« (unbeschleunigt).
Im »Framebuffer«-Modus wird das System mit 8 Bits pro Pixel arbeiten und die Videoauflösung wird von der Macintosh-Umgebung geregelt. Das bedeutet, dass du eine kleine MacOS-Partition auf deiner Platte belassen möchtest, um von dort aus diese Einstellungen anzupassen. Dieser Modus hat den Vorteil, dass er »einfach funktioniert«, doch kann es frustrierend einschränkend sein (zum Beispiel setzt eine Änderung der Auflösung einen Boot von MacOS voraus).
Wenn dein Macintosh ein ATI-basiertes Videosystem hat, kannst du es mit einem beschleunigten X-Server verwenden. Dieser liefert bessere Geschwindigkeiten und mehr Kontrolle in deiner OpenBSD-Umgebung. Die NVIDIA-Grafikkarten einiger macppc-Systeme werden auch in vielen Fällen funktionieren. Die Datei README hat Details über die Konfiguration beschleunigter Treiber, starte daher mit der dort gezeigten Beispieldatei.
Während die README-Datei detailliert auf die Verwendung der Standardmaus von Apple mit nur einer Taste unter X eingeht, wird dir dringend dazu geraten, dir einfach eine USB-Maus eines Drittanbieters mit drei oder mehr Knöpfen zu kaufen - es sei denn, du verwendest einen Laptop.
HorizSync 60.0 - 60.0
VertRefresh 43.0 - 117.0
Mit nur einem unterstützten Framebuffer wird keine Konfiguration benötigt. Wenn du eine Multihead-Konfiguration verwenden möchtest, wirf einen Blick auf die zuvor genannte README-Datei für weitere Details.
Die Auflösung wird von der Firmware eingestellt, bevor OpenBSD bootet.
Die meisten einfachen Konfigurationen »laufen einfach«. Tut es deine nicht, oder solltest du wünschen raffiniert zu werden, lies die oben angeführte README-Datei.
Der X-Server funktioniert momentan nur auf VAXstation-4000-Modellen mit einem lcg(4)- oder lcspx(4)-Framebuffer.
Es wird keine Konfiguration benötigt, X »funktioniert einfach«.
Funktioniert X nicht wie gewünscht auf einem System, so muss man eine Konfigurationsdatei erzeugen. Ein guter Startpunkt (und manchmal bereits das Ziel!) ist das Ausführen von Xorg(1) im Modus »X -configure«. Letzterer wird alle verfügbaren Grafikkartentreiber laden, andere Hardware austesten, und, basierend auf dem, was vorgefunden wurde, eine Datei xorg.conf schreiben, die funktionieren kann, aber nicht muss. Selbst wenn sie nicht funktionieren sollte, wird sie immer noch als nützliche Grundlage für eine dienen, die funktioniert wie gewünscht.
Eine altehrwürdige Methode zur Konfiguration von X ist die Benutzung deiner favorisierten Suchmaschine, um nach jemanden zu suchen, der dein Problem bereits für dich gelöst hat. Ebenfalls bemerkenswert ist, dass die xorg.conf-Dateien anderer UNIX-ähnlicher Betriebssysteme oft nützliche Tipps darüber enthalten, was letztendlich benötigt wird, um X auf ähnlicher Hardware zum Laufen zu bringen. Obwohl dies kein schlechter Weg ist, wird auf diese Methode hier nicht näher eingegangen.
Dies war einmal eine Highend-Grafikkarte mit 16 MB RAM, doch wird sie heutzutage von »gängigen« Betriebssystemen fast nicht mehr unterstützt. Des Weiteren wird ein Sony Multiscan G400 19" CRT als Monitor angeschlossen. Es wäre schön, wenn dieser Monitor bei einer Auflösung von 1280x1024, einer angenehmen Bildwiederholrate und 24 Bit Farbtiefe genutzt werden kann.vga1 at pci1 dev 0 function 0 "3DFX Interactive Banshee" rev 0x03
Nachdem OpenBSD mit X installiert wurde (wir haben sichergestellt, dass der Aperturetreiber im Kernel aktiviert wurde) werfen wir zuerst einen Blick auf die automatische Erkennung und Konfiguration von X.Org - vielleicht haben wir Glück. So, wir loggen uns einfach ein und rufen startx(1) auf. Der Bildschirm wird für ein paar Momente schwarz, dann erhalten wir den »Schachbrett«-Hintergrund von X, den »X«-Cursor und ein xterm-Fenster.
Es funktioniert!
Mehr oder weniger. Obwohl das System voll einsatzfähig ist, scheint es keine Funktionalitäten des Monitors erkannt zu haben und läuft auf einer eindeutig zu niedrigen Auflösung (640x480). Wir hoffen mal, dass wird das noch besser hinbekommen - damit meine ich sehr viel besser. Das heißt also, dass wir unsere eigene xorg.conf-Datei erstellen müssen.
Wir verwenden die »X -configure«-Methode, um eine Grundlage für unsere xorg.conf-Datei zu schaffen. Du musst folgenden Befehl als root ausführen:
Im Übrigen muss die Meldung ernst genommen werden - verwende den vollständigen Pfad zu deiner xorg.conf.new-Datei, selbst wenn du dich im gleichen Verzeichnis befindest. Dies nicht zu tun führt dazu, dass X(7) die Datei nicht findet, und ohne weitere Meldung die Standardkonfiguration benutzen; und wenn diese funktioniert hätte, dann hättest du diesen Vorgang ja nicht durchgeführt! Es kann die Fehlersuche deutlich vereinfachen. Vertraue uns in diesem Punkt.# X -configure [...] Your xorg.conf file is /root/xorg.conf.new To test the server, run 'X -config /root/xorg.conf.new'
Wir führen also aus, was uns gesagt wird:
Alles was wir kriegen ist ein schwarzes Bild. Dabei hat es so gut angefangen ...# X -config /root/xorg.conf.new
Nun ist ein guter Zeitpunkt gekommen, um über die unterschiedlichen Möglichkeiten zu sprechen, X zu beenden, wenn es auf diese Weise gestartet wurde. Nach Vorzug sortiert sind es:
An dieser Stelle kommt unser Wissen über die Hardware ins Spiel. Wenn wir das System an einen anderen Monitor anschließen, während ein schwarzes Bild angezeigt wird, gibt er uns eine »Sync. out of Range«-Meldung auf dem Bildschirm aus. Offensichtlich scheint die Konfiguration von X nicht mit diesem Monitor zu funktionieren. Eventuell läuft diese Konfiguration auf KEINEM Monitor, wenn ein Videomodus ausgewählt wurde, der mit der Karte nicht zusammen funktioniert (beachte bitte, dass X sich am Chip auf der Karte und dessen Leistung orientiert - nicht daran, wie der Hersteller die Komponenten zusammengestellt hat). Unterschiedliche Monitore werden verschieden reagieren, wenn die Rate falsch ist. Einige werden versuchen, das Bild anzuzeigen, andere werden in den Energiesparmodus wechsel, andere schreckliche Geräusche von sich geben und wieder andere werden hilfreiche Meldungen auf dem Bildschirm angeben. Dieser Bildschirm scheint zu keiner der zuvor genannten Arten gehören. Wir merken uns einfach, diesen Monitor NIE wieder für grundlegende X-Konfigurationen zu verwenden.
Während wir durch die erstellte xorg.conf.new-Datei gehen, sehen wir folgenden Eintrag:
Section "Monitor"
#DisplaySize 370 270 # mm
Identifier "Monitor0"
VendorName "SNY"
ModelName "SONY CPD-G400"
### Comment all HorizSync and VertSync values to use DDC:
HorizSync 30.0 - 107.0
VertRefresh 48.0 - 120.0
Option "DPMS"
EndSection
Wir werden nun versuchen, Xorg auf eine bestimmte Auflösung zu trimmen und zu sehen, ob wir damit Glück haben. In Section "Screen" der xorg.conf-Datei werden wir ein paar Zeilen hinzufügen, die hier fett gedruckt sind:
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x1024"
EndSubSection
EndSection
Wir testen die neue Konfiguration und ... ERFOLG! Wir scheinen ein schönes und hoch auflösendes Display zu besitzen. Beachte, dass wir NUR ein Schachbrettmuster (das sehr gut geeignet ist, um die Qualität deines Bildschirms zu prüfen und um LCDs zu kalibrieren [»root weave«]) und einen beweglichen Cursor erwarten. An diesem Punkt erwarten wir noch keine voll einsatzfähige Oberfläche.
Nun werden wir die xorg.conf-Datei installieren, sodass wir den alltäglichen Aufruf von X testen können.
Wir können nun versuchen, X mit dem normalen startx(1)-Kommando zu starten. Es funktioniert!# cp xorg.conf.new /etc/X11/xorg.conf
Es wäre auch nicht schlecht, zu überprüfen, ob es sich wirklich um die Auflösung und Farbtiefe handelt, die wir angestrebt haben. Das ganze soll selbstverständlich auch mit einer angenehmen Bildwiederholrate angezeigt werden. Wir können dies mit den Kommandos xrandr(1) und xdpyinfo(1) überprüfen. Neben anderen Informationen liefert xdpyinfo(1):
[...]
screen #0:
print screen: no
dimensions: 1280x1024 pixels (433x347 millimeters)
resolution: 75x75 dots per inch
depths (7): 24, 1, 4, 8, 15, 16, 32
root window id: 0x44
depth of root window: 24 planes
[...]
Folgende Ausgabe liefert xrandr(4):
SZ: Pixels Physical Refresh
*0 1280 x 1024 ( 433mm x 347mm ) *85 75 60
1 1280 x 960 ( 433mm x 347mm ) 85 60
[...]
Auf einigen Plattformen musst du das für die Konsolen zuständige getty(8) deaktivieren, um xdm(1) starten zu können.
Der Standard-Fensterverwalter von OpenBSD ist fvwm(1). fvwm ist ein guter Allzweck-Fensterverwalter, aber keineswegs deine einzige Auswahl; es ist noch nicht einmal der einzige Fensterverwalter, der standardmäßig in OpenBSD vorhanden ist (siehe cwm(1) und twm(1)). Eine große Auswahl an Fensterverwaltern ist außerdem als Paket verfügbar.
Ähnlich den Systemstart-Skripts folgt X einem definierten Ablaufplan, um die Benutzerumgebung einzurichten. Genauer gesagt existieren mehrere solche Startprozedere; welchem gefolgt wird, hängt davon ab, wie X gestartet wird. Zu verstehen, wie X startet, wird dir helfen zu verstehen, wie deine Arbeitsumgebung exakt so anzupassen ist, dass es deinen Wünschen entspricht.
Man kann die Umgebung sowohl auf System-, als auch auf Benutzerebene anpassen. Es ist vielleicht besser, Änderungen auf Benutzer-, als auf Systemebene durchzuführen, da die Benutzerskripte in dem Heimatverzeichnis des Benutzers gespeichert werden, sodass weniger Dateien vereinigt werden müssen, wenn du dein OpenBSD auf eine neue Version nachrüstest (»upgrade«). Die systemweit gültigen Standards befinden sich in /etc/X11 und werden ursprünglich von dem xetcXX.tgz Dateiset installiert, welches von dem vorgeschlagenen Nachrüstprozedere nicht erfaßt wird, d. h. werden Änderungen an den systemweiten Daten vorgenommen, so werden diese zwar bestehen, jedoch wird es eventuell nötig sein, diese Änderungen manuell in spätere Versionen der entsprechenden Dateien einfließen zu lassen.
Im einfachsten Fall braucht es aus nicht mehr als dem Namen des gewünschten Fensterverwalters zu bestehen, der ausgeführt werden soll:
Oder man kann ein wenig ausgefallener sein:cwm
Dies startet die xconsole(1), die eine Kopie ein jeden Texts zeigt, den der Kernel auf die Konsole geschrieben hätte (die jetzt ja von einem grafischen Bildschirm eingenommen wird), eine analoge Uhr, oclock(1), und konfiguriert den Hintergrund zu einer geschlossenen grauen Fläche mit Hilfe von xsetroot(1), und dies alles bevor der cwm(1) Fensterverwalter gestartet wird. Beachte, wie einzig der Fensterverwalter nicht durch das Anhängen eines »&«-Zeichens »in den Hintergrund geschickt wird«. Dies bedeutet, das X solange laufen wird, bis cwm(1) beendet wird.xconsole -geometry -0+0 -fn 5x7 & oclock -geometry 75x75-0-0 & xsetroot -solid grey & cwm
Besitzt das Heimatverzeichnis eines Benutzers keine Datei .xinitrc, so wird die des Systems, /etc/X11/xinit/xinitrc, benutzt. Diese Datei kann dich mit einigen zusätzlichen Ideen für deinen eigenen .xinitrc-Skript versorgen.
xdm(1) besitzt viel mehr Funktionalität als hier besprochen wird, aber für unsere Zwecke gilt, dass xdm dem Benutzer einen Anmeldebildschirm präsentieren wird, den Namen und das Passwort eines Benutzers abfragen und verifizieren wird, um letztlich dem Benutzer seine X-Umgebung zur Verfügung zu stellen. Beendet sich X, entweder absichtlich oder aus Versehen, so wird xdm es erneut starten. Dies ist der Grund, warum man sicherstellen sollte, dass X korrekt konfiguriert ist, bevor man xdm(1) benutzt, und in jedem Fall bevor xdm(1) beim Systemstart gestartet wird, das es ansonsten schwierig werden könnte, die Kontrolle über die Maschine zu erlangen.
Wenn xdm(1) startet, führt es /etc/X11/xdm/Xsession aus; dies wiederum wird versuchen, eine Datei .xsession in dem Heimatverzeichnis des Benutzers zu finden. D. h., wünschst du die Änderung deines standardmäßigen Fensterverwalters, führe ihn (und möglicherweise andere Sachen) in .xsession aus. Wieder gilt, dass alle Programme, die mit X gestartet werden sollen (zum Beispiel drei xterm(1)s), hier platziert werden müssen, dass alle im Hintergrund auszuführen sind, ausgenommen des Fensterverwalters, der, wie zuvor, wenn beendet, die X-Sitzung ebenfalls beendet. In letzterem Fall wird xdm(1) X erneut starten und einen Anmeldebildschirm präsentieren.
Verschiedene Fensterverwalter (einschließlich cwm(1) und fvwm(1)) bieten die Möglichkeit der Änderung des Fensterverwalters vom Fleck weg, ohne das X oder eine andere Anwendung neu gestartet werden müssen. Der neue Fensterverwalter ersetzt den alten; das Beenden des neu gestarteten Fensterverwalters beendet X, und führt nicht zum Vorherigen zurück. fvwm(1) erlaubt das Starten eines anderen Fensterverwalters durch einen Linksklick auf den Hintergrund (»root window«), der Auswahl von »(Re)Start« und dann des gewünschten Fensterverwalters (es ist allerdings anzumerken, dass dafür die alternativen Fensterverwalter in der .fvwmrc-Datei des Benutzers angeführt sein müssen [die systemweiten Standards sind in /usr/X11R6/lib/X11/fvwm/.fvwmrc]). cwm(1) erlaubt das Ausführen eines anderen Fenstermanagers durch Nutzung der Tastenkombination Ctrl-Alt-w (Steuerungstaste-Meta-w), und Eingabe des Verwalters, zu dem gewechselt werden soll.$ startx /usr/local/bin/fluxbox
Sobald du den Fensterverwalter gefunden hast, den du magst, kannst du ihn als zuletzt auszuführendes Programm in deine Startskripte schreiben, wie oben beschrieben.
[FAQ-Index] [Zum Kapitel 10 - Systemverwaltung] [Zum Kapitel 12 - Hardware- und Plattformspezifische Fragen]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org