Advanced graphics driver architecture with extension capability

Abstract

Disclosed is a support architecture that facilitates use of display device drivers containing a minimum of hardware-specific software code. A driver need support only a relatively few common functions, which act as building blocks for the larger, more complex operations typically requested by graphics engines. In order to mediate between the limited-instruction-set device driver and the various higher-level graphics engines, the invention includes a series of translation modules that simplify engine-originated instructions into simpler graphic components. A video manager supervises routing of instructions to the specific drivers they designate, and serializes access to hardware components so that graphic commands execute atomically (i.e., without interruption). The invention also includes a graphics library containing device-level instruction sets, as well as the on-board capability to execute those commands, for a broad range of graphic operations; and allows driver capability to be expanded by means of add-on extension modules, which relieve the designers of the need to fully rewrite a driver to test or implement an expanded function set.

Claims

What is claimed is:

1. An apparatus for facilitating extension of processing capabilities associated with a device driver in a data processing system, the apparatus comprising:

a graphics adapter configured to process driver-output signals;

a device driver, associated with the graphics adapter, for (1) receiving graphics commands, said graphics commands including a function call belonging to either a first set or a second set of function calls, (2) processing function calls within said first set of function calls into driver-output signals, and (3) outputting function calls within said second set of function calls;

a device driver expansion module, uniquely associated with the device driver, wherein said device driver expansion module receives function calls within said second set of function calls from said device driver and processes said function calls within said second set of function calls into driver-output signals;

a video manager for (1) receiving graphics commands from a graphics engine, and (2) routing the graphics commands to the device driver for processing; and

a library of graphic functions, the video manager being configured to (1) locate, in the library, graphic functions corresponding to function calls, specified within graphic commands, that are not supported by any device driver in said data processing system, and (2) cause processing of the graphic functions into driver-output signals for processing by the graphics adapter.

2. The apparatus of claim 1, further comprising a computer memory, the first and second sets of function calls being stored as templates, accessible to the video manager, in the computer memory.

3. The apparatus of claim 1, further comprising an operating system that facilitates concurrent processing of a plurality of program threads, each graphic operation being a thread, and wherein the video manager ensures completion of each graphic operation without interruption by other threads.

4. The apparatus of claim 1, said apparatus further including at least one other device driver associated with the graphics adapter, said at least one other device driver being capable of processing a separate set of function calls into driver-output signals.

5. The apparatus of claim 1, wherein said video manager further comprises means for translating graphics commands having a first format into a second format prior to routing said graphics commands to said device driver.

6. An apparatus for outputting graphics function calls issued by at least one graphics engine, the apparatus comprising:

a frame buffer for storing an array of pixel values;

a video display having a visual appearance determined by the array of pixel values;

a graphics adapter coupled to the frame buffer and responsive to output signals, wherein the graphics adapter executes graphic operations represented by the output signals on pixel values in the frame buffer;

a device driver for (1) receiving graphics commands, said graphics commands including a function call belonging to either a first set or a second set of function calls, (2) processing function calls within said first set of function calls into output signals, and (3) outputting function calls within said second set of function calls;

a device driver expansion module, wherein said device driver expansion module receives function calls within said second set of function calls from said device driver and processes said function calls within said second set of function calls into output signals;

a video manager for (1) receiving a graphics command from a graphics engine, and (2) routing the graphics command to the device driver; and

a library of graphic functions, the video manager being configured to (1) locate, in the library, graphic functions corresponding to function calls, specified within graphic commands, that are not supported by any device driver in said data processing system, and (2) cause processing of the graphic functions into driver-output signals for processing by the graphics adapter.

7. The apparatus of claim 6 further comprising a position-sensing device for producing signals indicative of positions on the video display, the video manager further comprising means for operating the frame buffer to generate a pointer on the video display at the positions indicated by the signals.

8. The apparatus of claim 6, further comprising a system memory that includes a partition, accessible to the video manager, containing the sets of supported function calls.

