Anschließen eines Monitors an einen Router in OpenWrt

Displaylink in OpenWrt

Wir werden unseren Monitor anschließen, während wir einen USB Video-Adapter Displaylink verwenden. Die laufende Version von OpenWrt hat keine vollwertige Unterstützung für displaylink, deshalb können die Schwierigkeiten in verschiedenen Stufen entstehen, die wir versuchen werden zu überwinden.

Bevor wir beginnen, möchte ich einen Link, der mir geholfen hat, geben. Es könnte sein, dass er nicht so aktuell in den nächsten Versionen von OpenWrt sein wird, aber zur Zeit können wir viele zusätzliche Anwendungen für POpenWrt bekommen, wobei wir die Paketquelle aus http://projects.qi-hardware.com/index.php/p/openwrt-packages/ klonen.

Für die Anfügung einer neuen Anwendung zu OpenWrt kopieren wir diese in das Verzeichniss von OpenWrt/package, und beim nächsten Start von make menuconfig ist diese Anwendung schon inkludiert in das Paket.

Ok, beginnen wir. Ich weiß nicht, wie ich die Informationen richtig darstellen soll, damit sie für alle klar ist. Ich versuche die Hauptpunkte zu erzählen.

In Linux erfolgen die Aktivitäten mit Videodarstellungen mittels Frame Buffers. Was das ist, ist in der Dokumentation für die Option CONFIG_FB im Linuxkernel sehr eingängig geschrieben.

Damit der Adapter DisplayLink mit dem Frame Buffer funktionieren könnte, ist die Unterstützung dieser Option im Linuxkernel(FB_UDL) zu aktivieren.

Damit wir etwas auf dem Monitor sehen können, ist die Unterstützung der virtuellen Konsoleim Kernel zu aktivieren. Was das ist, kann man in "Hilfe" für die Option CONFIG_VT lesen. Es soll auch die Konsolunterstützung im virtuellen Terminal und auch eine optionale Unterstützung der Möglichkeit "binding and unbinding console drivers" gesichert sein.

Es ist auch anzugeben, dass die Konsole an den Frame Buffer gebunden ist. Die Konsole des Frame Buffers soll von der Haupteinrichtung der Ausgabeeinheites der Darstellung.

Jetzt fassen wir alles zusammen mittels konkreter Kerneloptionen. Führen wir den Befehl «make kernel_menuconfig» aus
Device Drivers:
USB Support:
<*> Support for Host-side USB
Graphics support:
<*> Support for frame buffer devices:
<*> Enable firmware EDID
<*> Framebuffer foreign endianness support
<*> Enable Video Mode Handling Helpers
<*> Enable Tile Blitting Support
Staging drivers:
<*> Displaylink USB Framebuffer support
Character devices:
<*> Virtual terminal
<*> Enable character translations in console
<*> Support for console on virtual terminal
<*> Support for binding and unbinding console drivers
Graphics support:
Bootup logo:
<*> Standard 224-color Linux logo
Console display driver support:
<*> Framebuffer Console support
<*> Map the console to the primary display device
<*> Framebuffer Console Rotation
<*> Select compiled-in fonts
<*> VGA 8x16 font

Stellen wir die Programmcode zusammen, installieren wir die Firmware auf den Router und starten ihn.

Schließen wir den Displaylink Adapter an. Grundsätzlich sollte es reichen, was wir schon gemacht haben. Als Ergebnis sollte ein Startbild mit einem Pinguin erscheinen:

Was aber mich angeht, habe ich Folgendes gesehen auf meinem Monitor: «Out of range. Dvi digital. 53.5kHz/85Hz».

Prüfen wir die Ausgabe von dmesg:

usb 1-1.4.2: dlfb: allocated 4 65024 byte urbs
usb 1-1.4.2: dlfb: Unable to get valid EDID from device/display
usb 1-1.4.2: dlfb: set_par mode 800x600
usb 1-1.4.2: dlfb: open /dev/fb0 user=0 fb_info=c1e8bc00 count=1
usb 1-1.4.2: dlfb: set_par mode 800x600
Console: switching to colour frame buffer device 100x37
usb 1-1.4.2: dlfb: set_par mode 800x600
usb 1-1.4.2: dlfb: DisplayLink USB device /dev/fb0 attached. 800x600 resolution. Using 1875K framebuffer memory

