Hinweis: Der Artikel ist schon etwas älter, ich habe das Vorhaben bisher nicht fertig gestell, aber eventuell helfen die Angaben ja dem Ein oder Anderem

Bild: http://adlersa.yotaweb.de/gallery2/gallery2/d/6477-3/Bigdesktop.jpg?g2_GALLERYSID=33658476444b24a4cf10b9eac3d4ead9Ja, ich geb ja zu, ich bin Monitorsüchtig. Normal arbeiten hier zwei 19″er an einer NVidia-Karte per TwinView, für noch mehr Übersicht muss von Zeit zu Zeit mein Laptop herhalten. Hierbei wird auf dem Hauptrechner ein virtueller Monitor emuliert und dessen Inhalt per Ethernet auf den zweiten Rechner verfrachtet. Ein ähnliches Setup hatte ich bereits zu meinen Windows-Zeiten mit MaxiVista. Unter Linux muss ich mich natürlich etwas Neues suchen – das Zauberwort heißt Xdmx. Dieser X-Server kann mehrer andere X-Server zusammenfassen. Oder wie es die Wiki schimpft: „It acts as a proxy X Window server for multiple back-end X servers.“

Gentoo-User haben es hier einfach – Xorg (x11-base/xorg-server) hat dmx als USE-Flag – einmal setzen und schon werden alle Tools und Libs emerged. Unter Debian müsste das passende Paket xdmx-tools heißen. Zusätzlich ist Xnest zum Testen ein praktischer helfer – Gentoo-XOrg hats dabei, Debian-User sollten ein gleichnamiges Paket finden. Hiermit lassen sich virtuelle X-Server in einer laufenden Sitzung starten – ähnlich wie VNC.

Für den ersten Test werden auf dem Master zwei Xnester gestartet:

XSESSION="xterm" startx -- /usr/bin/Xnest :1 -geometry 640x480+0+0 -name Test1
XSESSION="xterm" startx -- /usr/bin/Xnest :2 -geometry 640x480+0+0 -name Test2

Ich nutze hier startx, da ich so in den Testservern ein Terminal erhalte und die Zugriffsrechte korrekt gesetzt werden. Danach kann der Xdmx gestartet werden:

Xdmx :9 -display :1 -display :2 -query localhost

Die beiden display-Angaben verweisen auf die virtuellen X-Server. Das Query stellt eine Anfrage an den Loginmanager – ist dieser auf Remoteverbindungen eingerichtet zeigt sich auf den ersten Testfenster die Loginmaske. Ich hatte in dem virtuellen X einige Tastaturprobleme, da aber auf #2 das Terminal verschwand und im Xdmx beide Screens aufgeführt waren lasse ich den Test mal als erfolgreich durchgehen.

Weiter zu den echten Screens: Zuerst benötigt der Hauptrechner Zugriff auf meinen Laptop – dazu wird auf dem Zweitgerät per "xhost +192.168.x.y die entsprechende IP freigeschaltet. Zum test kann man mit DISPLAY="laptop:0" xterm (laptop=IP oder DNS) ein Fenster auf dem Slave starten. Funktioniert das kann Xdmx den Dienst antreten:

Xdmx :9 -display :0 -display laptop:0 +xinerama -query localhost

Das ganze lässt sich dann noch in entsprechende Startscripte verpacken. Beendet werden kann Xdmx mit Strg+Alt+Backspace

Info am Rande: Es soll auch eine zweite Software geben, welche als OpenGL-Proxy dient, damit könnte eine einfache 3D-Beschleunigung möglich sein.

Noch ein paar Infos:

TwinView (NVidia) wird als ein großer Bildschirm erkannt

Statt TwinView 2 separate X-Screens einstellen. Geht z.B. über das NVidia-GUI

Gnome startet nicht/Macht Probleme/etc

Gnome kann pro Rechner und User nur 1x gestartet werden. Am besten mit einem anderen User oder einem anderen Windowmanager Xdmx starten

Tastaturlayout

-param XkbModel pc104 -param XkbLayout de -param XkbVariant nodeadkeys

Im Falle von Gnome unter System->Einstellungen->Tastatur entsprechend anpassen.

Probleme mit Schriftarten

Mittels -fontpath kann man die entsprechenden Pfade angeben. Fuer mein Gentoo z.B.

-fontpath /usr/share/fonts/local -fontpath /usr/share/fonts/misc -fontpath /usr/share/fonts/Type1 -fontpath /usr/share/fonts/TTF -fontpath /usr/share/fonts/75dpi -fontpath /usr/share/fonts/100dpi

Darstellungsprobleme

Folgende Optionen schalten einige Optimierungen ab – am besten selbst probieren was hilft. In meinem Fall reichte der noglxproxy um die meisten Programmfehler zu beheben und Videoplayer ans laufen zu bekommen:

-ignorebadfontpaths -noglxproxy -norender -nosubdivprims -nowindowopt -nooffscreenopt

Weitere Infos:

Ein Rechner, ein User – so oder so ähnlich dürften die meisten PC-Setups aussehen. Während in Firmennetzen mit Terminalservern wieder eine Rückbesinnung auf die Mainframe/Terminal-Architektur Einzug gefunden hat sind solche Ansätze bei einzelnen PCs eher weniger verbreitet. Keine Verbreitung heißt aber nicht, dass so etwas unmöglich ist. Vor einigen Jahren berichtete bereits die c’t über diese Möglichkeiten, aus Mangel an Interesse überflog ich die Seiten aber nur grob.

