Dynamic programmable mode switching device driver architecture

Abstract

A device driver architecture that couples an operating system to a computer interface of a controller device that includes a plurality of functional sub-elements. The device driver includes a plurality of operating system interface objects each presenting an operating system interface (OSI) to the operating system, a plurality of computer interface objects each providing for the generation of programming values to be applied to the computer interface to establish the operating mode of a respective predetermined sub-element of the controller device, and a device driver library of processing routines callable by each of the plurality of operating system interface objects to process data and generate calls to the plurality of computer interface objects in predetermined combinations. The device driver library enables the selection of an execution contexts within which to define the generation and application of the programming values to the computer interface. The state of the hardware interface is virtualized and maintained in discrete contexts, allowing for application specific, dynamic alteration of the state of the hardware interface through essentially context switching private to the device driver in response to selected operating system events.

Claims

What is claimed is:

1. A process of providing for the controlled manipulation of the operating state of a hardware controller attached to a computer system, which includes a processor and a memory, said computer system executing an operating system that couples through a device driver to said hardware controller, said process comprising the steps of:

a) determining in the execution of said device driver by said processor the occurrence of a mode switch event specifying a switch from a first predetermined operating state of said hardware controller to a second predetermined operating state of said hardware controller, wherein said first predetermined operating state and said second predetermined operating state correspond to respective sets of configurable operational features on said hardware controller;

b) selectively storing data defining a first context within which said device driver is executed by said processor, said first context corresponding to said first predetermined operating state of said hardware controller, in a first predefined location reserved within said memory by said device driver;

c) selectively restoring data defining a second context within which said device driver is executed by said processor, said second context corresponding to said second predetermined operating state, from a second predefined location reserved within said memory by said device driver; and

d) applying said data defining said second context to said hardware controller to establish said second predetermined operating state.

2. The process of claim 1 wherein said step of selectively restoring includes the steps of:

a) determining whether said second predefined location has been reserved by said device driver;

b) reserving said second predefined location for said device driver if said second predefined location has not been previously reserved; and

c) initializing data defining said second context.

3. The process of claim 1 wherein any of said steps of selectively storing and selectively restoring are selectively skipped.

4. The process of claim 1 or 3 wherein said data defining said second context is obtained dynamically from a data file external to said device driver.

5. A device driver for use in conjunction with an operating system of a computer system for providing an operating interface to a programmable controller, said device driver comprising:

a) a first interface module, coupleable to an operating system, providing entry point support for a predetermined API call to initiate a mode set operation;

b) a second interface module, coupleable to said operating system, providing entry point support for a predetermined operating system call to read system configuration data;

c) a third interface module, coupleable to said programmable controller, providing entry point support for a predetermined hardware interface register programming routine; and

d) a library module coupleable to said first, second and third interface modules, said library module being responsive to a call issued from said first interface module upon the receipt of said predetermined API call by said first interface module, said library module providing a call to said second interface module to initiate said predetermined operating system call to read predetermined system configuration data corresponding to said operating mode set data, said library module including a parser for generating register programming data by execution of predetermined instructions provided in said predetermined system configuration data, said register programming data being provided to said predetermined hardware interface register programming routine of said third interface module.

6. The device driver of claim 5 wherein said library module is coupled to said first, second and third modules at least upon installation and initialization of said device driver by said operating system within a memory of said computer system.

7. The device driver of claim 6 wherein said third module includes a programmable module interface having a plurality of call entry points to executable functions supported by said third module, and wherein said third module provides for the initialization of said plurality of call entry points to a predetermined subset of said plurality of call entry points of said third module.

8. The device driver of claim 7 wherein said third module provides for the re-initialization of said plurality of call entry points to an alternate subset of said plurality of call entry points of said third module consistent with said mode set operation.

9. The device driver of claim 8 wherein said first module includes a copy of said programmable module interface and wherein said copy is conformed to said predetermined subset or said alternate subset of said plurality of call entry points provided in said programmable module interface of said third module.

10. A process of performing a mode set of the operating state of a programmable controller coupled to a computer system, wherein an operating state is defined by a set of configurable operational features of said programmable controller, said programmable controller presenting a register interface to said computer system, wherein a device driver is executable by said computer system with respect to a mode switch call, and wherein an operating system executed by said computer system provides said mode switch call including predetermined data defining predetermined characteristics of an operating mode of said programmable controller, said process comprising the steps of:

a) determining, in execution of said device driver in response to said mode switch call, to perform a mode set of said programmable controller;

b) determining, in execution of said device driver based on said predetermined data, a target mode for said mode set;

c) obtaining, through the execution of said device driver by which system calls are issued to said operating system, predetermined configuration data corresponding to said target mode;

d) parsing, through the execution of said device driver, said predetermined configuration data to identify and execute a plurality of instructions included within said predetermined configuration data, the execution of said plurality of instructions providing register programming data appropriate to perform said mode set of said programmable controller to said target mode; and

e) providing said register programming data to said register interface.

11. The process of claim 10 wherein said plurality of instructions are represented by instruction directives which specify the selective execution of said device driver by which to perform said step of providing.

12. A device driver coupleable to an operating system and executable by a host computer, said operating system providing system calls to the device driver to modify the operating state of a programmable peripheral controller which is coupleable to said host computer, said operating system providing for the controlled execution of programs within respective operating system contexts, said device driver comprising:

