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.

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. Nach längere Zeit nutze ich an meinem Desktop-Rechner wieder fest zwei Monitor 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ämtlich Informationen zum Stand zu 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 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ähliche Blog-Artikel geben Tipps und Tipps, doch leider haben sich bei mir leider keine 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-Trucker 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 bleibenden 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 Schug 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 die 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 sollte 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 dar 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 dem 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 nun ist der Drops nun 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 dem selben Namen, wie das Binary eures Browser 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-Browser zeige ich euch kurz das Anlegen dieses SKripts. Erzeugt dazu eine Datei /usr/local/bin/firefox mit touch, weißt Ihr die passenden Rechte mit chmod zu und öffnet Sie abschließend in den Browser 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 sind und 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, den 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önnte 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 Player 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.

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 Monitore-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 einen 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.

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.