SunSolve Internal

Infodoc 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.