a) a first module provided to manage first and second sets of data respectively supporting first and second operating modes of said programmable peripheral controller, said first module selectively creating first and second device driver contexts within a predetermined operating system context, wherein said first module provides for the establishment of said first and second sets of data respectively within said first and second device driver contexts in connection with the selective creation of said first and second device driver contexts, and wherein said first module relies on a currently selected one of said first and second device driver contexts to manage said programmable peripheral controller within a corresponding one of said first and second operating modes; and

b) a second module providing an interface to said operating system to receive said system calls, said second module being coupled to said first module to direct the selection of either of said first and second operating modes, wherein said second module determines the selection of said currently selected one of said first and second operating modes in response to the receipt of a predetermined system call by said interface.

13. The device driver of claim 12 wherein said second module, in response to said system calls, directs said first module to modify the operating state of said programmable peripheral controller within said currently selected one of said first and second operating modes.

14. The device driver of claim 13 wherein said programmable peripheral controller is a video controller, wherein said first and second operating modes correspond to first and second video pixel resolutions, wherein said first and second sets of data include respective control data used by said first module in rendering predetermined video data in said first and second video pixel data states.

15. The device driver of claim 14 wherein said programmable peripheral controller includes a plurality of programmable functional units that control respective sub-functions of said programmable peripheral controller, wherein said first module includes a plurality of sub-modules selected in respective correspondence with said programmable functional units, wherein said control data of said first and second sets of data includes the state data of said sub-modules for said first and second device driver contexts, respectively, and wherein respective said control data is created in connection with the creation of said first and second device driver contexts.

16. The device driver of claim 15 wherein said first video pixel data state corresponds to a first color depth and said second video pixel data state corresponds to a second color depth different from said first color depth, wherein said first module manages the storage of a predetermined bit-mapped image, and wherein said first module provides for a translation of said predetermined bit-mapped image between said first and second color depths when said currently selected one of said first and second device driver contexts is changed.

17. The device driver of claim 15 wherein said first video pixel data state corresponds to a first display resolution and said second video pixel data state corresponds to a second display resolution different from said first display resolution, wherein said first module manages the storage of a predetermined bit-mapped image, and wherein said first module provides for a translation of said predetermined bit-mapped image between said first and second display resolutions when said currently selected one of said first and second device driver contexts is changed.

18. The device driver of claim 15 wherein said first video pixel data state corresponds to a first color depth and display resolution and said second video pixel data state corresponds to a second color depth and display resolution different from said first color depth and display resolution, wherein said first module manages the storage of a predetermined bit-mapped image, and wherein said first module provides for a translation of said predetermined bit-mapped image between said first and second color depths and display resolutions when said currently selected one of said first and second device driver contexts is changed.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is generally related to the design of device drivers utilized in computer operating systems to define and establish an interface between the core operating system and typically hardware devices and, in particular, to a modular device driver architecture providing a virtualized, context switchable interface environment within which to operate typically hardware devices in support of operating system functions, specifically including information display functions.

2. Description of the Related Art

In conventional computer systems, software operating systems provide generalized system services to application programs, including utility and daemon programs. These system services conventionally include access to whatever individual hardware peripheral devices, each generally presenting a well defined hardware interface to the computer system, may be attached directly or indirectly to the computer system. Device drivers, implemented as software modules or components that can be integrated into an operating system, are typically used to provide well defined software application program interfaces (APIs) to the operating system and application programs for each of the hardware interfaces. Device drivers often provide a degree of device independence or virtualizing that may simplify the interaction of an application program or operating system with the specifics of a particular class of hardware interface, such as a video controller. Conventionally, for each implementation underlying a particular hardware interface, a specific device driver is used to implement an otherwise common API that is presented to the application programs and operating system.

A number of problems are inherent in conventional device driver designs. First, conventional device drivers are specific to a particular hardware interface and the function of the underlying device or controller system. Thus, whenever a new or different version of a hardware controller is produced, a new device driver equally specific to the new or different hardware must also be developed. Where there are many different versions of a hardware device, a generally like number of device drivers must be developed. Alternately, single combination device drivers may be constructed to support multiple versions or types of devices. Such device drivers typically incorporate multiple device specific drivers that are otherwise substantially independent of one another into single binary file.

The effective number of device drivers needed to support a particular piece of hardware is also dependant on the number and differences in the operating system environments within which the hardware is to be used. In all but the most closely related operating systems, a substantial redevelopment of the device driver is required to both provide for the proper ability to incorporate the device driver into a particular operating system and, perhaps more significantly, to provide a logically similar though often entirely different API to the operating system and applications. Usually, the detailed definition of the API of the device driver governs the detailed design of the device driver itself. Consequently, device drivers for the same hardware but for different operating systems are often almost completely independently developed.

Another consideration that affects the number of device drivers that are required to support a particular hardware controller arises from the nature of other hardware and systems that are connected to a particular controller. Again, to provide flexibility in the detailed construction of computer systems, a hardware controller may be capable of supporting a number of distinctly different modes of operation. For example, a video controller may be able to support a significant range of video display resolutions and color depths. However, the range may be constrained by direct limitations such as the amount of video RAM actually implemented on a particular video controller and indirectly by the maximum vertical and horizontal frequencies of an attached video display. The requirements of particular applications may also drive the selection of a particular mode of operation that must be supported by a device driver. Conventionally, a number of device drivers are provided with the hardware controller, each supporting a different set of one or more modes of operation. One of the provided device drivers must therefore be selected for operating system incorporation based directly on the configuration of the particular computer system. Aside from the difficulties of picking a device driver that supports the desired set of operating modes, a substantial difficulty exists in preemptively determining the variety of modes that different individual device drivers are to support. Although the individual drivers may differ only by some modest amount, their number may be significant in terms of development.