9. The apparatus of claim 6, further comprising at least one translation module for translating at least some graphics commands received from a graphics engine into supported graphics commands, wherein said at least one translation module transmits said supported graphics commands to said video manager.

10. The apparatus of claim 6, wherein at least one said graphics engine includes (i) means for executing graphic operations on pixel values in the frame buffer and (ii) means for requesting access to the frame buffer, the video manager according the at least one said graphics engine exclusive access to the frame buffer in response to a request.

11. The apparatus of claim 6, wherein said video manager is implemented as a program object in an object-oriented environment, said apparatus further comprising a data structure stored in memory, wherein said data structure is associated with a graphics command and includes:

an identifier of a function call within said second set of function calls; and

an identifier of each region within said video display which is affected by said device driver expansion module.

12. The apparatus of claim 7 wherein the video manager maintains the pointer by overwriting pixel values in the frame buffer following execution of the graphic operations.

13. The apparatus of claims 9, wherein the supported function calls include bit block transfer and line drawing commands.

14. The apparatus of claim 10 wherein the video manager accords exclusive access to the frame buffer following complete execution of a graphic operation.

15. A computer program product for use in a computer system having a graphics adapter configured to process driver-output signals and a device driver, associated with the graphics adapter, for processing a first set of function calls into driver-output signals, the computer program product comprising:

a computer usable medium having computer readable program code embodied therein for facilitating the extension of processing capabilities associated with the device driver that is configured to process function calls within a first set of function calls into driver-output signals that drive the graphics adapter, the computer readable code including:

first program code, uniquely associated with the device driver, for processing function calls within a second set of function calls into driver-output signals;

second program code for managing video, said second program code including:

means for receiving graphics commands including a function call within said first set of function calls and said second set of function calls from a graphics engine;

means for causing said computer system to route said graphics commands to the device driver;

means for causing said device driver to route a function call to the first program code means for processing if the function call is a member of the second set; and

a library of graphic functions, the second program code being configured to (1) locate, in the library, graphic functions corresponding to function calls, specified within graphic commands, that are not supported by any device driver in said data processing system, and (2) cause processing of the graphic functions into driver-output signals for processing by the graphics adapter.

Description

FIELD OF THE INVENTION

This invention relates to graphics drivers, and in particular to an architecture for supporting different graphics subsystems and the various drivers usable therewith.

BACKGROUND OF THE INVENTION

Today even relatively modest personal computer systems have graphics subsystems that facilitate display of elaborate graphic patterns on a video or flat-panel display. The proliferation of applications generating such sophisticated graphics has engendered changes in the way computational responsibility for their actual rendering is allocated. In older systems, the main processor would perform all graphics processing (through a display controller) according to commands supported by the operating system--the software module responsible for managing the processing and transfer of information among various system resources. The desire for greater resolution and rendering capabilities eventually began to impose an excessive computational burden on the main processor, limiting overall speed and ultimately making this simple architecture obsolete.

System designers therefore began transferring graphics-processing tasks to separate graphics hardware boards, called "graphics adapters." These boards contain circuitry dedicated exclusively to drawing graphic patterns on the display, and support both high speed and fine resolution. The fact that their functional repertoires are fixed did not initially prove limiting, since board capabilities were matched to the commands recognized by the main operating system. Application programs requiring graphics operations passed task commands to the operating system, which executed them through the graphics hardware.

The recent advent of graphical user interfaces ("GUIs") has largely rendered this arrangement obsolete as well. GUIs provide a visual metaphor of a real-world scene, such as a desktop, featuring icons that the user can manipulate with a pointing device such as a mouse. GUIs operate at a hierarchical level above the operating system but below applications, from which they accept functional commands that include requests for graphics operations. GUIs offer the user a colorful graphic environment that is preserved across applications designed for the GUI; they also impose substantial graphics-processing demands, typically requiring sophisticated graphics subsystems that include an application-program interface ("API") and a graphics engine. The API layer translates application commands, which are written in a high-level language, to the high-level drawing commands supported by the graphics engine, a specialized component of the operating system. The graphics engine, in turn, processes the high-level drawing commands into lower-level drawing commands supported by a graphics device driver. The device driver, finally, processes the lower-level drawing commands into output signals that drive the graphics adapter, which performs the actual drawing operations on the display. (Typically, the instantaneous appearance of the display is determined by the bitwise or bytewise contents of a display or frame buffer; the graphics adapter draws patterns on the display by modifying bits in the buffer.)

