Edid is invalid if x resolution >= 2304

[golopot]

I met this error when I make with a modeline with resolution of 2304x1296.

$ make
edid.S: Assembler messages:
edid.S:171: Warning: value 0x101 truncated to 0x1
edid.S: Assembler messages:
edid.S:171: Warning: value 0x101 truncated to 0x1

edid.S line 171 :

std_xres:	.byte	(XPIX/8)-31

It seems that what happens is that when XPIX (x resolution) is >= 2304, (XPIX/8)-31 will be >= 0x101, which does not fit inside a byte.

[johnr14]

Trying to make a EDID for a Samsung Odyssey + VR HMD with

# 2880x1600 @ 90.00 Hz (GTF) hsync: 151.56 kHz; pclk: 606.24 MHz Modeline "2880x1600_90.00" 606.24 2880 3120 3440 4000 1600 1601 1604 1684 -HSync +Vsync

And have same error.

cc -c -DCRC="0x00" -o 2880x1600.o 2880x1600.S
edid.S: Assembler messages:
edid.S:171: Warning: value 0x149 truncated to 0x49
objcopy -Obinary 2880x1600.o 2880x1600.bin.nocrc
cat 2880x1600.bin.nocrc | edid-decode \
        | sed -ne 's/^[ ]*Checksum: 0x\w\+ (should be \(0x\w\+\))$/\1/p' >2880x1600.crc
cc -c -DCRC="$(cat 2880x1600.crc)" -o 2880x1600.p 2880x1600.S
edid.S: Assembler messages:
edid.S:171: Warning: value 0x149 truncated to 0x49
objcopy -Obinary 2880x1600.p 2880x1600.bin
objcopy -Oihex 2880x1600.p 2880x1600.bin.ihex
dos2unix --quiet 2880x1600.bin.ihex
rm 2880x1600.o 2880x1600.bin.nocrc 2880x1600.crc 2880x1600.p

[newperson1746]

2304x1080 was the limit for 165mhz pixel clock. hmmm...

[newperson1746]

limit of edid 1.3 spec: "Standard Timings shall not be used to define video timing modes with horizontal addressablepixel counts greater than 2288 pixels.In this case, the video timing mode shall be defined using the Detailed Timing Definition (Section 3.10.2) or the CVT Definition (Section 3.10.3.8)."

From EDID 1.4 spec at https://glenwing.github.io/docs/VESA-EEDID-A2.pdf
In other words, need to use detailed timing descriptor NOT standard timing to implement xres greater than 2288 pix

[yvvas]

I am also seeing this problem with a DQHD 5120x1440p monitor.

Warning: value 0x261 truncated to 0x61 because it's just way too wide

edid-decode claims EDIT length 130 is not a multiple of 128

[gknapp]

On a 4K TV (LG):

cc -c -DCRC="0x00" -o 3840x2160.o 3840x2160.S
edid.S: Assembler messages:
edid.S:171: Warning: value 0x1c1 truncated to 0xc1
edid.S:180: Warning: value 0x1166b truncated to 0x166b
objcopy -Obinary 3840x2160.o 3840x2160.bin.nocrc
cat 3840x2160.bin.nocrc | edid-decode \
	| sed -ne 's/^[ ]*Checksum: 0x\w\+ (should be \(0x\w\+\))$/\1/p' >3840x2160.crc
cc -c -DCRC="$(cat 3840x2160.crc)" -o 3840x2160.p 3840x2160.S
edid.S: Assembler messages:
edid.S:171: Warning: value 0x1c1 truncated to 0xc1
edid.S:180: Warning: value 0x1166b truncated to 0x166b

Produced with the following mode line:

Modeline "3840x2160" 712.75 3840 4160 4576 5312 2160 2163 2168 2237 -hsync +vsync

[bxabi]

I have the same problem, trying to build edid for:
Modeline "2560x1440" 220.812 2560 2608 2640 2720 1440 1443 1448 1478 -hsync -vsync

Did you find a solution?

[gknapp]

I have the same problem, trying to build edid for: Modeline "2560x1440" 220.812 2560 2608 2640 2720 1440 1443 1448 1478 -hsync -vsync

Did you find a solution?

No, unfortunately not. I'm living on 30Hz on this display - despite it being a recent card, AMD 6600

[mzpqnxow]

Same issue here for Dell 6k (6144x3456) monitor

I tried to hand-patch a la:

diff --git a/edid.S b/edid.S
index ef082dc..cc5639b 100644
--- a/edid.S
+++ b/edid.S
@@ -168,7 +168,7 @@ estbl_timing3:      .byte   ESTABLISHED_TIMING3_BITS
 
 /* Standard timing */
 /* X resolution, less 31, divided by 8 (256-2288 pixels) */
-std_xres:      .byte   (XPIX/8)-31
+std_xres:      .short  (XPIX/8)-31
 /* Y resolution, X:Y pixel ratio
    Bits 7-6    X:Y pixel ratio: 00=16:10; 01=4:3; 10=5:4; 11=16:9.
    Bits 5-0    Vertical frequency, less 60 (60-123 Hz) */
@@ -177,7 +177,7 @@ std_vres:   .byte   (XY_RATIO<<6)+VFREQ-60
 
 descriptor1:
 /* Pixel clock in 10 kHz units. (0.-655.35 MHz, little-endian) */
-clock:         .hword  CLOCK/10
+clock:         .long   CLOCK/10
 
 /* Horizontal active pixels 8 lsbits (0-4095) */
 x_act_lsb:     .byte   XPIX&0xff

However, this produces a 130 byte file (not a multiple of 128, which breaks the world)

I'm also not sure the calculations would be correct anyway - I didn't look to see the actual instructions using those variables

However, this may be on the right track if someone who also knows assembly and has the time to read the vesa/edid specs. From what I see in the comments, there are overflowed fields that are expected to be of a fixed length, and I'm not sure how to handle that ...

Would be nice if this had been written in C

[mzpqnxow]

Sounds like @newperson1746 has found the right spec and has described roughly what needs to be done from a logic perspective ...

[mzpqnxow]

#5 may be having the same issue ...

[mzpqnxow]

There is a patch to the edid generation that qemu implements here:

https://gist.github.com/knazarov/40348fe805fce1fdaada11c863380109

That doesn't solve the problem with edid-generator, but ripping that out of qemu may be a better solution than trying to patch this project