A second problem, in part a consequence of the first, is that each device driver must be thoroughly tested in the full variety of environments that the device driver may be used in to ensure commercially acceptable operation. Conventionally, device drivers are essentially monolithic software modules that are incorporated bodily into the operating system. As such, testing of even minor variants of a device driver for a particular operating system requires that the full suite of operational function and application compatibility tests be run to verify correct operation of the device driver. Selective functional testing is generally inappropriate due to the real possibility of collateral operational errors arising from any modification of a monolithically coded device driver. Given the substantial number of effectively different device drivers conventionally supported for a reasonably complex hardware controller and the size and substantial extent of corresponding test suites, the testing of device drivers represents a substantial expense and a very significant delay in bringing new or improved versions of a product to market.

A third problem with conventional device driver designs is that they provide for a substantially static type of hardware controller management. In general, device drivers establish a single set of operating parameters for the hardware controller being managed by the device driver. The operating system and the application programs executing on the computer system all must accept the parameters of this static mode or essentially fail to operate correctly.

In limited instances, a conventional device driver may make some modes available or visible to application programs. To make use of these modes, the device driver therefore relies on application programs to have essentially compiled-in hardware dependencies. In such cases, the application programs may invoke a mode change, though with potential detrimental effects on the other executing programs that, even if capable of invoking a mode switch, are effectively unaware of any such switch.

Some typically multi-tasking operating systems can perform limited dynamic hardware controller mode switching, though only through an operating system supported state change. In these cases, the operating system essentially reloads the state of the device driver and hardware controller consistent with the state of a new mode of operation. However, there is no direct relation between the applications executing and the state of the device driver and hardware controller. Again, any executing applications are largely if not completely unaware of any mode switch. Consequently, the selected mode may be optimal for some executing application, but not necessarily the application with current execution focus.

SUMMARY OF THE INVENTION

Thus, a general purpose of the present invention is to provide a flexible, modular device driver architecture that can provide independent hardware configuration options on a dynamic reconfiguration basis.

This is achieved in the present invention by providing a device driver architecture that operates to couple an operating system, provided in the memory of a computer system having a processor, to a computer interface of a controller device that includes a plurality of functional sub-elements. The device driver includes a plurality of operating system interface objects each presenting an operating system interface (OSI) to the operating system, a plurality of computer interface objects each providing for the generation of programming values to be applied to the computer interface to establish the operating mode of a respective predetermined sub-element of the controller device, and a device driver library of processing routines callable by each of the plurality of operating system interface objects to process data and generate calls to the plurality of computer interface objects in predetermined combinations. The device driver library enables the selection of execution contexts within which to define the generation and application of the programming values to the computer interface.

An advantage of the present invention is that the state of the hardware interface and, correspondingly, the state of the controller that presents the hardware interface, is virtualized and maintained in discrete contexts. Operational features or modes of a controller that must otherwise be handled or managed by individual application programs can be virtualized by operation of the present invention. The present invention provides for application specific, dynamic alteration of the state of the hardware interface through essentially private context switching implemented by operation of the device driver. Selected operating system events are modified or trapped to initiate the creation of new contexts and the dynamic switching between contexts by the device driver.

Another advantage of the present invention is that the device driver provides for a comprehensive optimization of the functions supported through the device driver by the controller. The device driver provides for the virtualization of the API call interfaces supported by the device driver. Virtualization of the call interfaces through the use of operating system interface objects provides specific support for independently defined APIs and the translation of functionally equivalent calls to be supported by substantially common execution streams.

A further advantage of the present invention is that virtualization of the call interfaces of the device driver architecturally establishes a common evaluation of API calls and their parameters, essentially eliminating any requirement for subsequent parameter checking within the common execution streams. The resultant substantially linear execution streams, coupled with pointer referencing of context data structures ensures efficient execution performance while enabling substantially greater functionality than achievable in conventional monolithic device drivers.

Yet another advantage of the present invention is that the device driver provides for context dependant alteration of the substantially linear execution streams. Conversion functions required to enable or support switching between contexts are supported by linking the functions directly into the execution streams so as to minimize repetitive testing to determine whether a conversion function need be performed.

A still further advantage of the present invention is that the device driver incorporates dynamic loading and configuration of essential functional objects necessary or optimal to support the particular controller configuration accessible through the hardware interface. The device driver responds to encoded configuration data obtained through the hardware interface or otherwise from the controller to identify the independent functional sub-elements constituting the controller, determines a corresponding set of hardware interface objects appropriate to support the sub-elements and dynamically loads and links in the object set as part of the initialization of the device driver.

Still another advantage of the present invention is that the device driver supports a variety of hardware interface objects that are programmable with respect to certain functional or operational aspects. Based on the encoded configuration data obtained through the hardware interface or otherwise from the controller, the device driver identifies and loads configuration data from system memory to program the hardware interface objects with operational configuration data defining details of how the hardware interface objects will support their corresponding sub-elements.