For example, GUI environments such as that supplied with the OS/2.RTM. operating system, available from International Business Machines Corp., permit the user to perform various operations in separate rectangular screen windows. The windows have characteristic appearances (colors, borders, shading, etc.), and must also exist alongside other windows and screen artifacts. In order to spare designers of applications intended for use on such a GUI from rewriting the copious graphics instructions associated with windows rendering and management each time these operations become necessary, the API packages these into high-level commands. Thus, the designer need only enter a WinDrawBorder instruction (along with appropriate parameters, such as window size) in order to give the application the ability to draw a window border. The API maintains a library of graphics instructions associated with each high-level command, and imports these into the application program when it is compiled or run.

The GUI must also be compatible with numerous available hardware platforms and graphics adapters. This is facilitated by interposing a device driver, which directly controls the graphics hardware, between that hardware and the graphics engine. Device drivers are a common expedient in current computer systems, and contain processing logic for controlling the low-level or device-specific components of a particular computer resource. Each hardware configuration is provided with a different graphics driver capable of translating the common set of graphics-engine commands, or "primitives," into signals specific to the graphics hardware. This arrangement provides consistency at the operating system and GUI level.

Matters become complicated, however, in systems that support applications written for different GUIs. For example, the OS/2 operating system accepts "native" commands from applications written specifically for OS/2 as well as "foreign" commands directed toward the Windows GUI marketed by Microsoft Corp. This versatility is ordinarily implemented by the simultaneous presence, in computer memory, of the graphics subsystems associated with each of the supported GUIs and the graphics drivers with which they are ordinarily paired.

Without special modification, each driver would operate in its usual fashion, under the assumption that it "owns" the graphics hardware (and without regard to the fact that other drivers also reside in memory and might suddenly become active). Unfortunately, modifying a driver to cooperate with other drivers represents a non-trivial task, not only because of the growing complexity of graphics drivers, but also due to the lack of agreed-upon standard for inter-driver cooperation.

A final complication occurs when graphics boards are updated. These hardware devices are frequently produced by independent vendors, which sell them to computer manufacturers for installation on an original-equipment manufacture (OEM) basis. If the hardware is to run the full repertoire of graphics subsystem functions associated with every supported GUI, the drivers must ordinarily be rewritten with each new equipment release.

DESCRIPTION OF THE INVENTION

Advantages of the Invention

An advantage the present invention is simultaneous support of a plurality of graphics device drivers, any of which may be selected for immediate implementation of a desired graphics function and without special programming to prevent unwanted interaction.

Another advantage of the invention is reduction of driver complexity through reduction in the required number of supported graphics operations.

A further advantage of the invention is reduction in the number of drivers required to adapt a given graphics-processing board to a plurality of GUIs.

Still a further advantage of the invention is the ability to support a variety of operating systems and GUIs.

SUMMARY OF THE INVENTION

The present invention provides a support architecture that facilitates use of device drivers containing a minimum of hardware-specific software code without compromising overall graphics functionality, and which expressly provides for expansion of driver functionality without the need to fully rewrite the driver code. The overall approach of the invention is particularly useful in systems employing a plurality of graphics subsystems, since the driver need only support the set of graphic function calls common to all subsystems. These relatively few common functions act as building blocks for the larger, more complex operations typically requested by graphics engines. In order to mediate between the limited-instruction-set device driver and the various higher-level graphics engines, the invention includes a series of translation modules that simplify engine-originated instructions into simpler graphic components. A video manager supervises routing of instructions to the specific drivers they designate, and serializes access to hardware components so that graphic commands execute atomically (i.e., without interruption).

