User:Combuster/UDI Graphics
While this may be hijacking of the OS development wiki for now, its imo the best place for collaborative editing and public scrutiny.
Long story short, the last revival of UDI led to a movement that would be trying to make it viable - initially with hobbyist drivers, but also for a larger audience when it does pick up. I was invited (and I agreed) to draft a specification for an UDI sub-protocol, targeted at graphics drivers.
Please add comments - they can be used for error checking now, and as a justification later
Things the video card might support
There is only one "standard" video analogy that is in common use - http://wiki.osdev.org/index.php?title=User:Combuster/UDI_Graphics&action=editthe framebuffer. It is not alone however, there are still many devices that do not comprise a square grid of pixels, like text LED/LCD displays. And even when you do have a square array of pixels, it might not be possible to address and control each pixel individually and freely. The latter is especially the case in the default video mode during boot of desktop hardware - text mode. Also, in the console market tile-attribute engines are not uncommon - in fact they are the bigger brothers which have sprite engines. They have a certain amount of freedom in the location of images compared to the fixed grid of a tile-only engine, but lack the freedom that is provided by framebuffer engines.
A graphics device can thus be in either of two modes: - Tile mode (potentially with attributes, potentially with sprites. The screen is composed of a placement of preselected images) - Framebuffer mode (where each pixel can be addressed individually) A device supports at least one, it may support both.
Graphics hardware serve no purpose if the result is not available to the user. Any device should thus have at least one output. On a desktop video card, the output is connected through a connector on the rear, VGA was the standard for desktop hardware, DVI is the current. The choice is however not limited to these two. Industry video standards include PAL and NTSC, which are used in TV, and their data is transmitted in a signal of various forms: RF, composite, component, HDMI amongst others. A device has a number of outputs, each with a transfer type attached. Some connectors (DVI/SCART) allow video data to be transferred in multiple formats. That implies there is no 1-on-1 mapping between connector types and signal types. When enumerating the outputs, the information returned should contain the type of connector, and the signal used over the connector. Depending on the signal, sideband data may also be transferred - it may be DDC for VGA (with the purpose of identifying and manipulating the attached monitor), it may be audio (for HDMI, DVI, SCART, RF), it may be USB (DVI). The interface should thus support various combinations of side channels. Some video-related sidechannels should be included in the graphics specification.
A graphics device has one or more outputs, each has a connector type (which is constant over time), and a signal type (which is variable). The connectors to include are: - VGA - DVI - S-video - Component - Composite - RF - SCART - HDMI - Hidden (when there is no physical connector, such as laptop screens)
The signals they carry - RGBHV (VGA, DVI-A) - RGBS - RGsB - YPbPr (Which is the common "Component" signal) - DVI-D - Composite YUV (PAL) - Composite YIQ (NTSC) - HDMI - Internal (used only with hidden connectors)
Based on the signal and connector, software using the device may base choices such as resolution. Software may also change the signal used on each connector when applicable. Important to note is that this excludes the capabilities of the receiving end.