On Sun, 21 Jul 2019, Jd Lyons wrote:
My resulting EDID was only 172 bytes long, I’m not sure that’s correct?
Probably not, you should have the same amount of bytes as the device tree dump you quoted earlier. Actually you could just use that edid blob as that's from a valid monitor and frequencies really don't matter and the resolutions are standard so it would work the same I think.
qemu-edid | od -t x1
0000000 00 ff ff ff ff ff ff 00 49 14 34 12 00 00 00 00 0000020 2a 18 01 04 a5 28 1e 78 06 ee 91 a3 54 4c 99 26 0000040 0f 50 54 21 08 00 e1 c0 d1 c0 01 01 01 01 01 01 0000060 01 01 01 01 01 01 25 20 00 66 41 00 1a 30 00 1e 0000100 33 40 93 2e 11 00 00 18 00 00 00 fd 00 32 7d 1e 0000120 a0 78 01 0a 20 20 20 20 20 20 00 00 00 fc 00 51 0000140 45 4d 55 20 4d 6f 6e 69 74 6f 72 0a 00 00 00 f7 0000160 00 0a 00 4a a2 24 29 20 00 00 00 00 00 00 01 19 0000200 02 03 0a 00 45 7d 65 60 59 1f 00 00 00 00 00 00 0000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 0000400
I realize the left hand coelom is offsets, not part of the EDID data, I’m not sure about the *, did that clip a bunch of zero’s, leaving me with 172 bytes rather than 256?
Yes the * omitted some all 0 lines, but as I said:
On Jul 21, 2019, at 10:42 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
On Jul 21, 2019, at 8:53 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
You only need the first 128 bytes because that's what drivers look at. Then you would need to add this to device-tree somehow, probably the same way as FCode adds NDRV.
But I don't think it would make a difference, I don't think it's the missing EDID is what prevents it from working. Have you tried all other ATY,* properties that are easier to add from the command line before trying EDID?
Regards, BALATON Zoltan