Yet still another advantage of the present invention is that the device driver provides an established architecture within which new hardware interface objects can be developed in substantial isolation from other hardware interface objects and other architectural components of the device driver. The architectural design of the hardware interface objects themselves also allows substantial configuration revision and enhancement to be performed through redefinition of the operational configuration data used to program the corresponding hardware interface objects. Modification of a device driver to support a revised or new controller sub-element may be limited to simply editing a configuration data file as opposed to preparing source code modifications to the sub-element corresponding hardware interface object. In any case, compatibility testing can be appropriately limited to testing the particular hardware interface object that supports a revised or new sub-element of a controller.

A yet still further advantage of the present invention is that the device driver provides for modification of the operating system to enforce a consistent reporting of the color depth currently supported by a video display controller. Different color depth contexts are established for the set of executing application with each context corresponding to the maximum acceptable color depth of one or more executing applications. As context is changed and where the maximum color depth of an application exceeds the color depth capabilities of the video display controller, color depth conversion functions linked into appropriate linear execution streams provide for display data color depth conversion.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other advantages and features of the present invention will become better understood upon consideration of the following detailed description of the invention when considered in connection of the accompanying drawings, in which like reference numerals designate like parts throughout the figures thereof, and wherein:

FIG. 1 is a schematic block diagram of a computer system constructed in accordance with the present invention;

FIG. 2 provides a schematic block diagram of the architectural configuration of the present invention during initialization of the device driver of the present invention;

FIG. 3 provides a flow diagram detailing the initialization of the present invention;

FIG. 4 provides a schematic block diagram of the architectural configuration of the present invention during a run time execution of the device driver of the present invention;

FIG. 5a provides a general illustration of the relationship between plural shell objects defining device driver context, the Shell Library, and the physical device structure of the operating system consistent with the preferred embodiment of the present invention;

FIG. 5b provides a generalized illustration of the relationship between plural instantiations of a hardware interface object consistent with a preferred embodiment of the present invention;

FIG. 6a provides a flow diagram describing the performance of steps in preparing for a context switch in accordance with the preferred embodiment of the present invention;

FIG. 6b provides a flow diagram describing the steps utilized in realizing a new context in accordance with a preferred embodiment of the present invention;

FIG. 7 provides a software flow diagram of the steps utilized in terminating the operation of a device driver constructed in accordance with the present invention;

FIG. 8 provides a block diagram of illustrating the use of both real and virtual architectural configurations of the present invention in support of multiple virtual machines executing within an operating system consistent with the present invention; and

FIG. 9 provides a schematic block diagram of the architectural configuration of a virtual device driver constructed in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

I. Hardware System Overview

A computer system 10, suitable for utilization of the present invention, is shown in FIG. 1. The computer system 10 preferably includes a central processing unit (CPU) 12 coupled through a system data bus 14 to a main memory 16 and a mass storage peripheral 18, preferably including a disk drive controller and hard disk drive unit. For purposes of the present invention, the operation of the mass storage peripheral 18 is sufficient if the supported function permits the reading of a certain executable, data and configuration files from a non-volatile resource. Thus, the mass storage peripheral 18 may be a communications controller providing access to a external or remote device or system that provides for the storage of data readable by the computer system 10 typically in a file oriented organization.

A video display controller 19 is also provided as a peripheral device coupled to the system bus 14. The hardware implementation of the video display controller 19 is generally conventional in nature for purposes of the present invention. However, in the context of the present invention, the video controller 19 is uniquely described as a collection of logically independent sub-elements that together comprise the controller 19. The sub-elements are logically distinguished by their functional identity particularly with regard to generally independent operational programmability. That is, the functional divisions of the hardware implementation of the controller 19 largely define the separate sub-elements of the controller 19 for purposes of the present invention.

Another basis for distinguishing the sub-elements is the grouping of functions based upon a commonality in the manner of programming the corresponding sub-element as a consequence ultimately by the programmed execution of the CPU 12. Thus, as generally indicated in FIG. 1, the sub-elements of the video controller 19 preferably include, but are not limited to, a video display buffer 20, a digital-to-analog converter (DAC) 22, a video graphics accelerator 24, a video controller 26, a programmable clock generator 28, a hardware cursor controller, and a coder-decoder unit (CODEC). Each of these sub-elements of the controller 19 are relatively independently programmable through a hardware register interface 30 that is appropriately coupled to the system bus 14. Thus, the CPU 12 may program and obtain information from the sub-elements 20, 22, 24, 26, 28. The register interface 30 and one or more of the sub-elements may, as a practical matter, be physically resident on a single integrated circuit. Co-residency of sub-elements on a single integrated circuit or the possibility that sub-elements are accessible through other sub-elements does not affect functionally distinguishing sub-elements from one another.

By the programming of the sub-elements 20-28, a video display 32 is supported for the presentation of textual and graphical information. In a preferred embodiment of the present invention, multiple display windows 34, 36 are supported in combination with a pointer 38 that can be used to select the current active or "focus" display window visible on the display 32. A display window 34, 36 can obtain the current focus through a number of discrete events. These events include the launching of a new application program for execution by the computer system 10. By default, the main window of a newly launched application obtains the current focus of the display 32. The pointer 38 can also be utilized to select a window 34, 36 that is to receive a focus on the occurrence of a mouse click, for example. Finally, the display window 34, 36 may receive focus upon termination of another application. In each of these circumstances a focus event is produced upon which the CPU 12, through the execution of the operating system, can act.

