WO1998043174A1

WO1998043174A1 - Method for emulating video port manager interface

Info

Publication number: WO1998043174A1
Application number: PCT/US1998/004466
Authority: WO
Inventors: Michael Andrew Yonker; Donald Tillery, Jr.; Wenbiao Wang
Original assignee: S3 Incorporated
Priority date: 1997-03-24
Filing date: 1998-03-05
Publication date: 1998-10-01

Abstract

General purpose computer applications which communicate with a VGA device via a specific function call protocol and can no longer do so because of the introduction of a new driver having as an input function calls different from the original application have inserted between the application and the new driver a converter for generating the proper sequence of new function calls in response to receipt from the application ones of the original function calls. The converter operates to insure that the timing is correct and that the new function calls are delivered in a sequence so as to achieve the desired result. The converter makes 32 bit and 16 bit operations transparent to the computer system and also allows certain system functions to be communicated to the application even though the new driver does not provide for such communication.

Description

METHOD FOR EMULATING VIDEO PORT MANAGER

INTERFACE

TECHNICAL FIELD OF THE INVENTION

This invention relates to computer systems in general and to the control of hardware within such systems in situations where the hardware has a control device interposed ahead of the input data control signals and more particularly to a system and method for substituting a first function call based protocol for a different function call based protocol for controlling a VGA device.

BACKGROUND OF THE INVENTION

A typical computer system performing, in addition to other operations, the operation of controlling video (from a video source), performing operations on that video in some manner, and delivering that video to a destination (such as to display or storage device). The hardware portion of such video operations is the VGA device which itself has three sections; the video port, the video window and the graphics control. The particular operation that is to be performed on the video is controlled by a program (called a client). For purposes of this patent, we will discuss the control of the video signals with respect to the video port section of a typical VGA device, but the invention is not limited to such a device nor is it limited to just the video port portion thereof.

There exists now a program called the Video Port Manager (VPM™) which is interposed between the client (called herein the VPM™ client) and the VGA device. The VPM™ provides a method for application to control the video port features of a VGA Device.

The other portions of the VGA are controlled by a display driver which contains a portion known as the DirectDraw™ driver (DDHAL). There is currently no conflict between the VPM™, which controls the video port portions of the VGA, and the DirectDraw™, which controls some other portions of the video port. However, soon the DirectDraw™ portion of the display driver will be modified to contain control for the same features of the video port that the VPM™ now controls. This will introduce a conflict between the two interfaces, i.e., between the VPM™ and the DirectDraw™. This conflict arises because the video port manager can attempt to control data to registers within the video port to control features of the VGA at the same time registers are also addressed by the DirectDraw™ portion of the display driver. Under this scenario, conflicts will arise and the system operation will fail.

Another problem is that a currently running application running under VPM™ cannot send control signals to the VGA directly and cannot send control signals to the DirectDraw™ (since the DirectDraw™ has its own input protocol which is different from the VPM™ protocol). Thus, such an application would stop running and it would have to be updated in order for it to work in the new environment. Updating is complicated and expensive.

Thus, a need exists in the art for a system and method for allowing existing VGA control applications to continue working without the need for modification of their output protocols.

A further need exists in the art for such a system which can perform economically and without adding overhead time penalties into the system operation.

A still further need exists for such a system which allows for full functionality without regard to whether the application is a 16 bit or 32 bit application.

A still further need exists in the art to minimize future driver development for non-DirectDraw™ applications while still allowing for those applications to function properly. SUMMARY OF THE INVENTION

These and other objects, features and technical advantages are achieved by a system and method which place a new software layer in front of the DirectDraw™ VPE (Video Port Extensions). The new layer emulates the VPM™ interface so that the VPM™ client continues to operate as before, believing that it is communicating with a Video Port Manager (VPM™). This new layer uses all of DirectDraw™, not just the VPE™ subsystem. Thus, the new layer acts as a proxy between the VPM™ client and the DirectDraw™ VPE. In this manner, the VPM™ client can operate with the DirectDraw™ VPE without having to be updated. Under this system, coordination between competing applications (clients) is performed by the new DirectDraw™ VPE device. The DirectDraw™ "sees two DirectDraw™ VPE clients (the VPM™ client and other clients) and it is designed with such competing situation, thus coordination is automatic.

