Video systems - the early days
Things began relatively simply in the early 1980s with just two options: a simple text-only monochrome video system, called MDA (Monochrome Display Adapter) or a rudimentary colour system, called CGA (Color Graphics Adapter). In those early days, IBM determined most of the development directions in the PC world; Apple were on a completely different path with their Apple II and Macintosh systems.
In 1984, IBM introduced a new video system to coincide with the release of the IBM PC/AT computer, creating yet another acronym: EGA (Enhanced Graphics Adapter). The new video system provided improved colour graphic capabilities and could also support the displays designed for the previous two systems. This presented a problem because although MDA, CGA and EGA displays all used the same type of connector, the video signals sent through them were different. Permanent damage could be caused to a monochrome display if connected to a controller that was sending out colour CGA or EGA signals. As there was no way for an EGA controller to determine which type of display was connected, the mode had to be set manually using miniature switches at the rear of the computer. This was prone to error and caused a good many technical support calls. A method was clearly required for the attached display to declare its capabilities to the video controller within the computer.
Three years later IBM, incorporated a solution to the problem into their next mainstream video system: VGA (Video Graphics Array). As well as the creation of new, higher resolution colour video modes, the VGA system specified a new style of video connector and added three identification pins to it. By sensing which pins had been connected to ground (within the display), the graphics controller could adjust its behaviour accordingly.
This was a significant improvement and meant an end to the cumbersome and mistake-inducing configuration switches. However, as a means of communication between display and computer, it was rudimentary and limiting. By the end of the decade, a significant split was occurring. IBM had been attempting to regain control of the market with its PS/2 range and a new high-end video standard called XGA (eXtended Graphics Array). The rest of the PC industry had other ideas and, thanks to the newly formed VESA group (Video Electronics Standards Association), a rival video design was available, called Super VGA.
Super VGA: IBM loses control
Super VGA (or SVGA) was the first major PC video system released to an open standard; published and available to all, rather than being developed by one company and then reverse-engineered by their competitors. Actually ‘standard’ is too strong a word for Super VGA. It was more of an umbrella term under which numerous developments could be made through a combination of common consent and/or commercial evolution. This was the point at which IBM lost its dominant role over the direction of new video standards; from now on development would be more akin to a democracy.
DDC and EDID emerge
Of the various changes that VESA put in place for Super VGA, an important step was to improve the manner in which the display communicates with the controller. Super VGA co-opted one of the identity pins from the original VGA specification and modified its use. Instead of merely presenting a static identification pattern, the connection was used to create a dynamic serial communications channel. This was called DDC (Display Data Channel) and the initial version provided a basic one-way communication route from the display to the controller.
The original DDC standard was superseded in the following years by a series of improved versions which are based upon a different serial communication method. The later versions allow an increased amount of data to be transferred and, in some variants, also permit two-way communication to enable the controller to adjust certain display settings. In partnership with the later DDC versions, a complimentary standard was also introduced to precisely define how the video display information should be structured. The standard is called EDID (Extended Display Identification Data) and it ensures that all display and controller manufacturers can agree on what each byte of information represents.
In combination, DDC (the link) and EDID (the content) have been highly successful in promoting essential dialogue between controllers and displays. Using this system, each display device and controller can automatically arbitrate and agree upon the most effective configuration to use.
In recent times DDC and EDID have been adopted by the high-resolution DVI (Digital Visual Interface) standard. They have also become an integral part of general system setup procedures (for DVI and SVGA systems) for two main reasons:
Firstly, with the advent of large LCD panels, new widescreen resolutions are becoming more prevalent and these require video controllers to significantly alter their output signals. To cater for larger and more complex displays, the later EDID versions provide greater memory space to allow more information to be declared to the video controller.
Secondly, many video controllers will no longer output any signal (or will drop down to a lower, default resolution) until a valid EDID identity has been received. This is fine when a display is connected directly to a computer, however, it can be problematic when a KVM switch is used to share a display between two or more computers. In such cases, only the currently selected computer would receive the much-needed EDID information as it was booting up.
Adder recognised this problem at an early stage, just as video controller manufacturers began to rely upon EDID inputs prior to output. As a result, all Adder video products designed since 2005 provide EDID Emulation as standard. This intelligent feature allows an Adder device to read the necessary details from a connected video display and then provide that EDID information at all times to all connected computers. If no new EDID information is available from a display, a default profile is automatically provided instead.
EDID Example
Below is an example of an EDID read from a DELL monitor, shown in hex.
2c 16 01 03 80 30 1b 78 ea 7c a5 a3 54 4e a0 27
12 50 54 a5 4b 00 71 4f 81 80 d1 c0 01 01 01 01
01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
45 00 db 0b 11 00 00 1e 00 00 00 ff 00 59 39 4b
43 48 32 41 56 31 5a 47 4c 0a 00 00 00 fc 00 44
45 4c 4c 20 55 32 32 31 32 48 4d 0a 00 00 00 fd
00 38 4c 1e 53 11 00 0a 20 20 20 20 20 20 00 8e
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
The information below has been extracted from the EDID data and presented it in a readable format. One point of interest is the detailed timing, which can refer to the Preferred Timing that the monitor is optimally set to use. In this case, the optimal resolution is 1920x1080. When building a KVM Matrix, it is important to consider the video resolution(s) and ensure that they are common to all the monitors used.
DEL code 61528, serial 1094013011, week 13, year 2014
EDID
rev 1, vers 3
Basic timing information
Digital;
Hor 48cm, Ver 27cm, gamma 2.2
STANDBY; SUSPEND; VLP; RGB; PREFTIME;
Colour Map
r_x 0.653 r_y 0.339
g_x 0.315 g_y 0.640
b_x 0.158 b_y 0.074
w_x 0.321 w_y 0.337
Established timings
720x400@70
640x480@60
640x480@75
800x600@60
800x600@75
1024x768@60
1024x768@75
1280x1024@75
Standard timing 1
1152x864@75
Standard timing 2
1280x1024@60
Standard timing 3
1920x1080@60
Standard timing 4
not used
Standard timing 5
not used
Standard timing 6
not used
Standard timing 7
not used
Standard timing 8
not used
Detailed timing 1
clk = 148.50Mhz
hora=1920 horb = 280 hso = 88 hs = 475 hb = 0 hsw = 44
vera=1080 verb = 45 vso = 4 vs = 267 vb = 0 vsw = 5
Non Interlaced
Non Stereo
SYNC Digital Separate; VSYNC pos; HSYNC pos;
Detailed timing 2
"Y9KCH2AV1ZGL"
Detailed timing 3
"DELL U2212HM"
Detailed timing 4
verical 56Hz to 76Hz; horizontal 30kHz to 83kHz; max clk 170MHz;
No ROM extention
ROM checksum = 8e