Hi all, As for the what standard to implement. VESA VBE 2.0 would be perfect, 3.0 brings a possibility to compute your own "modeline" with GTF and clockchip function. I think "must have" for linux would be "no-vesa" only basic INT 0x10 funcs. For windows I think we will need VESA 2.0 or 3.0. Powermanagement can be 1.0+, VESA DDC/EDID stuff is also good to have. This leads to questions about VGA BIOS ROM size. Common was 32KB, but I guess today they are bigger. 32KB is not so much space for all stuff like font maps etc. Is there some plan on this? (or did I missed it :) ?)
As for the rest, I went through the text with wordcat and grep :) So here are results: I found PC 2001 Design guide. There is one file 08grafx-2001.doc called Chapter 8 Graphics Adapters. It tells some more remarks about 3D etc... More on 3D is also in previous documents. http://www.microsoft.com/whdc/system/platform/pcdesign/desguide/pcguides.mspx Relevant parts to VESA BIOS PART: The adapter must support the DDC2B host requirements identified in the VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1, which defines the communication channel between the display and host system. The software can use this i nformation to properly manage output to the various displays and to prevent the disabling of television output if no monitor is attached. Devices capable of multihead display must support this feature for all attached monitors. Graphics adapter complies with VBE/Core 2.0 extensions for power managemen System BIOS supports large frame buffers for graphics adapters And from previous documents: 32-bit system BIOS supports large frame buffers for graphics adapter or chipset The system BIOS must support large frame-buffer graphics hardware that has up to 256 MB of frame buffers. The system BIOS must make available a frame buffer size of at least 256 MB. VESA BIOS Power Management Functions (VBE/Core Functions 2.0), which defines extensions to VGA ROM BIOS services for power management. DVI HPD is covered in the VESA Plug and Play (PnP) Standard for the Display/Graphics Subsystem, Release A. The display adapter or chipset must meet VESA specifications for ergonomic timing rates as described in Generalized Timing Formula (GTF), Version 1.1. Display adapters or chipsets must support I2C bus management on all video outputs whose video interfaces support I2C as specified in the VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1.0, which defines the communication channel between the display and host system. The adapter must support at least the DDC/CI level of functionality. The host CPU must be given the option of controlling the external I2C bus on all such video outputs by using software so that, at a minimum, the CPU can acquire the monitor descriptor (such as VESA E-EDID). Mobile devices that expose a VGA port must still support I2C bus management. The display adapter or chipset must support standard VGA. If necessary the device must be able to reset to standard VGA from high -resolutions. The hardware and BIOS must support VESA modes to allow at least the minimum desktop resolution for Windows using the system VGA driver. VESA Computer Display Monitor Timing Specification, Version 1, Revision 0.8 VESA Display Data Channel Command Interface (DDC/CI) Proposal, Version 1.0 VESA Enhanced Extended Display Data Channel Standard (EDDC), Version 1 VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release A VESA Generalized Timing Formula (GTF), Version 1.1 VESA Monitor Control Command Set (MCCS) Standard, Version 2.0 Offtopic to GPU design: GPU can blit from video memory to page locked WC system memory The GPU must be able to blit from video memory to page-locked WC system memory, including AGP memory or PCI Express memory aperture Aero Glass-capable GPU can process fence commands in the command queue When the hardware consumes a fence command, it must notify the operating system by triggering an interrupt to the CPU, with the fence ID communicated to the ISR. Aero Glass-capable GPU can be reset The hardware must be able to be reset to an initial power-on state by using memory-mapped I/O, independent of what the hardware is processing at any time. The graphics driver must be able to reset itself after the system notifies it of a hang condition. An interruptible GPU stops at a predetermined, fixed interval and persists state when interrupted If the GPU is interruptible it must be able to stop within a fixed interval. This interval may be time variable, but must be at some predefined level of granularity, for example at mid-pixel or mid-triangle. A noninterruptible GPU must be able to stop as soon as its internal hardware state is at a point that can be persisted. Interruptible GPUs must be able to persist their state when interrupted for a context switch and if they receive a request to do so. Regards Rudolf _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