There are situations where the VPM™ client must receive system status information in order to perform certain functions and this information is not passed through the DirectDraw™ driver to the new layer (called the Direct VPM™ (a TM of Cirrus Logic Corporation). In these situations, the DirectVPM™ layer operates to receive general system signals and commands and interprets these commands to the VPM client thus maintaining full functionality for the VPM™ client without requiring modification.

In addition, the general computer system keeps track of whether an application is a 16 bit application or a 32-bit application and provides different informational signals depending upon its knowledge of 16 bit or 32 bit status. Because of this, some 16 bit applications are denied certain functionality. The new layer that is used to buffer the signals to the VGA is also designed to mask the "true" user of the VGA from the system thereby allowing 16 bit applications to perform all the functions available to 32 bit applications.

One technical advantage of our invention is that all the currently operating VPM™ clients will automatically work without being rewritten so that existing applications do not become obsolete.

Yet another technical advantage of this invention is that there is no conflict between a VPM™ client and a DirectDraw™ VPE client because of the coordination inherent in the DirectDraw™ driver.

Another technical advantage is that developers, such as Cirrus

Logic driver writers (or Licensees of Cirrus Logic), do not have to continue to develop both a VPM™ version as well as a DirectDraw™ VPE version for every new application.

The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and the specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

FIG. 1 shows the details of one embodiment of the invention in block diagram form;

FIG. 2 shows a similar embodiment using the prior art structure and method;

FIGS. 3 & 4 show the input function calls of the VPM™ and the

DirectVPM™; and

FIG. 5 shows one embodiment of a structure and method for achieving 16 bit and 32 bit full functionality.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Before beginning the description of the invention, it might be well to review FIG. 2 with respect to the prior art. As shown in FIG. 2, system 20 has VPM™ client 11 which would open video port manager 22 via VPM™ 206 using the standard video port manager interface specified in the video port manager (VPM™) specification, dated February 29, 1996 from Cirrus Logic, Inc., which specification is hereby incorporated by reference herein. Video Port Manager 22 then controls the video port and video window portions of VGA 15 via inputs 201 and 202, respectively. VPM™ client 11 specifies the generic function calls (as will be detailed more fully with respect to FIG. 3) using the protocol set forth in the above-referenced VPM™ specification. The other clients 17 are DirectDraw™ 21 clients having a function call protocol as detailed in Microsoft® DirectX™ Software Development Kit available from Microsoft Corporation, which is hereby incorporated by reference herein.

The function protocol of DirectDraw™ device 21 is vastly different from that of VPM™ 22, as discussed above and as will be fully defined hereinafter. Other clients 17 talk to DirectDraw™ 21 via link to 220 which, in turn, then controls VGA 15 video window or graphics via 203 or 204. The remainder of the video is controlled through system interface

14 via 205 which controls mostly the graphics of VGA 15.

Video source 18 is a digital source of video which can, for example, include a television decoder, camera, an encoder/decoder, compressor/decompressor, or any number of video sources. The video is fed via 221 to the video port portion of VGA 15. VGA 15 then processes the coordinates with information in accordance with the instructions that are passed down via 201 from Video Port Manager 22. The video eventually will output via 222 to display device 16, which could be a CRT, a liquid crystal display (LCD), a television, or any number of display or storage devices.

It should be noted that lead 202 from VPM™ 22 and lead 203 from DirectDraw™ 21 both control the video window portion of VGA 15. Confusion is prevented by a system in which the driver (22 or 21) which has control of VGA 15 enables a bit switch in VGA 15 which then controls whether that video window is "on" or "off, so, if it is "on" and a particular driver wishes to use the video window, the "on" status tells the driver that another driver has control, that someone else is using it, and thereby blocks access by a view.

With respect to FIG. 2, if DirectDraw™ 21 is allowed to communicate with the video port portion of VGA 15, for example via 101, we could have a direct unresolvable conflict between Video Port Manager 22 and DirectDraw™ VPE 21 for the video port portion of VGA 15. The new DirectDraw™ VPE as discussed in FIG. 1 operates in this manner thus effectively eliminating the ability of VPM™ 22 to handle VPM™ clients 11 via link 201.

turning now to FIG. 1, there is shown one embodiment of our invention where VPM™ 22 is replaced by DirectVPM™ 12. The VPM™ interface acts just like VPM™ 22 to VPM™ client 11 via 206 and thus client 11 sees the same interface. However, instead of the output of DirectVPM™ 12 going directly to the hardware, it goes to DirectDraw™ VPE 13 and then via 102 to control the video port of VGA 15. This eliminates any conflict between the two drivers while also providing the same VPM™ interface to VPM™ client 11 as it expected with respect to prior art existing systems.

It should be noted that while the inputs to the VPM™ 22 and DirectVPM™ 12 from the client is the same in both situations, this is not so with the outputs. In the prior art situation (FIG 2) the output from VPM™ 22 is a stream of control code designed to drive VGA 15 directly. Essentially, the output code is a stream or combination of "l"s and "0"s (bits) which are used by VGA for control purposes. The input to VPM™ 22 (from Client 11) is a set of function calls having the protocol set forth in the above-referenced specification.

The input to DirectVPM™ 11 (FIG 1) from client 11 is the same as it was for VPM™ 22 but the output from DirectVPM™ 11 is vastly different since that output must obey the input function call protocol of DirectDraw™ VPE 13 which function call protocol as detailed in

Microsoft® DirectX™ Software Development Kit available from Microsoft Corporation, which is hereby incorporated by reference herein. The conversion between the input VPM™ protocol and the output (input to DirectDraw™) protocol is shown in Table 1 below. Note that only the function calls themselves are shown but that many of the function calls also have arguments associated therewith which must be factored into the final output call. In some situations these arguments can affect the timing of the output call as well as whether or not a call needs to be made or not.

TABLE I

VPM™ Provider Functions DirectDraw™ Functions

VPM™ Stream APIs DirectDraw™ Functions

The differences between DirectVPM™ 12 and the prior art VPM™ 22 can be shown with respect to FIGS. 3 and 4. In FIG. 3 there is shown the approximately 20 input function calls that would be received by VPM™ 22 from VPM™ 11 over input 206. Video port manager 22 processes each such call and provides data over output 201 to control VGA 15. This would be a data bit stream which controls the hardware depending upon the hardware configuration. This interface is described in more detail in the aforementioned VPM™ specification. In several instances, callbacks to client 11 must be made in response to a function occurring from some source, as, for example, from the user. These callbacks are controlled by callback control 301 over output 207 back to VPM™ client 11. By way of example, on such callback could be when a resizing is occurring on the screen and the

VPM™ client must cease operating for a period of time until the registers reclear and reset. Several callback types are processed by VPM™ 22 as described in the above discussed specification.

FIG. 4 shows DirectVPM™ 12 having the same function input calls over input 206 as shown in FIG. 3. However, the output is not a binary bit stream, but rather the output is a function call to DirectDraw™ 13 instructing DirectDraw™ 13 to perform the same functions so that DirectDraw™ 13 then converts the incoming function call (from DirectVPM™) to a bit stream for control of VGA 15.

The problem arises because there is not a direct correlation between any of the input function calls to the output functions calls of DirectVPM™ 12 and consequently some interpretation and buffering must take place to ensure that the system functions properly. As an example of one problem, if the "begin access" code were directly translated, it would result in the use of "lock" call to DirectDraw™ 13.

However, if this call is made at the wrong time or the wrong sequence, DirectDraw™ 13 will lock and cease to function. The actual correlation between the input protocol function call and the output protocol function call is shown in Table I.

An additional problem is that DirectDraw™ 13, as discussed above, does not feed back data to VPM™ client 11. Thus, those callback controls must be generated within DirectVPM™ 12 by callback control 401 as a result of certain actions being taken in the system. These callback functions are provided over output 207.

There are certain functions that have to be taken care of in addition to what has been described with respect to the function changes. One of these has to do with the use of 16 bit and 32 bit clients, and the other has to do with information that DirectVPM™ 12 must know about DirectDraw™ 13 at certain points in time.

As background, what happens is that DirectVPM™ 12 callback control 401 creates what the system calls a thread. That separate thread within DirectVPM™ 12 is designed to periodically inquire about certain operations of the system. One such query is: has one window that I am associated with been covered? or are we undergoing a resolution change? If neither of those events has occurred, the thread goes back to sleep. If either event (or others) have occurred, then the thread initiates the callback process within DirectVPM™ 12 via callback 401.

During this process, if the context of the thread was something unique for the 32 bit world, and a 16 bit client was connected, the system would not perform the function because it "knows" that the client is 16 bits even though the VPM™ is 32 bits. One of the problems is that the thread is a 32 bit feature and is not allowed to be created in the context of a 16 bit client. For example, the method used to determine if the resolution has changed is to create an invisible window. The system sends a message to the windows in the system when resolution is changing. Again, if DirectVPM™ 12 is servicing a 16 bit VPM™ client, the invisible window can be created but that window is marked as a 16 bit window even though it was created by a 32 bit DirectVPM™ 12. The system does not pass on the resolution changing message to 16 bi windows. For those reasons, our solution is to execute a separate 32 bit program which will create a thread and a window which will be recognized by the PC system as being fully 32 bit. It should be noted that in this discussion, operation means the entire PC system, as controlled by the CPU (not shown) and not system 10.

FIG. 5 shows the structure and method for creating a 32 bit window from 16 bit applications. This is shown in FIG. 5 where a VPM™ client 501 communicates its function calls to thunk layer 502 which is linked directly to thunk layer 503 (which is a 32 bit driver) which then communicates over 206 to DirectVPM™ 12. This effectively makes thunk layer 503 the VPM™ client. However, even though thunk layer 503 is a 32 bit client, the system CPU still maintains track of the fact that this originated as a 16 bit application (VPM™ client 51) and will forever after treat data to and from client 501 as a 16 bit client.

By initiating a totally independent VPM™ (a new client) 505 having 32 bit capability in a way in which it is treated by the system as totally independent of direct VPM™, it will receive all of the 32 bit system data and will have the privileges of a 32 bit application. VPM32AP 505 will then take over the control for doing functions such as creating the thread and watching the window to observe change of resolution, etc., messages. VPM32AP 505 has a method of communicating back to DirectVPM™ 12 via 504 such that the CPU system does not associate VPM32AP 505 application 503 with being started as a 16 bit client even though it is running concurrently with VPM™ client 501. DirectVPM™ 12 then communicates back to VPM™ client 501 through thunk layers callback control 401.

Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. The method for use in a general purpose computer system of communicating between an application having a first function call protocol and a computer system hardware control device operable to accept data stream inputs from a device driver which driver is operational under control of inputs thereto having a second function call protocol, the method comprising the steps of: receiving ones of said first function protocols, together with arguments associated with each said received function call; generating, based upon the received function call and the arguments associated therewith, one or more output function calls; and applying said output function calls as an input to said driver.

2. The method set forth in claim 1 wherein said hardware control device is a VGA device.

3. The method set forth in claim 1 wherein said device driver is a DirectDrawΓäó driver with VPE┬«.

4. The method set forth in claim 3 wherein said data which is presented to said control device is presented to the video port of said VGA.

5. The method set forth in claim 1 further comprising the steps of: monitoring the progress of certain first function calls; and modifying the presentation of the output function calls to the device driver in accordance with certain established protocols.

6. The method set forth in claim 1 further comprising the steps of: monitoring general system level operations; and sending control information to the application in accordance with certain of said monitored operations.

7. The method set forth in claim 1 further comprising the steps of: accepting function calls from either a 16 bit or a 32 bit application; and masking from the system the fact that certain applications are 16 bit applications thereby allowing the application to perform functions that it would otherwise not be able to perform.

8. The method set forth in claim 1 further comprising the steps of: accepting function calls from either a 16 bit or a 32 bit application; and masking from the system the fact that certain applications are 16 bit applications thereby allowing the application to receive data that would otherwise not be sent to it.

9. The method set forth in claim 1 wherein said generating step includes the generation of multiple output function calls timed in a specific pattern.

10. The method set forth in claim 1 wherein said generating step includes inhibiting the outputting of certain function calls.

11. An add-on computer program for use between an application program output and a computer system hardware device wherein the hardware device is controlled by a data stream input and wherein the data stream is generated by at least one device program which accepts a first set of function calls and converts each such function call to an appropriate set of data for presentation to the hardware device, the device operable for accepting such data from only one such device control program at a time and wherein the application program output is a set of function calls which are different from said first set of function calls, said add-on computer program comprising: means for accepting said different function calls from said application program; means for converting accepted ones of the application program calls into zero or more function calls within said first set of function calls; and means for presenting said converted function calls to said device control program.

12. The invention set forth in claim 11 wherein said computer system includes at least one application having function calls which correspond to said first set of function calls, and means for arbitrating between function calls from said one application and said converted function calls.

13. The invention set forth in claim 11 wherein said hardware device is a VGA device within a general purpose computer.

14. The invention set forth in claim 13 wherein said device control program is a DirectDrawΓäó driver with VPE┬«.

15. The invention set forth in claim 13 wherein said data which is presented to said device is presented to the video port of said VGA.

16. The invention set forth in claim 11 further comprising: means within said add-on for monitoring the progress of certain function calls from said application; and means for modifying the presentation of the function calls to the device control program in accordance with certain established protocols.

17. The invention set forth in claim 11 further comprising: means within said add-on for monitoring general system level operations; and means for sending control information to the application in accordance with certain combinations of monitored operations.

18. The invention set forth in claim 11 further comprising: means for accepting function calls from either a 16 bic or a 32 bit application; and means for masking from the system the fact that certain applications are 16 bit applications thereby allowing the application to perform functions that it would otherwise not be able to perform.

19. The invention set forth in claim 11 further comprising: means for accepting function calls from either a 16 bit or a 32 bit application; and means for masking from the system the fact that certain applications are 16 bit applications thereby allowing the application to receive data that would otherwise not be sent to it.

20. A DirectVPMΓäó converter for accepting functional statement protocols from a VPMΓäó client application, said functional statement protocols operational for controlling the video port of a VGA device operating within a computer system, in which a DirectDrawΓäó driver with VPE┬« is interposed between the output of said converter and said video port, said driver operational in response to certain established input commands for providing outputs for controlling said video port, and wherein said converter includes a protocol for converting the functional statements from said client application into proper input functional statements for said driver such that said video port receives commands generated by said client application and responds thereto in the manner anticipated by said client application.

21. The invention set forth in claim 20 wherein said converter monitors general system level operations and sends control information to the application in accordance with certain combinations of monitored operations, without the need for input from said DirectDrawΓäó driver with VPE┬«.

22. The invention set forth in claim 20 wherein said converter accepts function calls from either a 16 bit or a 32 bit application and masks from the computer system the fact that certain applications are 16 bit applications thereby allowing the application to receive data that would otherwise not be sent to it.

23. A computer product containing a set of program control code, the code operable in a computer system for communicating between an application having a first function call protocol and a computer system hardware control device operable to accept data stream inputs from a device driver which driver is operational under control of inputs thereto having a second function call protocol, the computer product controlling the steps of: receiving ones of said first function protocols; generating, based upon the received function call, zero or more output function calls; and applying said output function calls as an input to said driver.

24. The computer product set forth in claim 23 wherein said hardware control device is a VGA device.

25. The computer product set forth in claim 23 wherein said device driver is a DirectDrawΓäó driver with VPE┬«.

26. The computer product set forth in claim 25 wherein said data which is presented to said control device is presented to the video port of said VGA.

27. The computer product set forth in claim 23 further controlling the steps of: monitoring the progress of certain first function calls; and modifying the presentation of the output function calls to the device driver in accordance with certain established protocols.

28. The computer product set forth in claim 23 further controlling the steps of: monitoring general system level operations; and sending control information to the application in accordance with certain of said monitored operations.

29. The computer product set forth in claim 23 further controlling the steps of: accepting function calls from either a 16 bit or a 32 bit application; and masking from the system the fact that certain applications are 16 bit applications thereby allowing the application to perform functions that it would otherwise not be able to perform.

30. The computer product set forth in claim 23 further controlling the steps of: accepting function calls from either a 16 bit or a 32 bit application; and masking from the system the fact that certain applications are 16 bit applications thereby allowing the application to receive data that would otherwise not be sent to it.

31. The computer product set forth in claim 23 wherein said generating step includes the generation of multiple output function calls timed in a specific pattern.

32. The computer product set forth in claim 23 wherein said generating step includes inhibiting the outputting of certain function calls.

33. A method of arranging a general purpose PC system having a DirectDrawΓäó driver with VPE┬« ahead of a VGA, said driver operational in response to certain established input commands for providing outputs for controlling said VGA, said method comprising the steps of: establishing a direct VPMΓäó converter for accepting functional statement protocols from a VPMΓäó client application, said functional statement protocols operational for controlling the video port of said VGA; and said converter including a protocol for converting the functional statements from said client application into proper input functional input statements for said DirectDrawΓäó driver with VPE┬« such that said video port receives commands generated by said client application and responds thereto in the manner anticipated by said client application.

34. The method set forth in claim 33 wherein said converter accepts function calls from either a 16 bit or a 32 bit application and masks from the computer system the fact that certain applications are 16 bit applications thereby allowing the application to receive data that would otherwise not be sent to it.

35. The method set forth in claim 33 wherein said converter monitors general PC system level operations and sends control information to the application in accordance with certain combinations of monitored operations, without the need for input from said DirectDrawΓäó driver with VPE┬«.