Other peripherals 40 may also exist as components of the computer system 10. These other peripherals 40 may include complex controllers supporting audio, real-time video, and other complex multi-function operations alone or in combination with one another. Such complex controllers may be effectively supported by the present invention provided that the functional operation and organization of the controller is reasonably sub-divided as a multiplicity of functional elements that are programmable directly or indirectly by the CPU 12. For example, a high-performance audio subsystem presenting wavetable synthesis, FM synthesis, an equalization controller, a reverberation controller and multichannel amplifier sub-elements all directly or indirectly represented though a register interface presented to the system bus 14 can be optimally supported by the present invention.

II. Software System Overview

While the present invention may readily support any peripheral controller that has any number of sub-elements, the present invention may be best understood as applied in the preferred embodiment to the support and control of the video display controller 19. Referring now to FIG. 2, a preferred device driver embodiment of the present invention 50 is shown positioned between the hardware interface, representing the logical connection of the device driver to the register interface 30 of the video display controller 19, and an operating system layer 54. The operating system layer 54 typically includes an operating system kernel 56 and potentially one or more operating system extensions 58 that add some basic operating system level functionality. Finally, the operating system layer 54 may in turn support one or more application programs 60.

In operation, the application programs 60 obtain operating system layer 54 support services through an application program interface (API) that is presented effectively as a set of execution entry points that can be called by the application 60. In accordance with an embodiment of the present invention, a small sub-set 62 of the operating system kernel API call points are modified during the initialization of the device driver 50. These modified call points include the entry point routine that reports a window focus change event to an application 60 and the entry point routine that reports the current color depth of the display 32 back to the application 60. The focus change event is preferably modified to include a API call to an operating system extension 58 that provides for additional event processing in response to a focus change event. This additional event processing includes performing a configuration retrieval to obtain data quantifying the execution environment of an application that is to be launched generally as a consequence of the focus event. The data retrieved preferably includes the screen resolution and color depth configuration desired for the application being launched.

The modifications of the color depth reporting routine are made specifically to ensure that the maximum color depth requested by any application 60 is reported to the application 60 as being the current color depth of the display 32. Thus, in accordance with the preferred embodiment of the present invention, all applications 60 execute against a completely virtualized representation of the display 32 particularly with respect to color depth. That is, the device driver 50 provides full support for whatever color depth is requested by an application 60, regardless of whether the requested color depth exceeds the maximum color depth that can be handled by another application 60 or, indeed, the maximum color depth of the display 32 itself.

A. Device Driver Software Architecture--Upper Level

The kernel layer 54 connects to the device driver 50 through an operating system API (O/S API) that provides the operating system kernel 56 and any extensions 58 with entry points into the device driver 50. Within the device driver 50, the O/S API is supported primarily by a number of operating system interface modules including a Graphics Display Interface (GDI) module 64, a Direct Draw (DD) module 66, any number of other modules 68, each representing a present or future defined APIs, such as Direct 3D (D3D). Additional API entry points are provided by an operating system (O/S) module 70, a graphics interface (GRX) module 71, and a shell module 72. These modules together present essentially all of the callable entry points that make up the O/S API of the device driver 50.

The shell module 72 is the initial component of the device driver 50 loaded into the memory 16 as part of the initialization of the operating system kernel 56 during system startup. In a conventional operating system such as Microsoft MS-Windows '95.TM., the operating system kernel 56 will load the shell module 72 into memory 16 as a consequence of a reference in a standard initialization configuration file or data base, such as the MS-Windows '95 registry services.

An initialization entry point provided by the shell module 72 permits the operating system kernel 56 to initiate the device driver specific initialization of the device driver 50. As part of this initialization, the shell module 72 determines a Board driver, set of hardware interface modules, and compliment of operating system interface modules that are required to complete the implementation device driver 50 to support the O/S API that will be presented by the device driver 50 to the operating system layer 54. In a preferred embodiment, these determined additional modules, if not statically linked to the shell module 72, are dynamically loaded and then logically linked into the device driver 50.

In order to establish a call interface to the O/S API as needed to obtain support services for initialization of the device driver 50, at least the operating system module 70 loads as an integral portion or component of the shell module 72. Preferably, the GRX module 71 is also loaded with the shell module 72. As a matter of practical convenience, other commonly used and default operating system interface modules may also be statically linked to the operating system module 70.

Particularly as demonstrated by the GDI 64, DD 66, and D3D 68 modules, the device driver 50 of the present invention preferably implements the O/S API of the device driver 50 in segregated units that are specific to particular portions of the operating system kernel 56 and/or operating system extensions 58. Thus, in the preferred embodiment, the GDI module 64 preferably supports the flat model DIBEngine driver interface predefined by Microsoft for the MS-Windows '95.TM. product. Similarly, the Direct Draw module 66 supports the hardware independent interface for the standard direct draw API. The D3D module 68 will support the announced Microsoft Direct 3D API for Windows '95.TM.. Documentation for each of these APIs is available as part of the Microsoft Software Development Kit (SDK) and the Microsoft Device Drivers Kit (DDK), available as commercial products of Microsoft, Inc., Redmond, Wash. The dynamic loading capability of the present invention thus allows the comprehensive API support presented by the device driver 50 to be readily tailored and extended through the dynamic loading of additional operating system interface modules.

The shell module 72, including the O/S and GRX modules 70,71, presents both conventional and proprietary API interface parts to the operating system layer 54 as needed to support both conventional and proprietary support functions through the operation of the device driver 50. The conventional API part includes an initialization entry point that allows the operating system layer 54 to initiate the initialization of the shell module 72 upon loading into the memory 16. A generally standard termination call entry point is also provided. This entry point allows the operating system layer 54 to signal the device driver 50 that shutdown of the operating system layer 54 is imminent and that an orderly termination of the device driver is required.