In addition, the invention includes a graphics library containing device-level instruction sets, as well as the on-board capability to execute those commands, for a broad range of graphic operations. In this way, if the translation module is unable to decompose an engine-originated instruction into operations the driver is capable of performing, the invention can utilize the library as a default; this ensures that all graphics requests will ultimately be serviced.

Since a device driver need support only a relatively few functions in order to operate successfully in the environment of the present invention, that environment is highly useful in driver design and development. The invention also allows driver capability to be expanded by means of add-on extension modules, which relieve the designers of the need to fully rewrite a driver to test or implement an expanded function set. Instead, the designer implements a "virtual" or extension driver module having the additional processing capability, and which the invention associates with the original driver. The video manager passes commands specific to the extension module directly to that module for execution.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing discussion will be understood more readily from the following detailed description of the invention, when taken in conjunction with the accompanying drawings, in which:

FIG. 1 schematically illustrates a representative hardware environment for the present invention; and

FIG. 2 schematically illustrates the components and operation of the present.

DETAILED DESCRIPTION

Refer first to FIG. 1, which illustrates the hardware environment in which the present invention operates. The depicted computer system includes a central-processing unit 15, which performs operations on and interacts with a main system memory 17 and components thereof. System memory 17 typically includes volatile or random-access memory (RAM) for temporary storage of information, including portions of the computer's basic operating system and graphical user interface (denoted collectively by reference numeral 19). The system typically also includes read-only memory (ROM) for permanent storage of the computer's configuration and additional portions of the basic operating system, and at least one mass storage device 21, such as a hard disk and/or CD-ROM drive. All components of the system communicate over a bidirectional system bus 23.

The user ordinarily interacts with the system as it runs one or more application programs 25, at least portions of which reside in system memory 17. As used herein, the term "application program" refers broadly to any body of functionality for processing information of interest to the user and presenting that information in a manner that involves graphics operations. While graphics processing is the primary focus of design applications such as drawing and computer artwork packages, even text and numerically oriented applications such as word processors and spreadsheets can have significant graphic components. This is especially true in the context of systems that include a graphically sophisticated operating system and GUI that make use of a dedicated graphics subsystem 30. (Although, as noted previously, the GUI ordinarily mediates between applications and the basic operating system, the functionality of graphic subsystems can be distributed between these components, and so the two are merged in the figure for simplicity of presentation.)

Graphics subsystem 30 includes an application program interface (API) 32, which translates high-level application instructions into commands within the repertoire of a graphics engine 34. Graphics engine 34, in turn, processes these commands into output signals conveyed to a display driver 36, which is matched to and drives a graphics adapter 38. This latter component, finally, directly affects the contents of a video display 39 (e.g., by setting the bitwise contents of a display buffer in memory 17). A system may support more than one GUI or at least accommodate more than one set of API commands. This may be accomplished using multiple APIs and multiple graphics engines, or a single engine 34 capable of processing the different outputs.

The user interacts with the system using a keyboard 40 and a position-sensing device (e.g., a mouse) 42. The output of either device can be employed to designate information or select particular areas of video screen display 39 when the user interacts with applications 25.

The present invention provides a facility for the development of display drivers and accommodation of drivers having limited output instruction sets by interposing a series of modules between graphics engine 34 and display driver 36. Such modules are illustrated in FIG. 2.

Essentially, the invention comprises an architecture that coordinates communication between each of what may be several graphics engines and the available graphics hardware via one or a plurality of device drivers representatively denoted by reference numerals 50a, 50b; like other elements of the invention, only a small number are actually illustrated in the drawing, the ellipsis notation indicating the possibility of additional such elements. Each device driver 50a, 50b generates output signals that drive an associated graphics adapter 38a, 38b. The graphics adapters are hardware video or graphics accelerator boards, well known in the art and undergoing constant development and improvement. A device driver is typically matched to a particular graphics adapter.

