I see. Could you recommend me a fine EDID reader, from which I could find the needed values easily? I mean I got some EDID info, but there was no such thing as HSync Pulse Width for example. Or there may have been but under a different name and I didn't know what that was...
Use MonInfo, from EnTech. It's phenomenal, and includes not only the parsed data but the original raw EDID stream as well.
The DTD information spat out by EDID and inserted into the Intel driver .INF file is in the following 18-byte hexadecimal format:
01 1D 80 18 71 1C 16 20 58 2C 25 00 10 44 42 00 00 9E
This starts in the 55th byte of the EDID stream, and there can be up to 2 more (starting at the 73rd and 91st bytes). You can check to see if there are more by looking around the 73rd and 91st: if you see 00 00 00 F[something], it's not a new DTD, it's other data.
byte 1,2: hexidecimal pixel clock rate in 10kHz, reversed byte order01 1D
byte 3, 4, 5: Horizontal active and blanking. Byte 3 is the bottom half of the resolution, byte 4 is the bottom half of the blanking, and byte 5 is the top of both. 80 18 71
horizontal rez (1920 decimal), 118
blanking (280 decimal)
byte 6,7,8: vertical active and blanking. Byte 6 is the bottom half of the resolution, byte 7 is the bottom half of the blanking, and byte 8 is the top of both. 1C 16 20
vertical rez (540 decimal), 016
blanking (22 decimal)
Here's where is gets confusing... The lower part of the Hsync offset is stored in byte 9, the lower part of Hsync pulse width is in 10... and the upper part of each is stored in two bits of byte 12. Luckily the upper part is usually zero.
byte 9, 10 ..1258 2C
0 --> 058
Hsync offset (88 decimal), 02C
Hsync pulse width (44 decimal)
To add more confusion, the bottom half of Vsync offset Vsync pulse width are stored together in byte 11, and the upper half of both is stored in the remaining bits of byte 12. Again, the binary-impaired are fortunate in that usually this is zero and we don't have to convert hex to bin:
byte 11, 1225
vsync offset, 05
vsync pulse width
The rest you really shouldn't care too much about, except the final byte, byte 18. Then you have to convert to binary, alas. The secret decoder ring is:
bit 7 : 0 for progressive, 1 for interlaced
000 = No Stereo
111 = Side By Side
110 = 4-Way Interleave
101 = 2-Way Left Image
011 = 4 Way Right Image
100 = Seq. Stereo, left sync
010 = Seq. Stereo, right sync
11 = Digital Separate
10 = Digital Composite
01 = Bipolar Analog Composite
00 = Analog Composite
vertical polarity (0 for negative, 1 for positive)
horizontal polarity (0 for negative, 1 for positive)
So for this example EDID we have
9E = 10011110
Which is interlaced (bit 7=1
), no stereo (bits 6:5,0=000
), digital separate sync (bits 4:3=11
), vsync+ (bit 2=1
), hsync+(bit 1=1
Note that in the Intel driver .INF file, a couple extra bytes are tagged onto the end. They don't seem to do anything, so either leave them blank or keep them from the original values listed in the file.
So... if you want to reverse engineer a new DTD from information you have from a working Modeline, you can do so, and then stuff it into the Intel driver. Easiest would be to just grab it from the EDID, as people soon discover, the EDID does not always work right off the bat and tweaking must ensue. Plus, this enables you to do resolution-within-resolution. It's painful, and no PowerStrip. But it enables tweaking, for those with a monitor they really, really want to run at native rez and whose drivers are not cooperating on discovering this.
Edited to add pretty colors. Hopefully they add clarity, as well.