DDDR/2 - 32-Bit Super VGA Display Driver

From EDM2
Jump to: navigation, search
Display Device Driver Reference
  1. 16-Bit VGA Display Driver
  2. 8514/A Display Driver
  3. 32-Bit VGA Display Driver
  4. 32-Bit Super VGA Display Driver
  5. SVGA Base Video Subsystem
  6. Physical Video Device Drivers
  7. Virtual Video Device Drivers
  8. Seamless Windows Support
  9. PM Palette Management Support
  10. Distributed Console Access Facility (DCAF)
  11. DBCS Video Driver Support
  12. Installing and Configuring Display Device Drivers
  13. Graphics Test Suites
  14. Display Test Tool
  15. VIDEOCFG.DLL Exported Functions
  16. VIDEOPMI.DLL Exported Functions
  17. VIDEO Protect-Mode Interface
  18. Data Types
  19. S3 Display Driver
  20. Notices
  21. Glossary

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

32-Bit Super VGA Display Driver

The 32-bit Super VGA display driver, like all display drivers, provides hardware- independence for OS/2 application programs needing to perform I/O to a display device. While the general architecture and functionality of the Super VGA driver are the same as the 32-bit VGA driver, there are differences between the two. This chapter concentrates on those differences. See 32-Bit VGA Display Driver for detailed information about 32-bit VGA display drivers.

Overview

The 32-bit Super VGA display driver dynamically supports the following chip sets:

Vendor Chip Set
ATI Technologies, Inc.** ATI28800
Cirrus Logic, Inc.** CL-GD5422 and CL-GD5424
Headland Technology, Inc.** HT209 (VRAM II)
IBM Corporation VGA 256C or SVGA-NI
Trident Microsystems, Incorporated** TVGA 8900B and 8900C
TSENG Laboratories, Inc.** ET4000
Western Digital Corporation** WD90C11 (PVGA1C), WD90C30 (PVGA1D), WD90C31 (in WD90C30 compatibility mode)

The hardware is queried at runtime, and separate code paths for each chip set are taken.

The Super VGA driver supports multiple resolutions for each chip set, including 640 x 480, 800 x 600, and 1024 x 768. Each of these resolutions is supported in 256-color mode. A separate driver is built for each resolution using conditional compilation.

The 32-bit Super VGA display driver also supports several new features:

  • OS/2 Presentation Manager (PM) Palette Manager
  • Two new background mix options:
    • BM_SRCTRANSPARENT
    • BM_DESTTRANSPARENT

These new functions permit transparent overlay and transparent underlay of BitBlt operations. See #New Background Mix Support for details.

32-Bit Super VGA Display Driver Architecture

The 32-bit Super VGA display driver consists of two components: IBMVGA32. DLL and IBMDEV32.DLL. This architecture was chosen to make the driver more easily portable among various hardware video cards. The device-independent functions of the driver are contained in the base DLL, IBMVGA32.DLL; the device-specific functions are contained in the device-specific DLL, IBMDEV32.DLL. In order to be used in the system, individual Super VGA drivers must be renamed to IBMDEV32.DLL when they are built.

The graphics engine calls entry points in both DLLs. The two DLLs also call exported entry points within each other. If you want to port this driver to other video cards, you must write code that supplies the functionality for the entry points in the device-specific DLL. Notice that fonts are now built in the separate DLL called DSPRES.DLL. The following figure shows the 32-bit Super VGA display driver architecture. PMGRE.png

Building the 32-Bit Super VGA Display Driver

The supplied display drivers can be built using the NMAKE Utility in the IBM Developer Connection Device Driver Kit for OS/2. (The NMAKE Utility is particularly useful in programs consisting of several source files because it builds only those components that have changed since the program was compiled last.) The following six drivers can be built from the same source set:

640 x 480 256 colors Debug version
640 x 480 256 colors Retail version
800 x 600 256 colors Debug version
800 x 600 256 colors Retail version
1024 x 768 256 colors Debug version
1024 x 768 256 colors Retail version

Each of the drivers supports all six of the previously-mentioned chip sets. The debug versions of each driver have enabled all code within the ifdef FIREWALLS conditional compilation, which provides some extra error checking and messages through the kernel debugger.

By default, all the drivers are built just by typing the NMAKE command. Individual drivers can be built by passing the following parameters to NMAKE:

NMAKE  [vertical resolution].[debug or retail flag]

for example:

NMAKE 768.ret
- builds the 1024 x 768 retail driver.
NMAKE 600.deb
- builds the 800 x 600 debug driver.
NMAKE 480
- builds both the debug and retail 640 x 480 drivers.
NMAKE retail
- builds all resolutions of retail drivers.

New Background Mix Support

The background mix, BM_SRCTRANSPARENT, is used in calls to GpiBitBlt and GpiDrawBits so that pels in a source bit map that match pels in the target presentation space background color are not copied to the output bit map. Where source bit-map pels match the background color, target bit-map pels are left unchanged, which provides a transparent overlay function.

The background mix, BM_DESTTRANSPARENT, also is used in calls to GpiBitBlt and GpiDrawBits, to permit pels from the source bit map to be copied to only the target pels that match the background color of the presentation space. Pels in the target are changed where the source bit-map pels match the background color of the target, thus providing a transparent underlay function.

OS/2 PM Palette Manager Support

The supplied driver supports the OS/2 PM Palette Manager, which is a set of application-level APIs that enable an application to change a video board's palette look-up table. Refer to PM Palette Management Support for additional information. The driver must deal with logical color tables (LCTs), as well as palettes, and must be able to convert between memory-memory, memory-screen, and screen-memory bit maps.

Screen bit-map pels are physical indexes into the hardware palette, whether you are dealing with a device context (DC) that is using a palette or an LCT.

Memory bit-map pels can be any of the following:

Logical indexes into a palette if you are dealing with a DC that is using a palette
Physical indexes into the device default palette if you are dealing with a DC that is using an LCT
Physical indexes into the hardware palette if you are dealing with a DC that is using a realizable LCT