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.
“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” - Wikipedia.
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.
Each board has it's own way to access EDID.
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.
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.
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.
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:
service up /usr/sbin/fb -dev /dev/fb0 -args edid.${minor}=${label_of_driver_with_edid}
The minor number is included because, in the future, one might want to support multiple frame buffer devices (dual monitors).
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.
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 here.