Besonders ärgerlich wird das, wenn der Monitor, den GDM für den Login verwendet, gar nicht eingeschaltet ist. Dann bleibt der Bildschirm schwarz, und ich tappe im Dunkeln, bis ich das Notebook aufklappe oder den richtigen Monitor finde. Offenbar nutzt GDM eine eigene Konfiguration, die nichts mit den Anzeigeeinstellungen der GNOME-Sitzung zu tun hat. Im Wiki von Arch Linux bin ich auf eine Lösung gestoßen, mit der sich dieses Verhalten zuverlässig korrigieren lässt – und die auch unter anderen Distributionen funktioniert.

Warum GDM den falschen Monitor verwendet

Das Problem tritt typischerweise bei Systemen mit mehreren Bildschirmen auf, besonders wenn proprietäre Grafiktreiber wie von Nvidia im Einsatz sind. GNOME speichert die Bildschirmanordnung pro Nutzer in einer Datei namens monitors.xml im Verzeichnis ~/.config. GDM hingegen nutzt eine eigene Konfiguration im Kontext des gdm-Benutzers. Da diese Datei beim Einrichten des Systems nicht automatisch mit der des Hauptbenutzers synchronisiert wird, kann es passieren, dass der Login-Screen auf dem falschen Bildschirm erscheint – und dort auch bleibt.

Manuelle Lösung: Anzeigeeinstellungen übernehmen

Der einfachste Weg, GDM die richtige Monitorkonfiguration beizubringen, ist das Kopieren der monitors.xml-Datei aus dem Benutzerverzeichnis in das Konfigurationsverzeichnis von GDM.

1. Stellt zunächst die gewünschte Bildschirmkonfiguration in GNOME ein. Öffnet dazu die Anzeigeeinstellungen über:

$ gnome-control-center display

Wählt den bevorzugten Hauptbildschirm aus und arrangiert die Monitore nach Wunsch. Die Änderungen werden automatisch in eurem Homeverzeichnis unter ~/.config/monitors.xml gespeichert.

2. Kopiert die Datei in das Home-Verzeichnis von GDM:

$ sudo install -o root -m 644 ~/.config/monitors.xml ~gdm/.config/

Das Home-Verzeichnis des GDM-Nutzers ~gdm wird dabei korrekt vom System interpretiert.

3. Startet GDM neu, damit die neue Konfiguration übernommen wird – Achtung: Dabei wird eure aktuelle GNOME-Sitzung ohne Vorwarnung beendet:

$ sudo systemctl restart gdm

Nach dem Neustart sollte der Login-Screen auf dem gewünschten Monitor erscheinen.

Automatisierte Lösung: Mit einem Systemd-Service

Wenn Ihr häufiger mit unterschiedlichen Monitor-Setups arbeitet oder einfach eine dauerhafte Lösung bevorzugt, könnt Ihr das Kopieren der Datei beim Systemstart automatisieren.

1. Legt das Verzeichnis für den systemd-Override an:

$ sudo mkdir -p /etc/systemd/system/gdm.service.d

2. Erstellt eine neue Konfigurationsdatei override.conf mit folgendem Inhalt:

[Service]
ExecStartPre=/bin/sh -c 'install -o root -m 644 /home/EUER_NUTZER/.config/monitors.xml ~gdm/.config/monitors.xml || true'

Ersetzt EUER_NUTZER durch euren tatsächlichen Benutzernamen.

3. Ladet die systemd-Konfiguration neu:

$ sudo systemctl daemon-reexec

Beim nächsten Start von GDM wird die Datei automatisch übernommen.

Noch einfacher: Mit den grafischen GDM-Settings

Ganz zum Schluss gibt es noch eine grafische Alternative. Mit dem Programm GDM Settings, oder in der deutschen Übersetzung GDM Einstellungen, könnt Ihr viele Details des Loginmanagers konfigurieren – darunter eben auch die Bildschirmeinstellungen übernehmen. Ganz einfach per Mausklick und ohne Kommandozeile.

Das Programm ist kein offizielles GNOME-Tool und befindet sich meist auch nicht in den Paketquellen. Ihr könnt es aber via Flathub problemlos installieren. Achtet beim ersten Start auf die Warnung: Nutzung auf eigene Gefahr. Viele Optionen ändern Systemdateien, was im Einzelfall zu Problemen führen kann – aber in der Regel funktioniert alles wie gewünscht.

