EDID support (monitor auto-detection)

RE: EDID support (monitor auto-detection)

In response to my email, John Ballance told me:

[…] I’ll have a think about decodeEDID

Have you at ROOL heard any thing since?

No. Although that was a simple bodge rather than the sort of thing we’d be after. I’ve worked with EDID in the past so I have some idea of what would need to happen. Simply getting hold of the spec (which costs $$$) was part of the battle. :) I may have a copy somewhere and there’s moderately good (reverse engineered?) documentation on the web anyway.

The NetSurf guys have lots of experience with this kind of thing too.

I know nothing about EDID so I can’t say how good the information is, but wikipedia has a page about it: http://en.wikipedia.org/wiki/Extended_display_identification_data

The app Castle used to generate MDF’s for the Iyonix was in two parts, there was an app to bit-bang i2c to fetch the 128 bytes of data to a file, then another app to decode the files (or generate arbitrary resolutions on request), this was based on using vesa standard timings for the reported modes, then calculated other modes from the extended info using GTF formula. Some of the MDFs created were used on the RPC too, but manual tweaking was often required to suit the hardware.

Am I correct in thinking that EDID data isn’t going to be a lot of use for the BeagleBoard as EDID only reports vertical frequencies of 60Hz and above (see in the EDID specs quoted in the URL that Rik has given – bytes 38-53 “standard timing identification” bit 5-0 Verical frequency ADD 60 to get actual value), whereas at eg 1920×1280 only frequencies of 30, 25 and 24Hz are possible with the BB which give a perfectly stable display on TV monitors like the Samsung SyncMaster 2333HD that I have and the model that RCOMP has found. (The data produced by the monitor give the lowest frequency as 60Hz)

So I hope that if EDID is implemented it is only to give information and not to limit the screen modes available.

The app Castle used to generate MDF’s for the Iyonix was in two parts, there was an app to bit-bang i2c to fetch the 128 bytes of data to a file, then another app to decode the files

GraphicsV already provides an interface to allow the raw EDID data to be read from an attached display (on both Iyonix & OMAP), so we don’t need to worry about that first part.

Am I correct in thinking that EDID data isn’t going to be a lot of use for the BeagleBoard as EDID only reports vertical frequencies of 60Hz and above

The various descriptor blocks and extension blocks allow for much more data to be reported, including min/max H & V frequencies.

So I hope that if EDID is implemented it is only to give information and not to limit the screen modes available.

That’s what I’m hoping as well. Although I can’t find any reference to it, I’m sure there have been instances where people have upgraded to newer versions of Select only to find that it won’t let their Viewfinder use some of the screen modes they used before because the driver strictly adheres to the modes/limits specified in the EDID data.