elianda hat geschrieben:Und wenn man glaubt, damit wäre das EDID-Problem gelöst - falsch. Was machst Du denn, wenn die EDID Tabelle als maximale Werte Einträge hat, die kleiner sind als das, was der Monitor wirklich kann.
(Ich habe zufällig so einen Monitor)
Das Ergebnis ist, dass jede Software, die sich darauf verlässt dann z.B. nur 75 Hz bei 1600x1200 anbietet, obwohl der Monitor auch 85 Hz ohne Probleme kann.
Und oftmals ist die Software dann auch sehr hartnäckig, wie z.B. der NVidia-Treiber unter Windows.
Den 85 Hz Modus muss man dann als 'Vom Gerät nicht unterstützten' Modus manuell hinzufügen. Immer wenn man den Treiber updated, sind diese manuellen Einstellungen vergessen.
Welcher Monitor ist es denn?
Hast du die EDID selber darauf überprüft ob dort wirklich nur max. 75 Hz eingetragen sind?
Ich überprüfe es folgendermaßen: (mit folgenden x86-Opcodes
; Die EDID-Monitorinformationen beschreiben die Kapazität des Monitor und das Timing verfügbarer Videomodi.)
Code: Alles auswählen
Adresse Opcodes Mnemonic Beschreibung
Segment:Offset
----------------------------------------------------------------------
xxxx:0100 B8 0020 mov ax, 2000 ; Datensegment
xxxx:0103 8E D8 mov ds, ax
xxxx:0105 8E C0 mov es, ax
xxxx:0107 B8 4F15 mov ax, 4F15 ; DDC - READ EDID
xxxx:010A B3 01 mov bl, 1
xxxx:010C 33 C9 xor cx, cx
xxxx:010E 33 D2 xor dx, dx
xxxx:0110 BF 0000 mov di, 0000 ; EDID es:di 128 byte
xxxx:0113 CD 10 int 10h
xxxx:0115 66 B8 FD000000 mov eax, 0FD000000 ; Text-identifier V/H range
xxxx:011B BB 0036 mov bx, 36
xxxx:011E 66 3B 01 cmp eax, [di+bx] ; di+36h detailed timing #1
xxxx:0121 74 18 jz 013B
xxxx:0123 8D 5F 12 lea bx, [bx+12h]
xxxx:0126 66 3B 01 cmp eax, [di+bx] ; di+48h detailed timing #2
xxxx:0129 74 10 jz 013B
xxxx:012B 8D 5F 12 lea bx, [bx+12h]
xxxx:012E 66 3B 01 cmp eax, [di+bx] ; di+5Ah detailed timing #3
xxxx:0131 74 08 jz 013B
xxxx:0133 8D 5F 12 lea bx, [bx+12h]
xxxx:0136 66 3B 01 cmp eax, [di+bx] ; di+6Ch detailed timing #4
xxxx:0139 75 06 jnz 0141
xxxx:013B 8A 41 06 mov al, [di+bx+6] ; MAXHZ
xxxx:013E 8A 51 08 mov dl, [di+bx+8] ; MAXKHZ
xxxx:0141
Hierzu habe ich jetzt mal eine kleine Batchdatei geschrieben, damit jeder sich die
EDID-Daten holen und auf max.
HZ und max.
KHZ überprüfen kann:
(Die folgende Batchdatei kann z.B. als "EDID.bat" gespeichert werden.)
Code: Alles auswählen
@echo off
echo ecs:100>tmp.deb
echo B8 00 20 8E D8 8E C0 B8 4F 15 B3 01 33 C9 33 D2>>tmp.deb
echo ecs:110>>tmp.deb
echo BF 00 00 CD 10 66 B8 FD 00 00 00 BB 00 36 66 3B>>tmp.deb
echo ecs:120>>tmp.deb
echo 01 74 18 8D 5F 12 66 3B 01 74 10 8D 5F 12 66 3B>>tmp.deb
echo ecs:130>>tmp.deb
echo 01 74 08 8D 5F 12 66 3B 01 75 06 8A 41 06 8A 51>>tmp.deb
echo ecs:140>>tmp.deb
echo 08>>tmp.deb
echo g=cs:100 141>>tmp.deb
echo q>>tmp.deb
debug <tmp.deb >debug.tmp
del tmp.deb
type debug.tmp
del debug.tmp
Am Bildschirm wird ganz unten nun ungefähr folgende Ausgabe gemacht:
.....
AX=00
?? BX=3636 CX=0000 DX=00
?? SP=FFEE BP=0000 SI=0000 DI=0000
...............<--- Wir schauen uns diese Zeile etwas genauer an!
DS=2000 ES=2000 SS=
1537 CS=
1537 IP=0141 NV UP EI PL NZ NA PO NC
1537:0141 .......
Anstelle der orangen
?? befindet sich der hexadezimale Wert für max.
HZ und anstelle der blauen
?? befindet sich der hexadezimale Wert für max.
KHZ.
Anmerkung: Das funktioniert mit purem DOS und auch unter Windows 2000(aber nicht unter Windows XP) und benötigt einem 80386+.
Auch könnte ich das kleine Programm erweitern, so das eine fertige *.com-Datei daraus entsteht die beide Werte dezimal ausgibt, allerdings
sollte dieses Beispiel so kurz wie möglich bleiben und so habe ich mich für diese Variante entschieden. Eine Überprüfung ob der Monitor DDC
unterstütz wird in diesem Beispiel nicht vorgenommen.
BNC-Monitor-Kabel haben keine DDC-Leitung.
Kurze Erklärung zur Batchdatei:
In der Batchdatei befinden sich neben den bekannten Batch-Befehlen ausserdem verschiedene
x86-Opcodes in hexadezimaler Form.
Zusätzlich befinden sich dort Debug-Befehle. Beides zusammen wird mit dem Batch-Befehl "echo" ausgegeben und diese Ausgabe wird
dabei in eine Text-Datei(tmp.deb) umgeleitet. Nachdem in dieser "tmp.deb" alles eingetragen wurde, wird Debug gestartet und beim
Starten wird die "tmp.deb" mit übergeben, so das Debug die in der "tmp.deb" eingetragenen Debug-Befehle ausführt und damit die
Opcodes in den freien Ram-Speicher für uns einträgt. Danach werden die Opcodes im Speicher innerhalb von Debug ausgeführt.
Am Ende befinden sich in den CPU-Registern unsere gewünschten Ergebnisse die Debug am Bildschirm ausgiebt.
Umleitung:
Das erste "echo"-Zeile die umgleitet wird beinhaltet: "
ecs:100>tmp.deb" und damit wird eine neue Datei mit dem Namen: "
tmp.deb"
angelegt die zunächst diesen Inhalt bekommt: "
ecs:100". Mit den nun folgenden "echo"-Zeilen bspw. mit "
Byte Byte>>tmp.deb" werden
weitere Einträge in der "tmp.deb" zeilenweise angehängt. Debug nimmt nun die Einträge zeilenweise entgegen und führt die darin
enthaltenen Befehle so aus, als wenn sie innerhalb von Debug eingetippt werden.
Quellen:
Eine Erklärung für
Umleitungen und Pipes findet man hier:
http://www.o-bizz.de/qbtuts/omastut/kap23.htm
Die verwendeten
Debug-Befehle findet man hier erklärt:
http://www.armory.com/~rstevew/Public/T ... anual.html
Eine Tabelle der verwendeten
x86-Opcodes findet man hier:
http://ref.x86asm.net/coder32.html
Die betreffenden
Public-Dokumente für EDID/DDC findet man hier(Login erforderlich):
http://www.vesa.org/Standards/free.htm
EEDIDguideV1.pdf
EEDIDverifGuideRa.pdf
Dirk
) Mit der Schnittstelle habe ich auch schon tolle Sachen erlebt... Aber immerhin noch besser als Funk (Bluetooth und Konsorten). Aber wer weiß, vielleicht kann USB 3.0 denen ja bald das Wasser reichen in Sachen Unausgereiftheit.