Zum Übernehmen der Bildschirmkonfiguration des aktuell angemeldeten Nutzers öffnet Ihr in der Seitenleiste den Punkt Anzeige und klickt dann auf Aktuelle Bildschirmeinstellungen anwenden. Eine automatische Übernahme bei wechselnden Setups gibt es hier allerdings nicht. Wenn Ihr euer Notebook regelmäßig zwischen Arbeitsplatz und Homeoffice mit jeweils unterschiedlicher Monitorkonfiguration nutzt, ist die oben beschriebene systemd-Variante möglicherweise die bessere Wahl.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Das Logo des Herstellers glitzert mir auf der Frontseite des Gehäuses entgegen, doch weitere Informationen zum Gerät finden sich dort nicht. Und auch auf der Rückseite gibt es keine weiteren Details. Ein Schildchen mit der Typenbezeichnung gab es in der Regel bei den guten alten Röhrenmonitoren, doch bei meinen aktuellen Dell-Flatscreens findet sich dort nichts mehr. Auch die Monitor-Einstellungen der Gnome-Desktopumgebung lassen den Nutzer im Stich. Die zeigen nur dann Informationen zum Typ des Monitors an, wenn zwei Displays angeschlossen sind. Mehr als den Hersteller und die Bildschirmdiagonale erfährt man jedoch nicht.

Gnome geizt mit Informationen

Wenn die grafischen Tools so sparsam mit Informationen sind, dann hilft doch sicherlich das Terminal. Tools zur Anzeige von Hardware-Informationen gibt es unter Linux ja wie Sand am Meer, da müsste doch was dabei sein. Das Go-To-Werkzeug für diese Aufgabe wäre hier Inxi, das sich bei vielen Distributionen aus den Paketquellen installieren lässt (etwa via pacman -S inxi bei Arch Linux oder apt install inxi bei Ubuntu, Debian und Derivaten). Das Kommando inxi -F spuckt dann sämtliche Details zum System aus, aber auch hier Pustekuchen: keine Details zu den angeschlossenen Monitoren.

Details zum Monitor über das Terminal

Um mir eine weitere Suche unter den zahlreichen Tools zu ersparen, greife ich nun gleich auf das „richtige“ Werkzeug zurück. Details zum Displayserver liefert das Kommandozeilenwerkzeug Xrandr. Tools wie Inxi machen in der Regel nichts anderes, als solche Kommandos auszuführen und die Ausgabe optisch aufgewertet anzuzeigen. Über xrandr -q --verbose bekommt man also zahlreiche Details zu den unterstützten Auflösungen und Wiederholraten, doch der Name und Typ des Monitors fehlt immer noch. Aber nicht ganz: Die Daten sind im Feld EDID oder Extended Display Identification Data codiert.

Wer diese Daten nun nicht von Hand decodieren möchte, muss sich ein wenig unter die Arme greifen lassen. Das bei Stack Overflow gepostete Skript beispielsweise braucht keine weiteren Helferlein, um die EDID zu dekodieren. Ihr speichert folgenden Code einfach als monitor.sh ab und macht die Skriptdatei via chmod +x monitor.sh ausführbar. Aus dem Terminal heraus aufgerufen, zeigt das Skript dann die angeschlossenen Monitore inklusive des Namens des Herstellers und der Typenbezeichnung an. Technische Details zu Auflösungen oder Wiederholraten fehlen, doch die lassen sich ja auch an zahlreichen anderen Stellen ermitteln.

#!/bin/bash
while read -r output hex conn; do
    [[ -z "$conn" ]] && conn=${output%%-*}
    echo "# $output $conn   $(xxd -r -p <<< "$hex")"
done < <(xrandr --prop | awk '
    !/^[ t]/ {
        if (output && hex) print output, hex, conn
        output=$1
        hex=""
    }
    /ConnectorType:/ {conn=$2}
    /[:.]/ && h {
        sub(/.*000000fc00/, "", hex)
        hex = substr(hex, 0, 26) "0a"
        sub(/0a.*/, "", hex)
        h=0
    }
    h {sub(/[ t]+/, ""); hex = hex $0}
    /EDID.*:/ {h=1}
    END {if (output && hex) print output, hex, conn}
    ' | sort
)

$ ./monitor.sh 
# DP1-8 DP1   DELL U2515H
# HDMI1 HDMI1   DELL P2213

Alternativ holt ihr euch das Paket edid-decode auf den Rechner. Bei Ubuntu/Debian oder Linux Mint direkt über die offiziellen Paketquellen (via apt install edid-decode), bei Arch Linux oder Manjaro lediglich über das AUR (etwa mit einem AUR-Helper via yay -S edid-decode-git). Hier genügt dann der folgende Einzeiler, der allerdings nicht mit dem proprietären Nvidia-Treiber funktioniert. Hier bekommt ihr dann allerdings nicht nur den Hersteller und den Monitortyp angezeigt, sondern auch gleich die Seriennummer der Geräte — falls ihr an diesen Interesse haben solltet.

$ for file in $(ls -1 /sys/class/drm/*/edid); do text=$(tr -d 0 <"$file"); if [ -n "$text" ]; then edid-decode "$file" | grep -e Manufacturer: -e Product; sleep 0.0001; fi done
  Vendor & Product Identification:
    Manufacturer: DEL
    Display Product Serial Number: '9X2VY55I0J0L'
    Display Product Name: 'DELL U2515H'
  Vendor & Product Identification:
    Manufacturer: DEL
    Display Product Serial Number: 'Y57VF31AAT3M'
    Display Product Name: 'DELL P2213'

Letztendlich wäre es natürlich schneller gewesen, die alten Rechnungen herauszusuchen, oder vielleicht auch mal einen Blick über den Tellerrand zu KDE zu werfen. Im Gegensatz zu den Einstellungen von Gnome zeigen die Systemeinstellungen von KDE nämlich gleich die Bildschirmkennungen mit an. Wie immer ist Gnome ein wenig arg spartanisch und geizig mit Funktionen und Details. In meinen Augen dürften die System-Settings von Gnome ruhig auch die Bezeichnungen ausgeben. Nötig sind sie in der Regel nicht, doch ab und an können sie doch auch praktisch sein.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Voraussetzung für die Erweiterung ist die Installation von Disper (gibt es ab Ubuntu 12.04 und auch für zahlreiche andere Distributionen) und natürlich die GNOME-Shell. Laut den Kommentaren soll sie hauptsächlich mit dem proprietären Nvidia-Treiber zusammenarbeiten, allerdings nutzt Disper xrandr, von daher sollte das Shell-Tool wie auch die Erweiterung mit anderen Grafikkarten laufen.

$ sudo apt-get install disper

Getestet habe ich die Lösung auf einem Testsystem mit Ubuntu 12.10. Dort muss man die Versionsnummer der Erweiterung in der metadata.json des Add-Ons anpassen und bekommt sie auch so unter der GNOME-Shell 3.5.4 zum Laufen, allerdings funktionierte bei mir nur das Umschalten zwischen primärem und sekundärem Display zuverlässig, die anderen Modi erzeugten Grafikmüll auf dem Schirm. Speichert daher vor einem Test wichtige Dokumente ab, nicht dass ihr den Xserver killen müsst und wichtige Daten verliert, andere Systeme habe ich leider gerade nicht zur Hand.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Nach der langen Einleitung versuche ich nun wieder die Kurve zum eigentlichen Inhalt des Beitrags zu kommen: Flash und seine Probleme mit einem Dual-Monitor-System. Seit längerer Zeit nutze ich an meinem Desktop-Rechner wieder fest zwei Monitore und muss mich daher zwangsläufig dem Thema mal wieder widmen, Anlass ist auch die Fußball-EM, deren Streams von ARD und ZDF nur über Flash laufen.

Update 29.09.2014: Adobe hat die Unterstützung für Systeme mit mehr als einem Monitor in den aktuellen Versionen des Browser-Plugins deutlich verbessert. Allerdings spendierte Adobe die Neuerung lediglich der Pepper-Flash-Variante des Plugins. Wer mit Firefox arbeitet, sollte daher in Erwägung ziehen auf einen Browser wie Chrome oder Chromium mit PPAPI-Support umzusteigen, oder mit dem experimentellen Pepper-Flash-Wrapper zu arbeiten. Sämtliche Informationen zum Stand von Flash unter Ubuntu 14.04 und neuer findet ihr hier… Adobe Flash für Firefox, Opera, Chromium und Chrome unter Ubuntu 14.04 und 14.10 installieren.

Die Probleme

Nun also mal zu den Wehwehchen von Adobe Flash auf einem Linux-System mit zwei Monitoren. Wer so ein Setup nutzt, der wird über kurz oder lang ein paar nervige Probleme feststellen können, die sich leider nicht so einfach beheben lassen.

• Im Vollbild erscheinen Flash-Videos nicht auf dem Schirm, wo auch das Browser-Fenster liegt, sondern poppen immer auf dem primären Monitor auf.
• YouTube-Videos lassen sich zwar auf beiden Monitoren maximieren, allerdings wird das Video nicht auf die volle Breite des Displays aufgezogen und die Bedienelemente sind klitzeklein.
• Vollbild-Videos schnappen zurück ins Browser-Fenster, sobald man auf dem zweiten Display irgendein anderes Fenster anklickt und ihm so den Fokus gibt.

Alle Probleme zusammengenommen machen Flash-Videos auf einem Dual-Screen-System zu einer nervigen Sache. Eigentlich könnte man bequem auf einem Monitor arbeiten und am zweiten die EM schauen, doch weder funktioniert der Vollbild-Modus ordentlich, noch bleibt er lange erhalten.

Lösungen gefragt!

Im Netz tummeln sich bezüglich dieser Bugs zahlreiche Threads in Foren und unzählige Blog-Artikel geben Tipps und Tipps, doch leider hat sich bei mir keiner dieser Tipps bewährt. Ich habe weder für das Verschwinden des Fullscreen-Bildes bei einem Mausklick auf dem zweiten Monitor, noch für das Vollbild auf dem falschen Monitor eine Lösung gefunden. Für beide Issues gibt bzw. eher gab es schon Jahre alte Fehlermeldungen im Bug-Tracker von Adobe, allerdings ist jetzt nur noch der Falscher-Monitor-Bug dort zu finden… und zwar als gelöst.

Was mich noch interessieren würde: was YouTube anders macht, als bspw. Vimeo oder die Mediatheken von ARD und ZDF. YouTube-Flash-Videos maximieren sehr wohl auf das „richtige“ Display, während eben das Vollbild von Vimeo, ARD und ZDF immer auf dem primären Monitor landet. Es muss also noch einen Trick der YouTubler geben, den die anderen Web-Entwickler nicht kennen.

Fullscreen-YouTube-Bug

Was sich mit relativ erträglichem Aufwand und auch mit bleibendem Erfolg reparieren lässt, ist das Problem mit dem Vollbild bei YouTube-Videos. Bilder erklären hier die Lage sicherlich deutlich besser als viele Worte, von daher zeige ich einfach, wo der Schuh drückt.

Auf den folgenden Bildern seht Ihr ein Dual-Screen-System mit Ubuntu 12.04 und der GNOME-Shell. Auf dem rechten Screen läuft ein YouTube-Video im vermeintlichen Vollbild. Flash schafft es nicht das Bild auf die volle Breite zu strecken und die Bedienelemente sind klitzeklein. Im zweiten Bild seht Ihr wie das Ganze eigentlich aussehen sollte, das Video ist so breit wie der Bildschirm und die Buttons für Play und Co. sind normal groß.

Schuld daran ist das Verfahren wie Flash die Displaygröße ermittelt. Auf Al’s Website ist das Zustandekommen dieses Problems klasse erklärt, daher erspare ich mir an dieser Stelle weitere Details, allerdings lässt er uns nicht nur mit mehr Wissen um die Problematik zurück, sondern liefert auch gleich einen Patch, der das Problem in der Tat komplett behebt.

Den Patch müsst Ihr leider selber runterladen und kompilieren, was aber jetzt auch kein riesiges Unterfangen ist, im Archiv sind ausführliche Instruktionen hinterlegt, die ich hier im Rahmen des Artikels noch ein bisschen erläutern möchte. Getestet habe ich den Patch mit Ubuntu 12.04 64-Bit, aber auch ältere Ubuntus und andere Linux-Distributionen sollten funktionieren, dort müsst Ihr euch eben die genannten Abhängigkeiten mit dem Paketmanager eurer Distro holen.

Als Vorbereitung ladet Ihr euch bitte die aktuelle Version des YouTube-Fullscreen-Hacks herunter und packt das Archiv bspw. in /tmp aus, merkt euch bitte den Pfad und wechselt in einem Terminal dort hin. Anschließend braucht Ihr noch ein paar Pakete, um den Hack bauen zu können, auf 64-Bit Systemen braucht es auch die Build-Abhängigkeiten des NsPluginWrappers.

$ sudo apt-get install build-essential libx11-dev
$ sudo apt-get build-dep nspluginwrapper # Bei 64-Bit Systemen

64-Bit Linuxer müssen anschließend auch noch das Makefile in einem Editor ihrer Wahl öffnen und dort die erste Zeile von BITS=32 in BITS=64 ändern, so dass der Hack auch ordentlich für ein 64-Bit System gebaut wird. Danach wird mit einem simplen make der komplette Hack in wenigen Momenten gebaut, ein make test überprüft hinterher, ob das mit dem Bauen und der Erkennung der Auflösung auch geklappt hat.

$ make
$ make test
echo running without the hack...
running without the hack...
./tester
XGetGeometry reports width=3200 height=1200
echo running with the hack...
running with the hack...
LD_PRELOAD=./libfullscreenhack.so ./tester
fullscreen hack loaded...
XGetGeometry reports width=1920 height=1200

Interessant sind hier die beiden Zeilen mit XGetGeometry reports, sie zeigen an, welche Bildschirm-Dimension dem Flash-Plugin mit und ohne den Hack übermittelt wird. Wichtig ist, dass in der letzten Zeile die reale Auflösung eures primären Schirms steht. Stimmt hier alles, könnt Ihr den Hack als Bibliothek nach /usr/lib/ in euer System kopieren.

$ sudo cp libfullscreenhack.so /usr/lib/libfullscreenhack.so

Anschließend könnt Ihr den Hack nun erstmals richtig testen. Beendet dazu bitte euren Browser vollständig (Beachtet bitte bei Chrome, dass der Browser im Hintergrund als „Schnellstarter“ weiterläuft) und ruft dann euren Browser mit einem vorangestellten LD_PRELOAD=/usr/lib/libfullscreenhack.so auf, so dass eure Bibliothek zusammen mit dem Browser geladen wird.

$ LD_PRELOAD=/usr/lib/libfullscreenhack.so firefox
$ LD_PRELOAD=/usr/lib/libfullscreenhack.so /opt/google/chrome/chrome
$ LD_PRELOAD=/usr/lib/libfullscreenhack.so euerbrowser

Stimmt das Vollbild bei einem YouTube-Video, ist der Drops eigentlich schon gelutscht, allerdings ist es nicht gerade bequem nun den Browser immer aus dem Terminal heraus zu starten. Ich würde daher ein kleines Shell-Skript mit demselben Namen wie das Binary eures Browsers unter /usr/local/bin anlegen, das euren Browser mit dem LD_PRELOAD-Vorspann lädt. Da /usr/local/bin im $PATH weit vorne steht, wird automatisch euer Skript geladen und das Flash-Problem bei YouTube behoben.

Anhand des Firefox-Browsers zeige ich euch kurz das Anlegen dieses Skripts. Erzeugt dazu eine Datei /usr/local/bin/firefox mit touch, weist Ihr die passenden Rechte mit chmod zu und öffnet sie abschließend im Editor eurer Wahl, hier wäre das gedit, der mit Root-Rechten aufgerufen wird.

$ sudo touch /usr/local/bin/firefox
$ sudo chmod +x /usr/local/bin/firefox
$ sudo gedit /usr/local/bin/firefox

Dort fügt Ihr dann in einem aller, aber auch wirklich aller letzten Schritt die folgenden Zeilen ein. Sie bewirken, dass euer Firefox beim Klick ins Menü eurer Desktopumgebung ganz normal geladen wird, allerdings wird immer das LD_PRELOAD davorgesetzt.

#!/bin/bash
LD_PRELOAD=/usr/lib/libfullscreenhack.so firefox $@

Die restlichen beiden Probleme werden wohl auch in Zukunft nicht mehr bei Adobe-Flash behoben werden. Das Verschwinden des Vollbilds beim Klick auf den zweiten Screen ist – wenn ich mich richtig erinnere – angeblich ein Feature und kein Bug, und das Vollbild auf dem falschen Screen lässt sich einfach nicht auf den richtigen Bildschirm schieben.

HTML5 für YouTube und Vimeo

Die wohl einzig vernünftige Lösung ist es Adobe-Flash im Video-Bereich den Stiefel zu geben und auf HTML5 umzusteigen. Das ist leider nicht völlig eure Wahl, denn der Video-Hoster muss selber seine Videos oder Streams auch via HTML5 anbieten. Das ist bei YouTube oder Vimeo der Fall, aber bei unzähligen anderen Diensten (wie auch den Mediatheken von ARD und ZDF) leider nicht.

Bei YouTube könnt Ihr zentral auf der YouTube HTML5-Seite den Schalter umlegen, YouTube bezeichnet den HTML5-Player noch als Test, dennoch funktioniert er eigentlich ganz gut. Bei Vimeo findet Ihr unter jedem Video einen Link, um auf die HTML-Variante des Players zu kommen. So habt Ihr wenigstens bei diesen beiden Diensten Ruhe vor Flash, bei den Mediatheken von ARD und ZDF tut sich in dieser Richtung leider Gottes bislang noch gar nichts.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Nutzt man ein System mit einer Nvidia-Grafikkarte dann bieten die NVIDIA X-Server Settings eine entsprechende Option direkt an, das Konfigurationswerkzeug „Anzeigegeräte“ aus dem GNOME-Settings ist in dieser Richtung allerdings recht schweigsam. Ich kann die Position der Monitore ändern und so den Übergang von einem Monitor zum anderen regeln, doch eine offensichtliche Option „Das hier ist der primäre Monitor“ gibt es nicht.

GNOME soll ja einfach und intuitiv zu bedienen sein, von daher hat man diesen Dialog so gestaltet, dass man die Option nur durch Zufall entdecken kann. Der schwarze Balken über dem gelben Monitor ist nämlich nicht nur irgendein Balken, er ist quasi ein Sinnbild für das Panel am oberen Rand, er lässt sich mit der Maus auf den zweiten Schirm schieben, und diesen somit als primären Monitor festlegen.

Sollte euch aus irgendeinem Grunde der graphische Weg missfallen oder nicht zur Verfügung stehen, dann könnt Ihr auf das gute alte xrandr Kommando zurückgreifen, es liest eure Monitor-Konfiguration und kann diese auch setzen, die gängigen Desktopumgebungen greifen diese Einstellungen dann auch im Normalfall auf.

$ xrandr | grep connected
VGA1 connected 1280x1024+1920+148 (normal left inverted right x axis y axis) 359mm x 287mm
HDMI1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 160mm x 90mm
HDMI2 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)

Der Befehl sollte euch die Namen der angeschlossenen Monitore ausgeben, jede Schnittstelle, die ein „connected“ ausgibt, ist mit einem Monitor verbunden. Das VGA1, HDMI1 usw. packt Ihr dann nur noch in den entsprechenden Befehl und schon wandert das Dash bzw. die Shell auf diesen Schirm.

$ xrandr --output HDMI1 --primary

Diese Wahl ist allerdings nicht permanent, sondern nur bis zum nächsten Ausloggen aus dem System aktiv, von daher lässt sich die Wahl des primären Screens auch in der Konfigurationsdatei ~/.config/monitors.xml festzimmern. Öffnet sie in einem Editor eurer Wahl…

$ gedit  ~/.config/monitors.xml

…und ändert in der XML-Datei bei eurem Lieblingsmonitor in der „Primary“-Zeile das „no“ in ein „yes“. Entsprechend andersrum verfahrt Ihr mit den anderen Monitoren, bei denen muss natürlich ein „no“ stehen, so dass nur ein Monitor als primäres Display festgelegt ist.

yes ist markiert“ class=“wp-image-19005″/>

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Der Treiber wird jeweils nicht über die Paketverwaltung installiert. Kommt ein Kernelupdate, so kann der Xserver nicht mehr starten, weil das passende Kernelmodul fehlt. Bei der Installation über die Paketverwaltung kann das nicht passieren, denn das nötige Kernelmodul wird bei einem Kernelupdate automatisch mitgeliefert. Ich habe neulich ein Testsystem mit einer Nvidia GeForce 7600 GS Grafikkarte, zwei Bildschirmen und Ubuntu Gutsy Gibbon 7.10 aufgesetzt. Der Treiber und der Dual-Monitor-Betrieb ließen sich ohne Schwierigkeiten oder Basteleien an der xorg.conf einrichten. Ich habe ein paar Screenshots von der Aktion gemacht, vielleicht helfen die Tipps dem einen oder anderen.

Installation des Treibers

Den Restricted Manager findet man unter System | Systemverwaltung | Verwaltung eingeschränkter Treiber. Hat man diesen gestartet, so findet dieser die Grafikkarte und erkennt, dass der proprietäre Nvidia-Treiber noch nicht installiert wurde. Man sieht dies an der Spalte Aktiviert und Status.

Über einen Klick in die noch leere Checkbox unter Status wird die Installation des Treibers in die Wege geleitet. Es erscheint ein Dialog, der erklärt, was der Treiber bewirkt, wozu er benötigt wird und ob man ihn wirklich installieren will. Bejaht man diese Frage, so wird der Treiber automatisch aus dem Internet geladen und installiert.

Letztendlich ist der Treiber installiert. Nach einem Neustart des Systems – eigentlich würde ja auch ein Neustart des Xservers reichen – ist der Treiber aktiv. Man erkennt dies am Nvidia-Logo, das nun vor dem Start des Xservers erscheint. Die Desktop-Effekte, sprich Compiz als Windowmanager, werden automatisch aktiviert.

Dual-Monitor Betrieb

Nun sollten auch beide Monitore zu einem großen Desktop verschmelzen. Direkt nach dem Start wird jedoch nur ein Monitor benutzt. Ubuntu bietet seit der Version 7.10 einen Assistenten zum Einrichten der Bildschirmauflösung an. Dieser kommt auch mit zwei Monitoren zurecht. Man kann ihn über System | Systemverwaltung | Bildschirme und Grafik starten. Der Assistent erkennt, dass an der Grafikkarte zwei Monitore angeschlossen sind. Für beide lassen sich dann jeweils Auflösung (und Wiederholraten) definieren.

Für den zweiten Monitor kann man definieren, welche Rolle er spielen soll. In meinem Fall möchte ich einen großen Desktop, so dass ich Fenster von einem Monitor auf den anderen schieben kann. Dies lässt sich über die Option „Hauptbildschirm erweitern“ machen.

Nach einem Neustart des Xservers (einfach einmal aus und wieder einloggen) ist der zweite Monitor aktiv. Fazit: Man sieht, Ubuntu ist einfach geworden, man muss die gebotenen Funktionen nur nutzen!

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

In diesem Artikel habe ich ja schon beschrieben, wie man ein Tablett auf einem Linux-System einrichtet. Ergänzend hierzu folgen nun die Hinweise zum Betrieb mit zwei Monitoren an einem Rechner. Dazu editiert man wiederum die /etc/X11/xorg.conf und fügt die Option bzgl. Twinmode ein. Bei jedem Gerät muss also im Bereich…

Section "InputDevice"
    Identifier     "stylus"
    Driver         "wacom"
    Option         "Device" "/dev/input/wacom"
    Option         "Type" "stylus"
    Option         "USB" "on"
    Option         "PressCurve" "0,0,100,100"
EndSection

…die passende Option gesetzt werden.

# Allgemein
    Option "Twinview" "horizontal"|"vertical"|"none"
# Beispiel
    Option "Twinview" "horizontal"

Besitzen die eingesetzten Bildschirme eine unterschiedliche Auflösung, so kann man diese über die Option TVResolution jeweils definieren.

# Allgemein
    Option "TVResolution" "res1,res2"
# Beispiel
    Option "TVResolution" "1024x768,1280x1024"

Schließlich kann festgelegt werden, dass das Tablett nur auf einem Bildschirm aktiv sein soll, dann passt das Format des Grafiktabletts besser zum Format des Monitors und es kommt nicht zu unschönen Verzerrungen.

# Allgemein
    Option "ScreenNo" "n"
# Beispiel
    Option "ScreenNo" "1"

Nachdem man die xorg.conf gespeichert und den Xserver neu gestartet hat, sollte sich das Grafiktablett nun sehr gut mit einem Dualscreen-Arbeitsplatz vertragen und das Arbeiten mit dem Tablett unter Linux deutlich mehr Spaß machen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.