Each graphics adapter directly modifies the contents of a frame buffer 52 (generally through a dedicated graphics processor chip). Frame buffer 52 is typically a partition of memory 17 dedicated exclusively to video output, the instantaneous bitwise or (more typically) bytewise contents of which determine the pixel-by-pixel appearance of video display 39. As indicated by dashed lines, device drivers 50a, 50b can be configured to occasionally bypass graphics adapters 38a, 38b and write directly to frame buffer 52 (e.g., to quickly display a stored pixelmap).

Overall management of the invention architecture is controlled by a video manager module 55. This module recognizes a characteristic set of video-manager interface ("VMI") commands, which it utilizes to take various actions and generate graphics hardware interface ("GHI") commands recognizable to a selected device driver. The VMI commands thus represent a set of functions that include commands common to a variety of graphics engines.

If a device driver has not been provided with the ability to execute a particular GHI command, it can send manager 55 a "simulation request," causing it to perform the designated graphics function directly. Manager 55 carries out simulation requests by accessing a stored library 60 of graphics functions. Library 60, retained permanently on a mass storage device 21 but cached in system memory 17 during operation for rapid access, represents a generic library of standard graphic functions (along with the instructions necessary to execute those operations) that may be called by manager 55 for direct execution. For example, library 60 may contain routines that perform basic bit-transfer and line-drawing operations, as well as graphic elements stored in bitmap form; in response to a simulation request, manager 55 can perform the requested operation directly or locate the proper bitmap and cause its transfer directly to frame buffer 52.

Alternatively or in addition, manager 55 can be provided with command templates, stored in partitions of system memory 17, which specify the set of commands recognized by each of device drivers 50a, 50b. If an incoming function request does not correspond to a command in the template of a selected device driver, manager 55 can be configured to implement the function directly (by accessing an appropriate entry of library 60) without waiting for a simulation request from the device driver. (As discussed below, manager 55 can also use the template to select the optimal one of a variety of device drivers to execute the command.)

Requests for graphic functions originate with one or more graphics engines 62a, 62b, 62b. Each of these may represent a separate operating system supported by the computer, or emulations of different operating systems. For example, an operating system may utilize a "microkernel" that supports operation of various "personalities," each of which replicates the behavior of a different operating system (such as AIX) or GUI (such as XWINDOWS), each of which may have its own unique device-driver model.

Accordingly, each graphics engine may be paired with a specific one of the device drivers, or, instead, multiple engines may instead issue commands for ultimate execution by a single device driver (in conjunction with the support function provided by library 60) or any of multiple drivers. This configuration effectively renders the architecture operating-system independent, and is facilitated by a translation module 64a, 64b, 64c associated with each graphics engine. The translation modules convert function calls from the graphics engines into VMI commands recognizable by manager 55. Translation modules 64a, 64b, 64c may operate, for example, by simple table lookup.

For example, a graphics engine may issue generic function calls such as bit-block transfer ("bitblt," which causes transfer of a rectangular array of bitmap or pixelmap data) or specialized calls such as "paint window," "draw text," or "draw line." While primitive function calls can be passed through to manager 55 merely by converting them into the standard VMI format, the translation modules decompose higher-level engine commands into constituent elements drawn from the VMI command set. The repertoire of commands recognized by manager 55 is a matter of design choice. A large set of recognized commands requires less translation overhead but greater processing capacity by manager 55; on the other hand, virtually all graphic functions can ultimately be reduced to sequences of bitblt and line-drawing instructions, simplifying the required capabilities of manager 55 but requiring greater processing time for translation.

Manager 55 serializes communications between translation layers 64a, 64b, 64c and each device driver to accommodate concurrent processing requirements. When it receives a VMI command, manager 55 requests a semaphore (if necessary) from operating system 19, and sends a corresponding GHI command to a designated device driver only when it receives the semaphore, This prevents more than one program thread from accessing a device driver at a given time, and ensures that rendering commands will be executed atomically.