Zwischenzeitlich hat sich dann doch eine Idee ergeben, mein Server sollte dran glauben – mit Onboard Cirrus-Karte und einer Radeon PCI ging es in den Test. TFT+Touchscreen starten eine X-Sitzung mit meinem Frontend, die Cirrus-Karte darf unterdessen mit Tastatur und Maus die zweite Bedieneinheit bilden und sich mit xterm & co rumschlagen.

Erster Blick auf die Dokus: Kernel über 2.4.irgendwas sollte passen, mehrere Grafikkarten ebenfalls und ein X.org über 6.9 sollte ebenfalls keine Hürde darstellen. Durch meine Basteleien mit (X)DMX (ops, ich seh grade die Doku hab ich nie veröffentlicht) ist mir noch so einiges aus der xorg.conf im Kopf, daher kein wirkliches Problem eine passende Grundconfig zu schreiben, die Anpassungen für Multiseat liefert die Gentoo-Wiki.

Der erste Teststart mit beiden Monitoren brauch ein paar Minuten – die I2C-Verbindung für DDC ist über 20m Monitorkabel wohl nicht gerade zuverlässig. Trotzdem starteten beide Monitore zufriedenstellend. Als nächstes der Start mit einzelnen Monitoren, leider nicht ganz so erfolgreich – jeder für sich startet problemlos, simultan jedoch kommt die Radeon aus dem Tritt und verabschiedet sich bis zum nächsten Reboot (genauer: Es werden falsche Monitorfrequenzen berechnet – laut Log soll die Radeon plötzlich irgendwas zwischen -32000000MHz und 32000000MHz unterstützen). Auch der versuch die PCI-Isolierung über die X-Argumente zu regeln brachte leider keinen Erfolg. Scheint, als ob ich bei Multihead bleiben muss, auch wenn dadurch beide Monitore nicht komplett unabhängig betrieben werden können.

…denn einige der üblichen Linux-Optimierungen können schnell nach hinten los gehen: Den Anfang machte das Spiel Enemy Territory, welches ich mal wieder aus der Versenkung gefischt habe. Alles funktioniert prima, versucht man jedoch einem Spiel beizutreten landete man wieder auf dem Desktop – eine Datei würde fehlen. Hm – OK, auf den Spielordner unter /opt hat die Gruppe games, welcher der User auch angehört, die nötigen Rechte und auch die Datei findet sich dort. Sollte also funktionieren – eigentlich, denn ich habe nicht mit den Mods gerechnet. In meinem aktuellen Fall war „JayMod“ der Auslöser – diese Mod installiert eine neue Version der Datei ins Mod-Verzeichnis unterhalb von ~/.etwolf/ – nicht sehr passend, wenn man, wie in diversen Anleitungen empfohlen, sein /home auf einer eigenen Partition eingerichtet und mit der option noexec gemountet hat. Hier hilft dann nur ein remount mit exec oder das Umbiegen der ET-Verzeichnisse auf eine andere Partition.

Der zweite Fehler hat mich etwas länger auf Trab gehalten – mein Laptop dient nebenbei als Testgelände für kommende Gentoo-Pakete, daher ist hier ~x86 (aka testing) installiert. Soweit kein Problem, die meisten Probleme mit den Abhängigkeiten lösen sich recht schnell, aber seit einiger Zeit machen einige Pakete, welche revdep-rebuild eingebracht hat, größere Probleme. So brachen z.B. subversion, totem und avidemux wärend des Kompilierens ab – gcc verstand plötzlich seine eigenen include-files nicht mehr. Gcc neu kompiliert, mit gcc-profilen gespielt, aber das alles ist natürlich relativ zwecklos, wenn man am falschen Ort sucht. Die Meldung kam nicht von meinem Laptop, durch einen vorherigen Versuch war noch distcc aktiv und die 4.1er GCCs auf den anderen Rechner können mit den Dateien des 4.2er natürlich nicht viel anfangen.

OK, mit PHP kann man vom simplen Gästebuch bis hin zum Gerätetreiber einiges hin bekommen, aber für kleinere Tools möchte man nicht immer den PHP-Interpreter in den Arbeitsspeicher jagen. Praktisch, dass Bash & Co schon recht mächtige Werkzeuge mitbringen. Wenn dann ein Bekannter nach einer kleinen Verwaltungsoberfläche für Subversion-Repositorys schreibt kann man seinen Rechner ja mal als Testobjekt verwerten. OK, der Code ist vermutlich schrecklich, dürfte nur auf Gentoo laufen und auch sonst noch weit von einer Produktivversion entfernt sein, aber immerhin startet das ganze und löscht mir inziwschen auch nicht mehr die ganze Platte vor der Nase weg (gut, dass es Snapshots gibt). Wer was zum lachen brauch kann sich gerne den Code vornehmen: [HTML] [Download]

–Update–
Eine verbesserte Version, jedoch ohne Dialog, findet sich in der Gentoo-Wiki.

Dass neue Versionen nicht immer so funktionieren, wie man es möchte ist ja nichts neues, aber der 2.6.23er Kernel hat dieses mal so richtig zugeschlagen: Die Umstellung der VESA-Framebuffer lässt bei mir nicht mehr als 640×480 Bildpunkte zu, die Zaptel ISDN-Treiber scheinen ebenfalls nicht mit der neuen Version zu harmonieren und für mich das Killerargument: Der ARK3116 USB-Converter-Treiber lässt bei jedem Zugriff alle meine Systeme abstürzen. Naja, der AKR-Treiber ist als experimental markiert und die Zaptel-Treiber sind nicht offiziell im Kernel aber zumindest zum VESA-Framebuffer hätte ich mir eine besere Doku gewünscht, denn in den Kernel-Sources scheinen immernoch die alten zu sein.