Re: Keine Grafikausgabe (weder an Textkonsole noch via X11)
Hallo $LISTE,
nun die vermutliche Auflösung des Rätsels, nach Kreuztausch mit einem
anderen DisplayPort-fähigen TFT und einem PC mit ähnlicher Grafikhardware:
Es scheint am TFT zu liegen.
Über DisplayPort spricht er EDID Version 1.4 und verhaspelt sich dabei
wohl, jedenfalls ist der Datenblock, den er da schickt, nur halb so lang.
Über HDMI spricht er EDID Version 1.3 und der Datenblock hat die
korrekte Länge.
Der andere TFT spuckt auch über DisplayPort mit EDID 1.4 einen
Datenblock in korrekter Länge und wird nicht dunkel; der andere PC am
ursprünglichen Monitor dagegen zeigt das gleiche Problem.
Meine Vermutung ist, dass die Grafikhardware/der Treiber wartet, bis das
Ende des EDID-Datenblocks erreicht ist, und irgendwie die
Ende-Markierung nie kommt. Durch das Aus- und Einschalten des TFTs
passiert dann irgendwas, was "hier kommt nichts mehr" signalisiert, und
dann nimmt das Gerät die Informationen, die es bis dato erhalten hat,
und arbeitet mit denen weiter. Da die passende Auflösung schon am Anfang
des EDID-Datenblocks steht, ist sie auch in diesem Fragment enthalten.
Deswegen kann danach das Bild angezeigt werden.
Lösung könnte sein, den EDID-Datenblock mittels get-edid einmalig über
HDMI auszulesen, als Datei in die initrd zu packen, und einen
entsprechenden Bootparameter zu setzen. Das muss ich aber noch ausprobieren.
Gruß
Stefan
Am 28.01.2018 um 16:49 schrieb Stefan Baur:
> [Jan Kappler, Martin Steigerwald, sorry, dass ich euch noch nicht
> geantwortet habe; ich versuche immer noch, Daten von unterschiedlichen
> PC-, TFT-, und Anschlusskabelvarianten zu sammeln und zu vergleichen.]
>
> Ein weiteres Update:
> Ich habe es mittlerweile auch mit Debian Stretch probiert.
> Hier ist die Situation noch krasser:
> Direkt nach dem Laden von Kernel und Initrd wird der Bildschirm dunkel,
> wenn er über DisplayPort angeschlossen ist.
> Über den DisplayPort->HDMI-Adapter besteht dagegen weiterhin kein Problem.
>
> Wenn ich dann abwarte, bis
>
> [ -d /sys/class/graphics ] && [ -c /dev/tty1 ] && [ -c /dev/vcs1 ]
>
> erfüllt ist, und via ssh folgende Befehle absetze:
>
> chvt 1 # kann man sich sparen, wenn kein X startet
> echo 1 >/sys/class/graphics/fb0/blank
> echo 0 >/sys/class/graphics/fb0/blank
>
> Dann ist anschließend das Bild wieder da.
>
> D.h. ich kann jetzt in ein Startskript, was möglichst früh ausgeführt
> wird, einbauen, dass ein Hintergrundtask gestartet wird, der so lange
> wartet, bis [ -d /sys/class/graphics ] && [ -c /dev/tty1 ] && [ -c
> /dev/vcs1 ] erfüllt ist, und dann die beiden echos abfeuert (bzw. eine
> for-Schleife für fb[0-9]* durchläuft und sie ggf. wiederholt, je ein Mal
> pro Device, abfeuert).
>
> Damit habe ich dann relativ zeitig wieder eine Bildschirmanzeige, und X
> startet danach auch normal, es kommt also nicht erneut zu einem dunklen
> Bildschirm.
>
> Aber mal ehrlich: Das kann's doch nicht sein?
> Mein Bauchgefühl sagt mir, keiner der Treiber-Entwickler für diese
> Grafikhardware hat das jemals mit DisplayPort und Atom/Celeron-CPUs
> getestet.
>
> Ein "Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated
> Graphics Controller (rev 06) (prog-if 00 [VGA controller])" tut
> wunderbar über DisplayPort, genauso wie über HDMI.
>
> "Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx
> Integrated Graphics Controller (rev 35) (prog-if 00 [VGA controller])"
> (zum Vergleich ebenfalls getestet) und "00:02.0 VGA compatible
> controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series
> Graphics & Display (rev 0e)" (das ist die problematische Hardware aus
> meinem Ursprungspost) haben dagegen das Problem, wenn sie über
> DisplayPort ausgeben sollen.
>
> Gruß
> Stefan
>
Reply to: