The below description relates to ffbconfig, but is also true of other
xxxconfig utilities that support DDC.
The monitor is interrogated by the OBP (Fcode PROM) at reset (init) time (e.g.
when you do reboot) via two (serial) lines (called DDC sense and clock lines)
connected to the monitor. Then the OBP (Fcode) puts the returned data on the
PROM device tree node for the device (e.g ..../ffb0) as a property called
edid_data, so that the kernel driver can later retreive this data (called edid)
and use it when a GETEDIDDATA or SETMODE ioctl is sent to it.
This edid data contains data pertaining to display monitor particulars, such as
supported resolutions/modes, etc.
ffbconfig in turn issues the GETEDIDDATA ioctl to the Kernel Driver to obtain
this data.
What is DDC?:
DDC (Display Identification Standard) is a VESA standard for obtaining information
from the monitor. DDC allows the frame buffer to read the monitor's information EDID.
This information entails resolutions supported, max width, max refresh, sync type and so
forth. DDC uses the protocol known as I2C (I squared C). For more information on I2C, look
in Phillips I2c handbook of Phillips Desktop Video Data Handbook.
I2C Bus:
I2C is a bidirectional two line bus. It uses external pull up resistors and allows either
the slave (monitor) or master (host) to pull down the signal. The maximum clock rate is
specified to be 100Khz.
What is DDC1/2/2B/2B+/2AB ?
DDC1 Uses vsync instead of SCL to transfer EDID data, unidirectional, point to point.
DDC2 Standard never implemented
DDC2B Uses I2C bus to read EDID, unidirectional, point to point. What Sun uses!
DDC2B+ Modification to DDC2B to allow bidirection interface, point to point.
DDC2AB Same as DDC2B+ but multi point. Other devices can be on bus.
* Bidirectional implementation allows monitor settings control from the host.
EDID 1.0/1.1:
The EDID information consists of 128 bytes of monitor data. Refer to the included list
for a summary. Both EDID versions 1.0 and 1.1 are supported in
pineapple (PGX/PGX8 8-bit only) and FFB2. The difference in these versions lies in the
detailed timings information section. Since we do not use the detailed timings, both
versions appear the same. Additional blocks of 128 bytes can be stored in EDID extension
blocks (aka VDIF) after the initial EDID block. These blocks contain addtional detailed
timing information. There is a flag within the EDID to indicate the existence of these
blocks. VDIF is not currently used in our systems.
Procedure for monitor initialization:
1) Read Sense Codes and set initial resolution to appropriate value
1a) If no sense code, use 1152x900x66
2) Read EDID 1.5 seconds after applying sync
2a) Use first standard timing id that matches a supported resolution
on the frame buffer (Look at list for matches)
2b) If no standard timings match, or no EDID present, use resolution
as determined in step 1
3) Look at NVRAM settings. If output_display = resolution, set resolution to
that value, else use results from EDID.
FRAME BUFFERS:
PGX:
Full DDC support
FFB:
FFB does not officially support DDC.
FFB2:
FFB2 does officially support DDC.
Clock stretching is not supported. The current FFB2
fcode does not support ack as either.
FFB2+:
Has full DDC support.
AFB:
Supports DDC based on RAMDAC. If it is a 49(7 or 8)+, it will have full DDC.