erforderliche Kenntnisse: Umgang mit der Konsole, Bearbeiten von Konfigurationsdateien, einfache Bash-Skripte erstellen, Anwendungen aus Paketquellen installieren.
Mit dem Raspi lässt sich ja so einiges anstellen – ich nutze einen auf dem Schreibtisch als Desktop-Ersatz, denn mit dem geringen Stromverbrauch ist er zum Mails abholen und surfen im Web durchaus eine Alternative. Daneben läuft er als quasi als ThinClient, um eine RDP-Session einer VM auf dem Homeserver auf den Schreibtisch zu holen.
Aus meinem Nutzungsverhalten entstand auch der Wunsch einen zweiten Bildschirm am Raspi zu betreiben, um dort parallel eine Webseite (z.B. WhatsApp) offen und vor allem im Blick zu haben.
Ich hatte vor einiger Zeit schon mal im Netz gesucht und viele erfolglose Geschichten gelesen. Ein Arbeitskollege kaufte sich kürzlich USB2VGA-Adapter von DisplayLink und brachte diese unter Windows 10 zum laufen. Dank Google fand ich heraus, dass RaspbianJessie mittlerweile DisplayLink unterstützt, also in die Bucht und Hardware besorgt.
Erster Kontakt mit dem Raspi
Nach dem Auspacken des USB2VGA-Adapters einfach mal an der einen Seite einen weiteren Monitor dran, das andere Ende mit einem USB-B-Kabel an den USB-Hub am Raspi (Anmerkung: funktioniert auch direkt am Raspi, wie ich bei diversen Versuchen herausfand). Eine schnelle Kontrolle mit lsusb und dmesg zeigte, dass der Adapter korrekt erkannt wurde und als /dev/fb1 eingehängt wurde. Auf dem Monitor war ein grünes Bild … sonst nix.
Auch die LXDE-Bildschirmeinstellung brachte mich nicht weiter … hier gab es nur den „Standardmonitor“ und keine weiteren Geräte. Also weiter mit xrandr … das soll ja sowas können.
ein nervenaufreibender Tag mit xrandr
Ich nehme die Pointe mal vorweg – ich habe es nicht hinbekommen, trotz vieler Versuche, stundenlangem googeln und lesen … ich konnte xrandr nicht bewegen den HDMI-Ausgang und den USB2VGA-Adapter zu verwalten.
Es scheitert schon am HDMI-Ausgang, denn xrandr erkennt nur „default“ als Display und setzt es mit einer festen Auflösung an. Die Abfrage xrandr --listproviders bringt als Ergebnis immer 0 und auch das Hinzufügen und Ändern von Bildschirmmodi hat nicht funktioniert.
Um sicher zu gehen, dass es nicht an meinem Image liegt (Raspbian Jessie LITE mit manuell installiertem X-Server, LXDE und Openbox) habe ich auf anderen Raspis im Haus versucht …. xrandr hat mir nirgends mehr ausgespuckt.
Da xrandr nicht korrekt funktioniert, brachte mich also auch das GUI-Tool Arandr nicht weiter, dass auch immer nur das „default“-Display mit der fixen Auflösung anzeigte.
X-Server mittels xorg.conf überzeugen
Nachdem nun das moderne und flexible xrandr seinen Dienst versagte, muss nun eine feste Konfig gebastelt werden …
/etc/X11/xorg.conf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 | Section "Device" Identifier "usb" Driver "fbturbo" Option "fbdev" "/dev/fb1" Option "ShadowFB" "off" EndSection Section "Device" Identifier "pihdmi" Driver "fbturbo" Option "fbdev" "/dev/fb0" Option "ShadowFB" "off" EndSection Section "Monitor" Identifier "Terra" Modeline "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync Option "PreferredMode" "1280x1024_60.00" Option "DPMS" "true" EndSection Section "Screen" Identifier "vga" Device "usb" Monitor "Terra" DefaultDepth 16 SubSection "Display" Depth 16 Modes "1280x1024" EndSubSection EndSection Section "Screen" Identifier "hdmi" Device "pihdmi" Monitor "Terra" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection Section "ServerLayout" Identifier "default" Screen 0 "hdmi" 0 0 Screen 1 "vga" RightOf "hdmi" # Option "Xinerama" "on" EndSection |
Dann ein sudo systemctl restart lightdm und der X-Server brachte mir auf dem zweiten Monitor ebenfalls einen Desktop, nur ohne Panel und mit den Default-Einstellungen zum Desktop-Hintergrund. Ein Verschieben von Fenstern über beide Desktops war natürlich nicht möglich, da es eben kein ausgedehntes Desktop ist, sondern irgendwie ein weiteres Desktop unter dem gleichen Benutzer.
Xinerama mit Pi-HDMI und USB2VGA
Hoch motiviert habe ich dann versucht mittels der Zeile Option "Xinerama" "on" die Desktoperweiterung zu aktivieren. Ihr ahnt es … versucht heißt, dass es nicht funktioniert hat.
Ich habe in der Folge gefühlt 100 Varianten der Konfig getestet, immer mit dem Ergebnis, dass der X-Server abstürzt oder eben nur ein Screen voll nutzbar ist. Irgendwann bin ich dann auch mal auf die Idee gekommen unter /var/log/Xorg.0.log zu forschen, warum … es war erstaunlich einfach:
Der X-Server kann Xinerama nicht starten, wenn die beiden Screens unterschiedliche Farbtiefen (Depth) verwenden und stürzt dann ganz ab. Der Pi läuft standardmäßig mit 24 Bit, der USB2VGA-Adapter kann 16 Bit und 32 Bit, letzteres aber leider nur unter Windows.
Ich mache es auch hier kurz … man hat jetzt eine Möglichkeit mit zwei Optionen das erweiterte Desktop zu bekommen … man freundet sich mit 16-Bit Farbtiefe auf beiden Bildschirmen an
- Weg 1: den HDMI-Framebuffer des Raspi über die config.txt ebenfalls fest auf 16-Bit runterschrauben
- Weg 2: zwei USB2VGA-Adapter nehmen und den HDMI-Port des Rapsi ungenutzt lassen
Mit Weg 2 habe ich problemlos mittels xorg.conf einen erweiterten Desktop eingerichtet bekommen. Über die Performance brauchen wir gar nicht reden, wenn das Bild komplett über 2 USB-Adapter an einem Hub erzeugt wird und 16-Bit Farben fand ich das letzte mal unter Win2k schön.
Wer damit leben kann, kann diese Konfig nehmen – alle anderen müssen unter der Konfig mein Workaround lesen 😉
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 | Section "Device" Identifier "usb1" Driver "fbturbo" Option "fbdev" "/dev/fb1" Option "ShadowFB" "off" EndSection Section "Device" Identifier "usb2" Driver "fbturbo" Option "fbdev" "/dev/fb2" Option "ShadowFB" "off" EndSection Section "Device" Identifier "pihdmi" Driver "fbturbo" Option "fbdev" "/dev/fb0" Option "ShadowFB" "off" EndSection Section "Monitor" Identifier "Terra" Modeline "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync Option "PreferredMode" "1280x1024_60.00" Option "DPMS" "true" EndSection Section "Screen" Identifier "vga1" Device "usb1" Monitor "Terra" DefaultDepth 16 SubSection "Display" Depth 16 Modes "1280x1024" EndSubSection EndSection Section "Screen" Identifier "vga2" Device "usb2" Monitor "Terra" DefaultDepth 16 SubSection "Display" Depth 16 Modes "1280x1024" EndSubSection EndSection Section "Screen" Identifier "hdmi" Device "pihdmi" Monitor "Terra" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubSection EndSection Section "ServerLayout" Identifier "default" Screen 0 "vga1" 0 0 Screen 1 "vga2" RightOf "vga1" Option "Xinerama" "on" EndSection |
Mich hat diese Lösung nicht erfüllt. Ich wollte gerne auf dem Hauptscreen weiterhin meine 24-Bit-Farben nutzen. Der zweite Screen, nicht dauerhaft benötigt, darf gerne mit weniger laufen und soll ohnehin nur bei Bedarf ne Webseite anzeigen, oder ein weiteres Terminal beherbergen.
Mein Workaround: den geteilten Desktop bewirtschaften
Basierend auf meiner ersten xorg.conf habe ich nun also den zweiten Desktop angenommen. Dort kann man vom ersten Desktop aus auch Programme starten. Von einem Terminal oder aus einem Skript heraus kann man zum Beispiel mit
DISPLAY=:0.1 lxterminal
auf dem zweiten Screen ein Terminalfenster starten. Das hat aber keine Titelleiste, keine Fensterkontrollelemente und kann auf seinem Screen nicht verschoben werden. Mit etwas Recherche im Netz habe ich die Ursache auch gefunden … der Fenstermanager openbox läuft aktuell nur auf dem ersten Bildschirm. Um das Problem zu lösen habe ich mir mal ein Skript erstellt …
1 2 3 4 | #!/bin/bash #Startet Fenstermanager auf zweitem Screen DISPLAY=:0.1 openbox & exec openbox-session |
Das startet nun openbox auf dem zweiten Screen und sorgt für eine ordentliche Session. Jetzt haben die Fenster Titelleisten und die gewohnten Steuerelemente und können nach belieben innerhalb des zweiten Screens verschoben werden.
jetzt kann auf dem zweiten Screen über ein Terminal mit obconf das Aussehen angepasst werden, so dass beide Desktopteile „harmonisch“ wirken.
Ein Problem bleibt aber noch … die Fenster aus dem zweiten Screen tauchen aber logischerweise nicht im lxpanel auf dem ersten Screen auf und es gibt kein Menü/keine Programmstarter auf dem zweiten Screen.
Der erste Gedanke … einfach auf dem zweiten Screen auch das lxpanel starten – geht leider nicht, anders als openbox, lässt sich lxpanel nur einmal starten. Also muss ein anderes Panel her, mit dem man die Tasks des zweiten Screens verwalten kann
ein Panel für den zweiten Screen: tint2
Ich habe mich für tint2 entschieden, weil es klein ist, recht einfach an die eigenen Bedürfnisse angepasst werden kann und noch dazu aus den Paketquellen zu bekommen ist.
Nach der Installation kann man es einfach im Terminal des zweiten Screens mittels tint2 starten und hat in der Grundkonfig schon mal ein Panel mit Taskleiste und Uhr.
Das Aussehen und die Funktion des Panels lässt sich in der ~/.config/tint2/default.tint2rc beeinflussen. Man kann diese auch einfach kopieren und in der Kopie nach Herzenslust Farben, Rahmen, Panelaufteilung und vor allem Starter, mit denen man gezielt auf dem zweiten Screen Dinge starten kann, erstellen. Mit dem Tool tint2conf kann man dann eine Konfig auswählen und aktivieren ohne das Panel selbst neu zu starten.
das Finetuning: Skripte und Starter fürs zweite Panel
Ich habe mir für das Starten des zweiten Desktops oben erwähntes Skript angelegt und auf meinem Desktop als Starter platziert, da ich aus Ressourcengründen diesen nicht immer mit laufen lassen möchte.
Für das Starten der verschiedenen Apps auf dem zweiten Screen habe ich mir entsprechende Skripte und Starter erzeugt, die ich dann im zweiten Panel verknüpft habe.
Chromium aufdem zweiten Screen parallel starten
Chromium startet standartmäßig neue Fenster immer im selben Screen. Das kann man aber umgehen, indem man für den zweiten Screen ein eigenes „User-Data-Dir“ für den Browser definiert und dann kann man sogar zwei verschiedene Browser-Konfigurationen parallel laufen lassen. Mein Skript start_chromium2.sh …
1 2 | #!/bin/bash DISPLAY=:0.1 chromium-browser --user-data-dir=/home/pi/.chromium-2 |
… startet den Browser mit einem anderen Datenverzeichnis und damit auch in einem anderen Kontext. Ich habe einfach dafür ein neues Verzeichnis im Homedir angelegt. Vielleicht ginge es auch mit einem Softlink auf das „normale“ Datenverzeichnis, dann hätten beide Browser den selben Cache, die selben Cookies … aber ich finde es ok quasi zwei verschiedene Browser zu haben, sind eh über den Google-Account synchronisiert.
Für diese Skript habe ich dann einen Starter chromium2.desktop erstellt …
1 2 3 4 5 6 7 | [Desktop Entry] Type=Application Name[de_DE]=Chromium 2nd Exec=/home/pi/Skripte/start_chromium2.sh GenericName=Startet Chromium auf zweitem Screen Comment[de_DE]=Startet Chromium auf zweitem Screen Icon=/home/pi/Skripte/chromium.png |
… den ich nun im zweiten Panel eingebunden habe. Man kann ihn natürlich auch im lxpanel oder dem Desktop verlinken, wollte ich aber nicht. So erscheint er nämlich nur auf dem zweiten Screen, also auch nur, wenn dieser verfügbar ist.
In meiner default.tint2rc habe ich das so eingebunden …
[...] launcher_item_app = /home/rainer/Skripte/tint2conf.desktop launcher_item_app = /home/rainer/Skripte/thunar2.desktop launcher_item_app = /home/rainer/Skripte/chromium2.desktop launcher_item_app = /home/rainer/Skripte/lxterm.desktop [...] |
tint2conf.desktop ist ein Starter für das oben erwähnte Konfig-Tool von tint2.
thunar2.desktop bringt mir einen Dateimanager auf den zweiten Screen, denn der LXDE-Standard pcmanfm lässt sich auch mit verschiedenen Tricks nicht auf dem zweiten Screen parallel starten.
lxterm.desktop ist, ihr ahnt es, ein Starter für das Terminal auf dem zweiten Screen.
Die Starter sind alle nach dem Prinzip vom Chromium-Starter aufgebaut … der Starter greift auf ein Skript zurück und im Skript werden die Anwendungen immer mit der DISPLAY-Variable vorweg gestartet. Diese Variante hat den Vorteil, dass alle Starter auch vom Hauptscreen aus funktionieren, solange der zweite Screen verfügbar ist.
Fazit
Das Verschieben von Fenstern vom einen auf den anderen Screen oder ein Screen-übergreifendes Fenster ist mit dieser Variante natürlich nicht möglich. Dazu muss man zwingend Xinerama zum Laufen bringen. Wer, wie ich, auf diese Funktion verzichten kann, kann auf diese Weise aber auch ein nutzbaren Desktop auf einem weiteren Bildschirm erzeugen.
Ein alternativer Weg für einen zweiten Desktop, sogar mit eigenem Benutzer ist die MultiSeat-Funktionalität von lightdm. Das habe ich auch ausprobiert, ist sehr interessant, weil man damit an einer Maschine mehrere unabhängige X-Server erzeugen und auf verschiedene Monitore verteilen kann. Trickreich ist dann das Konfigurieren der Eingabegeräte, denn ohne weitere Zutun werden Eingaben und Mausbewegungen parallel an beide X-Server gesendet (witziger Effekt), aber das war dann nicht das, was ich gesucht habe.