Jetzt ist die Ursache klar. Soviel ich verstehe, bedeutet die Anzeige «Unable to get valid EDID from device/display », dass das System irgendwelche Daten nicht bekommen hat um den Adapter für die korrekte Betriebmode des Monitors zu konfigurieren. Und der Monitor hat den vorgegebenen Modus gestellt.

Bestimmen wir den Modus selbständig. Dafür gibt es ein Dienstprogramm, das heisst fbset. Dieses Dienstprogramm gehört zu busybox OpenWrt inkludiert, aber es ist nicht bestimmungsgemäß gebrauchbar, weil es reduziert ist. Deshalb laden wir die Programmcodes fbset von der offiziellen Webseite herunter und stellen wir das Dienstprogramm selbständig unter Berücksichtigung der Verwendung vom Cross-Compiler bei der Zusammenstellung.

Um den Befehl fbset zu starten, braucht man die Datei fb.modes. Man kann sie von unserer Webseite herunterladen site.

Also, führen wir den Befehl aus:

root@OpenWrt:/# /home/fbset -fb /dev/fb0 -db /etc/fb.modes 800x600-75
usb 1-1.4.2: dlfb: open /dev/fb0 user=1 fb_info=c1da3000 count=2
usb 1-1.4.2: dlfb: set_par mode 800x600
usb 1-1.4.2: dlfb: release /dev/fb0 user=1 count=1

Da wir die Tastatur schon angeschlossen haben, drücken wir die Taste ENTER. Unser Monitor soll uns ungefähr Folgendes zeigen:

Draußen ist schon das Jahr 2011, aber dieses Ereignis hat mir ein Lächeln abgewonnen.

Starten wir den Muttermanager Midnight Commander.

Wer hätte gedacht, dass alles so leicht ist?

Als PS sind immer die letzten Versionen von Programmcodes zu verwenden ).

Ich habe die letyte Version von OpenWrt heruntergeladen und das Problem mit dem Fehler «Out of range» hat sich erledigt. Die Ausgabe von dmesg sieht jetzt wie folgt aus:

usb 1-1.4.2: new full speed USB device using ohci_hcd and address 6
usb 1-1.4.2: not running at top speed; connect to a high speed hub
udlfb: DisplayLink SUNWEIT USB Display - serial #500457
udlfb: vid_17e9&pid_024c&rev_0003 driver's dlfb_data struct at 81a5c800
udlfb: console enable=1
udlfb: fb_defio enable=1
udlfb: vendor descriptor length:e0 data:00 00 00 0000 00 00 00 00 00 00
udlfb: Unrecognized vendor firmware descriptor
udlfb: allocated 4 65024 byte urbs
udlfb: Unable to get valid EDID from device/display
udlfb: 640x350 valid mode
udlfb: 640x400 valid mode
udlfb: 721x400 valid mode
udlfb: 640x480 valid mode
udlfb: 640x480 valid mode
udlfb: 640x480 valid mode
udlfb: 640x480 valid mode
udlfb: 800x600 valid mode
udlfb: 800x600 valid mode
udlfb: 800x600 valid mode
udlfb: 800x600 valid mode
udlfb: 800x600 valid mode
udlfb: 1024x768 valid mode
udlfb: 1024x768 valid mode
udlfb: 1024x768 valid mode
udlfb: 1024x768 valid mode
udlfb: 1024x768 valid mode
udlfb: 1152x864 valid mode
udlfb: 1280x960 valid mode
udlfb: 1280x960 valid mode
udlfb: 1280x1024 valid mode
udlfb: 1280x1024 valid mode
udlfb: 1280x1024 valid mode
udlfb: 1600x1200 valid mode
udlfb: 1600x1200 valid mode
udlfb: 1600x1200 valid mode
udlfb: 1600x1200 valid mode
udlfb: 1600x1200 valid mode
udlfb: 1792x1344 beyond chip capabilities
udlfb: 1792x1344 beyond chip capabilities
udlfb: 1856x1392 beyond chip capabilities
udlfb: 1856x1392 beyond chip capabilities
udlfb: 1920x1440 beyond chip capabilities
udlfb: 1920x1440 beyond chip capabilities
udlfb: Reallocating framebuffer. Addresses will change!
udlfb: 800x600 valid mode
udlfb: set_par mode 800x600
udlfb: open /dev/fb0 user=0 fb_info=80d93c00 count=1
udlfb: set_par mode 800x600
Console: switching to colour frame buffer device 100x37
udlfb: set_par mode 800x600
udlfb: DisplayLink USB device /dev/fb0 attached. 800x600 resolution. Using 1880K framebuffer memory