The proprietary API entry points presented by the shell module 72 include entry points providing for the reading and writing of data defining the current desktop presented on the display 32, the current viewport and certain data defining the operation of the device driver 50. This latter information may include setting the current physical color depth of the display 32, the current color and pattern of the display pointer 38, and a number of largely video hardware specific aspects such as the interlace, video sync type, video fast scroll, and color enable options of the device driver 50.

Finally, the operating system module 72 provides the device driver support routines that call the operating system layer 54 to obtain basic operating system services. In the preferred embodiment of the present invention, these system services include memory allocation, freeing of previously allocated memory, the loading and unloading of dynamic link libraries, memory management functions such as enabling a memory object to be executable or to lock a memory object in real memory, to disable the executable or lock status of memory objects, to read and write data to defined I/O addresses, and to open, read and close named data files typically as stored by the mass storage peripheral 18.

B. Device Driver Software Architecture--Lower Level

The shell module 72 also provides for a dynamic configuration of the device driver 50 with respect to the particular instance of the video display controller 19. While any of a number of functionally similar video display controllers 19 may be utilized in the computer system 10, the device driver 50 of the present invention provides for the dynamic selection and inclusion of a board driver 74 into the device driver 50 to optimally support the hardware specifics of the particular video display controller 19. The shell module 72 selects a particular board driver 74, from among any number of variants, that corresponds to the major aspects of the particular video display controller 19. In practical terms, the major aspect of a particular video display controller 19 is the specific architecture of the integrated circuit graphics accelerator chip or chip set used in the implementation of the controller 19. Thus, a single board driver 74 may correspond to a well defined family of specific variants of the display controller 19. Other board drivers can be constructed to correspond to other families of controllers of different definition.

The board driver 74 provides for an additional layer of dynamic configuration of the device driver 50 by the selective support of a set of hardware interface modules. These hardware interface modules are dynamically loadable as component elements of the device driver 50 and correspond substantially to the individual sub-elements of a particular implementation of the video display controller 19. In a preferred embodiment of the present invention, the set of hardware interface modules include a Clock Module 76, DAC Module 78, CODEC Module 80, Hardware Cursor Support Module 82, Video Module 84, Two Dimensional Graphics Control Module 86, and Three Dimensional Graphics Control (3D) Module 88. The particular set of hardware interface modules dynamically loaded in to the device driver 50 is determined by the board driver 74 in correspondence to the specific sub-elements present in the implementation of the video display controller 19. That is, dependant upon the specific implementation of the Clock sub-element 28, a particular and corresponding clock module 76 is identified by the board driver 74 and dynamically loaded into the device driver 50. Consequently, for example, inclusion of a new version of a DAC sub-element 22 into the otherwise generally existing design of the video display controller 19 can be immediately accommodated by a corresponding revision in the functionality of essentially only the DAC module 78 of the device driver 50. Thus, the partitioning of sub-element specific aspects of the device driver 50 into dynamically loadable modules allows significant revisions in the ultimate configuration performance and operation of the device driver 50 to be made in isolation from the rest of the device driver 50. Such hardware specific changes are also effectively isolated from the other hardware interface modules and from the higher layers of the device driver 50. Testing of a device driver 50 configuration for a new version of the display controller 19 can therefore be made with confidence against only the particular new or revised hardware interface module or modules.

As a practical matter, some of the hardware interface modules may be statically linked to the board driver 74. Where a basic compliment of modules will always or almost always be used with a particular board driver 74, an optimization is gained by loading the modules together with the board driver 74. Subsequent use of a statically linked module can also be effectively overridden by providing a dynamically linkable module for supporting the corresponding sub-element. Dynamically loaded modules are preferably used over corresponding statically linked modules.

III. Device Driver Initialization

The process of initializing the device driver 50 of the present invention is generally illustrated in FIG. 3. This initialization process will be described with regard to the preferred embodiment which operates with the MS-Windows '95.TM. operating system.

A. Initial Upper Level Initialization

In connection with the conventional execution of the operating system initializations, the shell module 72 is loaded 90 into memory 16 as a consequence of a conventional system driver reference in the registry services database file. Once resident in memory, a call is made to the initialization entry point of the shell module 72 to initiate the device driver dependent initializations. The initialization routine of the shell module 72 provides for the creation 92 of and a shell object 126 (SHELLOBJ) and then an operating system object 128 (OSOBJ) at 93.

