Document ID   Synopsis   Date
21423   How ffbconfig and other graphic card configuration tools determine the monitor resolution capability   24 Dec 1999


 

Description Top
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.

Applies To Hardware, Operating Systems/Solaris/Solaris 2.x
Attachments (none)
Document Content INFODOC ID: 21423