Schwarzer Bildschirm mit Debian Stretch & Buster in Verbindung mit Intel-Grafik, DisplayPort und TFT
Hallo Liste,
ich versuche nun schon eine ganze Weile, einen bestimmten TFT per
DisplayPort zu betreiben, ohne Erfolg.
Irgendwo in der Initrd macht es "zapp" und danach bleibt der TFT am 1.
DisplayPort-Ausgang schwarz, bis man ihn aus- und wieder einschaltet.
Ein parallel am 2. DisplayPort-Ausgang angeschlossener TFT zeigt dagegen
das Bild weiter an - allerdings manchmal in einer falschen Auflösung.
Das Gerät hat wirklich 2 separate DisplayPort-Ausgänge, ich verwende
also kein Y-Kabel oder DaisyChaining oder so.
Der gleiche TFT funktioniert wunderbar, wenn man ihn über einen
billigen, passiven DisplayPort-HDMI-Adapter an das Gerät anschließt:
Dabei wird der DisplayPort-Ausgang des Geräts weiter benutzt, aber der
HDMI-Eingang des TFTs. (Umgekehrt geht nicht, das Gerät hat nur DP-Out).
Genauso funktionieren TFTs anderer Hersteller per DisplayPort wunderbar
an diesem Gerät.
Was mich besonders stutzig macht: Gerät und TFT sind vom selben
Hersteller, man sollte doch erwarten können, dass die miteinander
harmonieren (wurden $DAMALS als Bundle verkauft).
"Schuld" ist wohl das mit Stretch eingeführte "Early KMS".
Mit Jessie funktioniert es nämlich noch.
Gebe ich als Bootparameter "nomodeset" mit, kommt die Textkonsole auf
80x25 daher (wäre zu verschmerzen), es wird dann aber der VESA-Treiber
verwendet. Mit dem kann ich auch nur ein Display ansteuern.
So was wie "mach kein Early KMS, aber mach Late KMS" scheint es nicht
als Bootparameter zu geben.
Wenn Modesetting aktiv ist, und der Fehler auftritt, dass der 2.
(baugleiche) TFT eine andere Auflösung hat, dann sieht man den
Unterschied zwischen den beiden Dateien
/sys/class/drm/card0-DP-1/modes
/sys/class/drm/card0-DP-2/modes
Der benötigte Mode fehlt dann in /sys/class/drm/card0-DP-2/modes.
Tritt dieser Fehler nicht auf, der Bildschirm an DP-1 bleibt aber
trotzdem schwarz, so gibt es offenbar nichts, was den Unterschied
eingeschalteter Bildschirm/schwarzer Bildschirm dateimäßig greifbar
machen würde. Weder unter X noch an der Konsole.
Der "Schwarzzustand" beinhaltet ein ausgeschaltetes Backlight, trotzdem
sind /sys/class/graphics/fb0/blank bzw. xset -q -d :0 der Meinung, der
Monitor sei an.
Ich kann an der Konsole den Fehlerzustand beenden, indem ich:
chvt 1 # irgendein vt was halt nicht X ist
echo 1 > /sys/class/graphics/fb0/blank # mit Absicht alles blanken
echo 0 > /sys/class/graphics/fb0/blank # mit Absicht alles entblanken
bzw. in X
xset -d :0 dpms force off
xset -d :0 dpms force on
absetze - aber das kann ja wohl nicht die Lösung sein ... zumal zwischen
blank und unblank eine gewisse Zeit liegen muss, damit es wirkt.
Manchmal bis zu zweieinhalb Sekunden oder mehr.
Das ganze passiert mit einem Intel-Grafikchipsatz:
00:02.0 VGA compatible controller: Intel Corporation Atom Processor
Z36xxx/Z37xxx Series Graphics & Display (rev 0e) (prog-if 00 [VGA
controller])
Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series
Graphics & Display
Flags: bus master, fast devsel, latency 0, IRQ 88
Memory at 90000000 (32-bit, non-prefetchable) [size=4M]
Memory at 80000000 (32-bit, prefetchable) [size=256M]
I/O ports at 2020 [size=8]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: [d0] Power Management version 2
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [b0] Vendor Specific Information: Len=07 <?>
Kernel driver in use: i915
Kernel modules: i915
Beim Booten bekomme ich über netconsole manchmal
[ 29.806826] [drm:intel_dp_get_link_train_fallback_values [i915]]
*ERROR* Link Training Unsuccessful
[ 29.811941] [drm:intel_dp_get_link_train_fallback_values [i915]]
*ERROR* Link Training Unsuccessful
Googeln nach dieser Fehlermeldung führt zu diversen Bugreports wie
<https://bugzilla.redhat.com/show_bug.cgi?id=1570392>
<https://bugs.freedesktop.org/show_bug.cgi?id=107503>
<https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=107503&attachment=141051>
sowie dem Stichwort "LSPCON timeout" und dem Hinweis, es sei mit Kernel
4.20 behoben. Was leider so nicht stimmt - oder der Bug ist in neueren
Versionen wieder zurück, oder nur mit meinem Problem verwandt.
Debian Buster hat ja nur 4.19 im Repo, aber über Backports bekommt man
einen 5.6-Kernel. Mit dem habe ich getestet, und der Fehler tritt damit
seltener auf - aber er tritt weiterhin auf.
Besondere Schwierigkeit ist, dass es sich um ein Live-System handelt.
"Mal eben" einen neuen Kernel kompilieren und damit rebooten ist daher
nicht so einfach, man braucht den Kernel als binäres deb-Paket und kann
dann das Image neu bauen lassen.
Ich habe außer "nomodeset" auch noch diverse andere bootparameter
getestet, z.B. in Kombination diese hier:
i915.modeset=1 i915.enable_rc6=1 i915.enable_fbc=1
i915.enable_guc_loading=1 i915.enable_guc_submission=1 i915.enable_huc=1
i915.enable_psr=1 i915.disable_power_well=0 i915.semaphores=1
aber auch
drm.debug=0x1e
(was das DRM-Debugging einschaltet und bei dem anderen oben verlinkten
Bug angeblich so viel Verzögerung auslöst, dass er damit nicht mehr
reproduzierbar wäre)
aber leider ohne Erfolg. Mit dem 4.19-Kernel reproduzierbar Schwarzbild
beim Start, mit dem 5.6-Kernel nicht jedes Mal, aber doch immer wieder.
dmesg ist unauffällig:
dmesg | grep -E "drm|i915"
[ 5.595499] [drm] Replacing VGA console driver
[ 5.597378] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 5.597380] [drm] Driver supports precise vblank timestamp query.
[ 5.598155] i915 0000:00:02.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 5.605899] [drm] Initialized i915 1.6.0 20180719 for 0000:00:02.0 on
minor 0
[ 5.625964] fbcon: inteldrmfb (fb0) is primary device
[ 5.698812] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 63.632826] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops
i915_audio_component_bind_ops [i915])
Und jetzt weiß ich nicht weiter.
Hat jemand Ideen, Tipps was ich noch probieren könnte?
Irgendeine Datei, in der angezeigt werden könnte, dass das Display eben
doch ausgeschaltet ist, obwohl das System der Meinung ist, es sei an, so
dass man dem Ding wenigstens auf die Schliche kommen könnte und
geskriptet Gegenmaßnahmen ergreifen kann?
Irgendein Bootparameter, der mich das Early KMS abstellen lässt, aber
mir trotzdem modesetting für X und die Nutzung von 2 TFTs erlaubt?
Gruß
Stefan
Reply to: