releases:3.2.1:developersguide:edidreading [Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

====== EDID Reading Internals ======

This page provides the official documentation for EDID reading in MINIX 3. It describes how EDID is read by the frame buffer driver from various sources. The current version documents code in git commit **26f14d6b** and later. If you update this document because of changes to MINIX 3, please mention the commit ID of the change in the wiki comment.


===== General Overview =====

"Extended display identification data (EDID) is a data structure provided by a digital display to describe its capabilities to a video source....The channel for transmitting the EDID from the display to the graphics card is usually the I²C bus" - [[http://en.wikipedia.org/wiki/Extended_display_identification_data|Wikipedia]].

===== General Design =====

The frame buffer driver (fb) will look for a provider of EDID. If one is available, fb will request/transfer the data, do validation, parse the data into "struct edid_info", and call a function in the arch specific part of the code to apply the EDID settings.

===== Providers of EDID =====

Each board has it's own way to access EDID.

==== BeagleBoard-xM ====

The 3rd I2C bus is connected, through a logic level translator IC, to the HDMI connector itself. It's possible to read the EDID info with the eeprom driver.

==== BeagleBone Black ====

Access to EDID is done through the TDA19988 HDMI Transmitter on the first I2C bus. The TDA19988 is pretty complicated and has it's own driver. It provides two I2C interfaces CEC (0x34) and HDMI (0x70). The driver accesses the CEC interface to enable the HDMI interface (which is disabled at power-up), sets up interrupts on the chip, initiates a transfer between the display and the chip, and then transfers data from the chip.

==== BeagleBone Black ====

There's no on-board video, but the DVI cape wires the 2nd I2C bus to the DVI connector. Again, the eeprom driver should be used for reading the EDID.

===== Finding the EDID Provider =====

As we've seen above, the driver with the EDID information will vary from board to board. Instead of hardcoding the logic into fb to decide where to read EDID from, the rc script just passes the label of the driver responsible for the EDID to the service command. Something like this:
<code>
service up /usr/sbin/fb -dev /dev/fb0 -args edid.${minor}=${label_of_driver_with_edid}
</code>
The minor number is included because, in the future, one might want to support multiple frame buffer devices (dual monitors).

===== Transferring EDID to FB =====

The EEPROM driver already implements the block device protocol, so we use that instead of coming up with a new message type, etc. To read EDID, fb just does a block device read request for 128 bytes from offset 0.

===== Leveraging Existing Code =====

NetBSD provides a set of functions for validating, parsing, and printing EDID. These have been imported into the Minix tree so that the FB driver can use them. Man page [[http://netbsd.gw.com/cgi-bin/man-cgi?edid++NetBSD-current|here]].
User Tools

Site Tools

Page Tools
