Als Arbeitstier für mein Studium habe ich unlängst ein Thinkpad T440p erstanden. Passend dazu stieß ich auf ein unschlagbar günstiges Angebot für einen DisplayLink USB-Monitor aus dem gleichen Hause in der Bucht. Der Thinkvision Lt1421 hat, genau wie mein Thinkpad eine Diagonale von 14 Zoll und wird einzig per USB angeschlossen. Zwar ist die Bildqualität des verbauten Panels bei einer Auflösung von 1366×768 nicht berauschend, für meine Zwecke ist das aber durchaus ausreichend.
Doch zunächst verweigerte das Display unter meiner Manjaro Installation den Dienst und gab nur einen farbenfrohen Pixelbrei aus. Testhalber ließ ich den Monitor erst einmal unter Windows 10 erkennen, wo er auch tadellos funktionierte.
Nach einiger Recherche im Netz erfuhr ich, dass der zu dieser Zeit aktuelle Intel Grafiktreiber xf86-video-intel-1:2.99.917+892 die Probleme mit Displaylink verursachte. Zunächst half also nur ein Downgrade des Grafiktreibers. Relativ komfortabel lässt sich das über das Terminal mit dem Tool „downgrader“ realisieren, welches aus der AUR bezogen werden kann. Aktuell ist dieser Schritt nicht nötig da die Version 1:2.99.917+899 diesen Fehler nicht mehr produziert. Es kann aber nicht ausgeschlossen werden, dass ein künftiges Treiberupdate wieder neue Probleme macht und so wieder ein Downgrade erforderlich wird.
Im Gegensatz zu USB3.0 Displaylink Geräten, welche den evdi Treiber nutzen, benötigen USB 2.0 Geräte den UDL Treiber, welcher seit der Linux Kernel Version 4.14.9-1 standardmäßig aktiviert ist. Das Display wird also nach dem Einstecken erkannt und gibt auch direkt ein Bild aus. Hier begegnete ich direkt dem nächsten Fehler. Hinter einem Schwarzen Bildschirm kam der eigentliche Bildinhalt nur dort zum Vorschein, wo ich den Mauscursor gerade entlang bewegte. Ich konnte das Hintergrundbild quasi wie auf einem Rubbellos „freirubbeln“.
Dieser Effekt wird auch im Displaylink-Eintrag des ArchWikis erläutert. Um dieses Problem zu beseitigen, muss zunächst der korrekte Bildmodus definiert und dieser anschließend dem Display zugeordnet werden. In meinem Fall geschieht das über folgende Befehle:
xrandr --newmode "1368x768_59.90" 85.72 1368 1440 1584 1800 768 769 772 795 -HSync +Vsync
xrandr --addmode DVI-I-1-1 1368x768_59.90
xrandr --output DVI-I-1-1 --mode 1368x768_59.90
Den korrekten Modus für andere Geräte kann man mit dem Befehl:
gtf 1366 768 59.9
ermitteln. Wobei natürlich die Auflösung und Bildwiederholrate des eigenen Bildschirms einzutragen sind. Um diese Eingabe nicht nach jedem Systemstart wiederholen zu müssen, kann man in der Datei: /etc/X11/xorg.conf.d/10-monitor.conf den Eintrag:
Identifier "DVI-I-1-1"
Modeline "1368x768_59.90" 85.72 1368 1440 1584 1800 768 769 772 795 -HSync +Vsync
Option "PreferredMode" "1368x768_59.90"
EndSection
einfügen. Dies kann man noch beliebig für weitere Einträge ergänzen. Also für DVI-I-1-2, DVI-I-1-3, usw., Da bei jedem ab- und anstecken der Zähler des Monitors steigt.
Jetzt funktionierte zwar die Anzeige wie erwartet, jedoch wartete bereits der nächste Fehler auf mich, welcher tatsächlich lästiger war, als es zunächst klingen mag. Sobald auf dem Bildschirm irgend etwas passierte, quittierte der Mauscursor dies mit einem Flackern, welches erst wieder aufhörte, wenn wieder ein „Standbild“ ausgegeben wurde. Wenn man nun aber ein Video laufen ließ, flackerte der Cursor durchgängig.
Hier durchforstete ich eine ganze Weile diverse Foren und fand dabei folgende Konfiguration recht funktional:
Die Datei: 20-intel.conf wird unter /usr/share/X11/xorg.conf.d/ angelegt mit folgendem Inhalt:
Section "Device"
Identifier "Intel Graphics"
Driver "Intel"
Option "AccelMethod" "sna"
Option "DRI" "2"
Option "TearFree" "true"
Option "TripleBuffer" "true"
Option "MigrationHeuristic" "greedy"
Option "Tiling" "true"
Option "ExaNoComposite" "false"
EndSection
Dort wird auch die folgende 20-displaylink.conf angelegt:
Identifier "DisplayLink"
Driver "modesetting"
Option "PageFlip" "false"
EndSection
ich nutzte dazu übrigens den Terminal-Editor nano.
Jetzt flackerte der Cursor kaum mehr. Nur wurde das System eigenartigerweise recht intensiv belastet und solange die Maus über den Bildschirm bewegt wurde, rührte sich sonst nichts mehr. Videos stoppten, Animationen wurden unterbrochen usw …
Das ließ sich beheben, indem das displaylink-aur Paket installiert wurde:
git clone https://aur.archlinux,org/displaylink.git
cd displaylink
makepkg -scCi
Damit war endlich Ruhe. Das Display wird zuverlässig erkannt und der Cursor verhält sich so, wie man es von ihm erwartet. Auch wenn das Display über den UDL Treiber angesprochen wird, braucht es wohl das das Displaylink Paket um den ordnungsgemäßen Betrieb zu gewährleisten.
Zu Beachten ist nun lediglich, dass der Bildschirm erst nach dem Systemstart angesteckt wird, weil es sonst häufig nur ein verzerrtes Standbild zeigt. Einmal korrekt erkannt kann man sich jedoch auch problemlos aus der aktuellen Sitzung ausloggen, ohne dass der Bildschirm den Dienst quittiert.
Update 11.04.20: nach einem kürzlichen Systemupdate erwartete mich wieder ein verzerrtes Bild auf dem USB Monitor. Schuld war hierbei das Mesa-Paket, welches auf die Version 20.0.4-1 angehoben wurde. Ein Downgrade auf die letzte 19er Version stellte die gewünschte Funktion wieder her.
Update 06.05.20: das aktuelle Update des mesa-vdpau Pakets auf die Version 20.0.6-2 verursacht ebenfalls Probleme mit dem Bildschirm. Ein Downgrade auf eine 19er Version schafft auch hier Abhilfe.