The shell object is used as a top level data structure that logically links together the structure of the device driver 50. The significant elements of the shell object are identified in Table I.

    TABLE I
    SHELLOBJ
        {
            /* global state flags */
            InitFlags
            ModeSetFlags
            /* public data */
            ViewportXext
            ViewportYext
            ViewportLeft
            ViewportTop
            ViewportRight
            ViewportBottom
            DesktopXext
            DesktopYext
            PixelDepth
            ColorType
            HorzFreq
            VertFreq
            Interlace
            SyncTypes
            CursorColor
            PanlockOn
            FastScrollRate
            ColorEnableOn
            VideoMemoryOffset
            VideoMemoryPool
            OffscreenBitmapCache
            /* pointers to list of operating system and hardware
                interface objects with head and tail pointers to
                facilitate pointer list management and pointers
                to Board and GRX objects */
            FirstObj
            BoardObj
            GrxApiObj
            LastObj
            /* storage for the board identifier */
            BoardData
            /* shell library routine entry points */
            ShellModeSet
            ShellSetDPMSState
            ShellModeDump
            ShellGetDesktop
            ShellValidateDesktop
            ShellGetViewport
            ShellValidateViewport
            ShellSetViewportPos
            ShellStrlen
            ShellStrtok
            ShellStrncmpi
            ShellStrcpy
            ShellStrcat
            ShellPrintStr
            ShellScanStr
            ShellDebugOut
            ShellStringOrdinal
            ShellSkipWhitespace
            ShellSkipToAfterNull
            ShellSkipToAfterCrLf
            ShellReadFileIntoBuffer
            ShellGetBufferedSection
            ShellReplaceCrLfWithNull
            ShellParseSection
            ShellLoadObject
            ShellUnloadObject
            ShellGetModeFileName
            ShellRegisterBoardObject
            ShellUnregisterBoardObject
            ShellOffscreenBitmapInit
            ShellOffscreenBitmapRegisterMove
            ShellOffscreenBitmapUninit
            ShellOffscreenBitmapCreate
            ShellOffscreenBitmapDestroy
            ShellOffscreenBitmapCache
            ShellOffscreenBitmapFlush
            ShellOffscreenBitmapFlushAll
            ShellOffscreenBitmapCleanBand
            ShellOffscreenBitmapCleanAll
            ShellMemoryPoolCreate
            ShellMemoryPoolDestroy
            ShellMemoryPoolSetInform
            ShellMemoryPoolAlloc
            ShellMemoryPoolAllocMoveable
            ShellMemoryPoolAllocFixed
            ShellMemoryPoolFree
            ShellMemoryPoolCompact
            ShellMemoryPoolEnumerate
            ShellMemoryPoolGetData
            ShellBandListCreate
            ShellBandListDestroy
            ShellBandListFindByHeight
            ShellBandListEnumerate
            ShellBandListAlloc
            ShellBandListFree
            ShellRectPoolCreate
            ShellRectPoolDestroy
            ShellRectPoolAlloc
            ShellRectPoolFree
            ShellRectPoolGetData
        }

    TABLE II
    OSOBJ
        {
            /* General Purpose Operating system API calls
                supported */
            OsMemoryAlloc
            OsMemoryFree
            OsLoadDLL
            OsUnIoadDLL
            OsGetModuleHandle
            OsGetProcAddress
            OsGetModuleProcAddress
            OsMapPhysicalAddr
            OsMakeSelectorUse32
            OsCopyAddrMpping
            OsMakeExecutable
            OsMakeReadWrite
            OsMakeSelectorAlias
            OsFreeSelectorAlias
            OsOutputDebugString
            OsUnmapPhysicalAddr
            OsGetSystemDesktop
            OsGetSystemViewport
            OsGetSystemTickCount
            OsFileFind
            OsFileOpen
            OsFileClose
            OsFileRead
            OsFileWrite
            OsFileSeek
            /* platform specific utility functions */
            OsReadWord
            OsWriteWord
            OsReadString
            OsWriteString
            OsReadIOByte
            OsReadIOWord
            OsReadIODword
            OsReadIndexedIOBytes
            OsWriteIOByte
            OsWriteIOWord
            OsWriteIODword
            OsWriteIndexedIOBytes
            OsWriteFixedIOBytes
            OsWriteMemDWord
            OsWriteMemDWordVerify
            OsWriteMemWord
            OsWriteMemWordVerify
            OsWriteMemByte
            OsWriteMemByteVerify
            OsReadMemDWord
            OsReadMemWord
            OsReadMemByte
            OsMemCopy
            /* Low level operating system and Bios call
            functions */
            Os4To3
            OsInt10
            OsFindPCIId
            OsGetPCICfgRegB
            OsGetPCICfgRegW
            OsGetPCICfgRegDW
            OsSetPCICfgRegB
            OsSetPCICfgRegW
            OsSetPCICfgRegDW
            OsGetBoardData
        }

            TABLE IlI
            Board_Identifier:
            ID                       DW          "DM"
            Revision                 DB          "1"
            StructureSize            DB          "16"
            BoardFamily              DB          "0"
            BoardModel               DB          "0"
            ControllerFamily         DB          "0"
            Controller               DB          "0"
            DacType                  DB          "0"
            PixelClockType           DB          "0"
            MemoryClockType          DB          "0"
            MemoryType               DB          "0"
            VideoType                DB          "0"
            Oem                      DB          "0"
            BoardDependantInfo       DW          "0"

    TABLE IV
    BOARDOBJ
        {
            OBJHDR
            /* public data */
            ScreenBaseAddress
            MmioBaseAdddress
            VideoMemorySize
            ScreenWidthBytes
            BytesPerPxel
            /* actual modes.dmm file name */
            ModeFileName[128]
            /* pointers to a list of the hardware interface objects -
                also head and tail pointers to facilitate pointer
                list management and to support dynamically
                loaded objects*/
            FirstObj
            MemoryClockObj
            PixelClockObj
            CursorObj
            DacObj
            DrawengObj
            LastObj
            /* public data of board spatial resolution and color
                depth capabilities supported for both Desktops
                and Viewports */
            NumDesktops
            Desktops[]
            NumVieworts
            Viewports[]
            /* pointer to in-memory board identifier structure held
                by the shell object */
            BoardData
            /* board library entry points */
            BoardBlankScreen
            BoardSetViewpotPos
            BoardWaitForVertBlank
            BoardReadReg
            BoardWriteReg
            BoardReadDAC
            BoardWriteDAC
            BoardWriteDACArray
            BoardWriteSerialDeviceStart
            BoardWriteSerialDevice
            BoardWriteSerialDeviceEnd
        }

    TABLE V
    OBJHDR
        {
            /* universal object information */
            HeaderVer
            ObjectVer
            Module
            ObjDataInstance
            RegClassHandler
            ObjectInit
            ObjUnInit
            ModeSet
            SetDPMSState
            /* for debug */
            ModeDump
        }

    TABLE VI
    RegClassHandler
        {
            "Class_Name"
            Class_Index
            Class_Max
            H/W_Interface_Object
            RegClassMap
            Read_reg
            Write_reg
            CmdHandler
        }

    TABLE VII
    CLOCKOBJ
        {
                OBJHDR
        }

    TABLE VIII
    CURSOROBJ
        {
                OBJHDR
                CursorEnable
                CursorSet
                CursorMove
                CursorSetColor
        }

    TABLE IX
    DACOBJ
        {
                OBJHDR
                DacBlankScreen
                DacSupportGammaInMode
                DacGammaEnable
                DacPaletteSet
        }


TABLE IX
    DACOBJ
        {
                OBJHDR
                DacBlankScreen
                DacSupportGammaInMode
                DacGammaEnable
                DacPaletteSet
        }

    TABLE XI
    DRAWENGMINIFUNCS
        {
        BeginAccess
        EndAccess
        CheckAccess
        SolidColorRop
        NotDst
        ColorPatternRop
        CacheColorPattern
        CacheMonoPattern
        MonoPatternExpandRop
        ScreenToScreenRop
        MemoryToScreenRop
        MemoryToScreenRopXlat
        MonoToScreenRop
        MonoToScreenXparRop
        GlyphBltXpar
        SolidLineRop
        SolidJointLineRop
        MultiSolidColorRop
        MultiMonoPatternRop
        MultiMonoPatternXparRop
        MultiColorPatternRop
        MultiNotDstRop
        MultiDitherColorRop
        SrcRopSrcKey
        SrcRopDstKey
        CreatePrivateDither
        PrivateDitherRop
        Polygon
    }

    TABLE XII
    GRXAPIOBJ
        {
                OBJHDR
                GrxApiFastCopy
                GrxApiColorMatch
        }

                  TABLE XIII
                  GDIOBJ
                      {
                               OBJHDR
                               GdiColorMatch
                               PDevice
                               SystemPDevice
                               GdiInfo
                               SystemGdiInfo
                               VddMagicNumber
                               VddEntryPoint
                               Palette
                               DibengObj
                               DrawengObj
                      }

          TABLE XIV
          DIBENGOBJ
          {
          /* The DisplayDriverFuncs will hold the set of functions
          that should be dispatched to for a bitmap associated
          with the display device or for a memory bitmap,
          depending on whether the identified bitmap is a device
          or in-memory bitmap. The appropriate function pointers
          are determined at init time so that they can be copied
          into the BMP headers easily as the bitmaps are created.
          */
              OBJHDR
              DisplayDriverFuncs
              DisplayDriverExtFuncs
          }

                TABLE XV
                DISPLAYDRIVERFUNCS
                    {
                    /* this structure of function pointers is
                       also added to or copied into the
                       bitmap headers on device driver
                       initialization of the bitmap */
                       Bitblt
                       ColorInfo
                       Control
                       Disable
                       Enable
                       EnumDFonts
                       EnumObj
                       Output
                       Pixel
                       RealizeObject
                       StrBlt
                       ScanLR
                       DeviceMode
                       ExtTextOut
                       GetCharWidth
                       DeviceBitmap
                       FastBorder
                       SetAttribute
                       DibBit
                       CreatDiBitmap
                       DibToDevice
                       SetPalette
                       GetPalette
                       SetPaletteTranslate
                       GetPaletteTranslate
                       UpdateColors
                       StretchBit
                       StretchDibits
                       SelectBitmap
                       BitmapBits
                       Inquire
                       Polyline
                       Polygon
                       Polyscan
                       Scanline
                    }


                TABLE XVI
                    DISPLAYDRIVEREXTFUNCS
                       {
                           SetCursorExt
                           MoveCursorExt
                           CheckCursorExt
                           BeginAccess
                           EndAccess
                           CreateDibDPevice
                           RealizeObjectExt
                           DibBltExt
                           EnumObjExt
                           ExtTextOutExt
                           UpdateColorsExt
                           SetPaletteExt
                           GetPaletteExt
                           SetPaletteTranslateExt
                           GetPaletteTranslateExt
                       }

            TABLE XV
            DDRAWOBJ
                {
                /* Remember that this is probably going to be
                    most heavily used in 32bit land
                    although it must compile for both. */
                OBJHDR
                ObjInstData;
            }


        TABLE XV
            DDRAWOBJ
                {
                /* Remember that this is probably going to be
                    most heavily used in 32bit land
                    although it must compile for both. */
                OBJHDR
                ObjInstData;
            }

        TABLE XVII
        PDevice
            {
                Dibeng
                DmmFlags
                DibengObj
                xCoord
                yCoord
                BitmapInfoHeader
                /* additional fields specific to palettized contexts */
                Colors[0x100]
                PaletteTranslateTable[0x100]
                InversePaletteTranslateTable[0x100]
            }