Die Informationswert der Ausgabe ist höher geworden, aber das Problem mit «Unable to get valid EDID» wurde nicht gelöst. Ich nehme an aber, dass die Default Konfiguration, welche der Adapter im Falle der Nichtfindung von EDID bekommt, korrigiert wurde.

Die Konsole wird in der virtuellen Frame Buffer Konsile in der neuen Version nicht automatisch gestartet. D.h., wir sehen einen grünen Displaz auf dem Monitor. Es könnte sein, ich hätte meine Darlegung mit diesem Fakt begonnen sollen.

Das grüne Display auf dem Monitor bedeutet beim Anschließen vom Displaylink Adapter, dass der Adapter korrekt initialisiert und definiert im System wurde. Es ist jetzt zu verstehen, warum die Konsole nicht gestartet wurde.

Prüfen wir folgende Informationen.

Prüfen wir, ob die Datei fb im Verzeichnis /dev vorhanden ist:

root@OpenWrt:/# ls /dev/fb*
/dev/fb0

Prüfen wir, ob die virtuelle Konsole des Frame Buffers erstellt wurde:

root@OpenWrt:/# ls /sys/class/vtconsole/vtcon*
/sys/class/vtconsole/vtcon0:
bind name subsystem uevent

/sys/class/vtconsole/vtcon1:
bind name subsystem uevent

Die Konsole wurde erstellt. Prüfen wir, ob sie dem Frame Buffer nämlich gehört:

root@OpenWrt:/# cat /sys/class/vtconsole/vtcon1/name
(M) frame buffer device

Prüfen wir, ob sie verbunden ist:

root@OpenWrt:/# cat /sys/class/vtconsole/vtcon1/bind
1

Hier ist auch alles OK. Dann machen wir die Textdatei mit der Treiberbeschreibung auf:
/trunk/build_dir/linux-brcm47xx/linux-2.6.37/drivers/staging/udlfb/udlfb.txt.

Folgende Zeilen machen alles klar: «Allow fbcon to attach to udlfb provided framebuffers. This is disabled by default because fbcon will aggressively consume the first framebuffer it finds, which isn't usually what the user wants in the case of USB displays»

Versuchen wir die vorgeschlagene Lösung anzuwenden:

root@OpenWrt:/# modprobe udlfb defio=1 console=1

Was mich angeht, hat diese Lösung mir nicht geholfen )). Vielleich darum, dass das Dienstprogramm Modprobe wieder reduziert war. Deshalb ist es einfacher die Ausgangsdatei udlfb.c zu öffnen und direkt in dieser Datei die Default Werte für diese 2 Variablen anzugeben:
/* module options */
static int console=1; /* Optionally allow fbcon to consume first framebuffer */
static int fb_defio=1; /* Optionally enable experimental fb_defio mmap support */

P.P.S.: Die Prüfung der Operationsgeschwindigkeit des Systems ist notwendig, natürlich nicht mit dem Programm mc. Beim Programmstart vom mc hat das System dies nicht "gespürt".

Bestellen einen USB2VGA Displaylink Adapter bei uns:

USB2VGA Displaylink Adapter