The various components of the invention will now be described in greater detail.

1. Video Manager 55

Manager 55 receives requests from the various translation layers according to a special protocol, the video manager interface, which consists of a small set of operations each identified by a function number. Preferably, manager 55 is implemented as an object in an object-oriented program environment, and exports an entry point for access by the translation layers. A translation layer furnishes the following information to the entry point:

ULONG EXPENTRY VMIEntry (ID, FUNCTION, P.sub.in, P.sub.out);

The ID parameter identifies the device driver, the FUNCTION parameter is a number that identifies the requested VMI operation, and the P.sub.in and P.sub.out parameters are pointers to input and output data structures, respectively, that are relevant to the requested operation. Manager 55 passes most of the requested operations directly to the device driver, changing only the prefix of the command from VMI to GHI. The following calls are common to both the VMI and GHI, and are passed through in this fashion:

    ______________________________________
    VMI.sub.-- CMD.sub.-- INIT
                       GHI.sub.-- CMD.sub.-- INIT
    VMI.sub.-- CMD.sub.-- INITPROC
                       GHI.sub.-- CMD.sub.-- INITPROC
    VMI.sub.-- CMD.sub.-- TERM
                       GHI.sub.-- CMD.sub.-- TERM
    VMI.sub.-- CMD.sub.-- TERMPROC
                       GHI.sub.-- CMD.sub.-- TERMPROC
    VMI.sub.-- CMD.sub.-- QUERYCAPS
                       GHI.sub.-- CMD.sub.-- QUERYCAPS
    VMI.sub.-- CMD.sub.-- QUERYMODES
                       GHI.sub.-- CMD.sub.-- QUERYMODES
    VMI.sub.-- CMD.sub.-- SETMODE
                       GHI.sub.-- CMD.sub.-- SETMODE
    VMI.sub.-- CMD.sub.-- PALETTE
                       GHI.sub.-- CMD.sub.-- PALETTE
    VMI.sub.-- CMD.sub.-- BITBLT
                       GHI.sub.-- CMD.sub.-- BITBLT
    VMI.sub.-- CMD.sub.-- LINE
                       GHI.sub.-- CMD.sub.-- LINE
    VMI.sub.-- CMD.sub.-- MOVEPTR
                       GHI.sub.-- CMD.sub.-- MOVEPTR
    VMI.sub.-- CMD.sub.-- SETPTR
                       GHI.sub.-- CMD.sub.-- SETPTR
    VMI.sub.-- CMD.sub.-- SHOWPTR
                       GHI.sub.-- CMD.sub.-- SHOWPTR
    VMI.sub.-- CMD.sub.-- VRAMALLOC
                       GHI.sub.-- CMD.sub.-- VRAMALLOC
    VMI.sub.-- CMD.sub.-- REQUESTHW
                       GHI.sub.-- CMD.sub.-- REQUESTHW
    VMI.sub.-- CMD.sub.-- BANK
                       GHI.sub.-- CMD.sub.-- BANK
    VMI.sub.-- CMD.sub.-- EXTENSION
                       GHI.sub.-- CMD.sub.-- EXTENSION
    ______________________________________

    ______________________________________
    typedef struct .sub.-- BMAPINFO {   /* bmapinfo */
    ULONG              ulLength;
    ULONG              ulType;
    ULONG              ulWidth;
    ULONG              ulHeight;
    ULONG              ulBpp;
    ULONG              ulBytesPerLine;
    PBYTE              pBits
    } BMAPINFO
    typedef BMAPINFO  *PBMAPINFO;
    typedef struct .sub.-- BLTRECT  {   /* bltrect */
    ULONG              ulXOrg;
    ULONG              ulYOrg;
    ULONG              ulXExt;
    ULONG              ulYExt;
    } BLTRECT  *PBLTRECT;
    ______________________________________

    ______________________________________
    #define BMAP.sub.-- VRAM
                           0X00000000
    #define BMAP.sub.-- MEMORY
                           0x0000000l
    ______________________________________

    ______________________________________
    typedef struct.sub.-- BITBLTINFO {   /* bitbltinfo */
    ULONG              ulLength;
    ULONG              ulBltFlags;
    ULONG              cBlits;
    ULONG              ulROP;
    ULONG              ulMonoBackROP;
    ULONG              ulSrcFGColor;
    ULONG              ulSrcBGColor;
    ULONG              ulPatFGColor;
    ULONG              ulPatBGColor;
    PBYTE              abColors;
    PBMAPINFO          pSrcBmapInfo;
    PBMAPINFO          pDstBmapInfo;
    PBMAPINFO          pPatBmapInfo;
    PPOINTL            aptlSrcOrg;
    PPOINTL            aptlPatOrg;
    PBLTRECT           abrDst
    PRECTL             prclSrcBounds
    PRECTL             prclDstBounds
    BITBLTINFO;
    typedef BITBLTINFO  *PBITBLTINFO;
    ______________________________________

    ______________________________________
    typedef struct .sub.-- LINERACK  {   /* linepack */
    ULONG ulStyleStep;
    ULONG ulStyleValue;
    ULONG ulFlags;
    struct .sub.-- LINEPACK * plpkNext
    ULONG ulAbsDeltaX;  /* absolute (ptlStart.x - ptlEnd.x) */
    ULONG ulAbsDeltaY;  /* absolute (ptlStart.y - ptlEnd.y) */
    POINTL ptlClipStart;
    POINTL ptlClipEnd;
    POINTL ptlStart;
    POINTL pltEnd;
    LONG 1ClipStartError;
    } LINEPACK; /* lpk */
    typedef LINPACK *PLINEPACK; /* plpk */
    ______________________________________

    ______________________________________
    typedef struct .sub.-- LINEINFO {   /* lineinfo */
    ULONG               ulLength;
    ULONG               ulType;
    ULONG               ulStyleMask;
    ULONG               cLines
    ULONG               ulFGColor;
    ULONG               ulBGColor;
    USHORT              usForeROP;
    USHORT              usBackROP;
    PMAPINFO            pDstBmapInfo;
    PLINEPACK           alpkLinePack;
    PRECTL              prclBounds;
    } LINEINFO;  /*  linfo  */
    ______________________________________

    ______________________________________
    typedef struct .sub.-- HWEXTENSION {
    ULONG              ulLength;
    ULONG              ulXSubFunction;
    ULONG              cScrChangeRects;
    PRECTL             arectlScreen;
    ULONG              ulXFlags;
    PVOID              pExtPl;
    } HWEXTENSION;
    ______________________________________

    ______________________________________
    typedef struct .sub.-- INFO {   /* driver information */
    ID                   identifier;
    PSZ                  pszDriverName;
    PFNHWENTRY           pDriverEntry;
    ULONG                cModes;
    struct .sub.-- GDDMODEINFO
                         pModeInfo;
    struct .sub.-- CAPSINFO
                         pCapsInfo;
    struct .sub.-- DRIVERINFO
                         pNextDriverInfo
    } INFO ;
    ______________________________________

• Inventors
  Celi, Jr., Joseph; Wagner, Jonathan M.; Louie, Roger;
• Assignee
  International Business Machines Corporation (Armonk, NY)
• Published
  Apr-28-1998
• Current US Classes:
  345/522
  719/323
• Application #
  356101
• International Classes
  G06F 009/40
• Field of Search
  395/700 395/681 345/522
• Examiner
  Oberley; Alvin E.
• Agent
  Walker; Mark S., Russell; Brian F., Dillon; Andrew J.
• US Patent References:
  4855724
  4893116
  5027212
  5097257
  5208908
  5212770
  5214761
  5226160
  5257387
  5269021
  5291585
  5299307
  5313592
  5319751
  5418962
  5477242
  5491813
  5513365