WO2001046803A2

WO2001046803A2 - Architecture for dynamically exposing hardware capabilities using a page description language

Info

Publication number: WO2001046803A2
Application number: PCT/US2000/041655
Authority: WO
Inventors: Robert L. Mendoza
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1999-12-21
Filing date: 2000-10-27
Publication date: 2001-06-28
Anticipated expiration: 2002-06-21
Also published as: AU2620201A; WO2001046803A3; DE10085323T5; GB0215176D0; GB2373902B; GB2373902A; DE10085323B4; TWI248020B; HK1046571B; HK1046571A1

Abstract

A software architecture provides a generic user interface capable of supporting a wide range of hardware devices and utilizes a page description language to expose the capabilities of the various hardware devices within a computer system. The page description language is utilized to define a user interface for the hardware device. A driver interface provides communications with a driver associated with the hardware device independent of driver type. A service layer of software that communicates via the driver interface exposes a hardware-independent interface to provide services for the graphical user interface.

Description

ARCHITECTURE FOR DYNAMICALLY EXPOSING HARDWARE CAPABILITIES USING A PAGE DESCRIPTION LANGUAGE FIELD OF THE INVENTION

The subject matter of the present invention relates generally to the field of software architecture; more particularly, the present invention relates to software that implements a user interface capable of communicating with driver software. BACKGROUND OF THE INVENTION

There are several traditional ways of exposing the properties of the hardware device to the end-user. One traditional method is through a simple command-line language interface. Alternatively, a pre-formatted configuration file can be created specific to this purpose. A more popular way of exposing hardware device properties to the user is through one or more static, configuration screens. These screens basically allow the user to input specific configuration values.

In the Microsoft Windows® operating system environment static screen pages, known as "property pages", are commonly used to provide access to hardware device control settings. A property page refers to a specific type of Microsoft Windows® dialog box that consists of a set of labeled tabs across the top edge of the dialog box. A dialog box is well known as an interface screen in the Microsoft Windows® operating system (OS) environment. By way of example, a typical computer system may have a display adapter, modem, and other hardware devices that can be configured to a variety of different settings or values. Associated property pages are provided through the operating system software to access and change these settings. Often times, the property page settings must be set to match the specific requirements of a particular hardware device.

One problem that has arisen is that as devices have gotten increasingly complicated, the property page information no longer fits on a single page or screen. Hence, the concept of tabbed pages was developed, where all of the properties of, say, a modem or graphics device are collected into multiple pages, each with a separate tab that may be accessed by the click of a mouse button. The different tab pages, for example, provide access to different aspects of a particular hardware device. The problem remains, however, that, as more information is needed to describe and control hardware device settings, there is a corresponding increase in the number of tabbed pages required. Sorting through and selecting the correct page for a particular hardware setting can be an imposing and unwieldy task for the end-user.

Another problem with property pages is that they generally tend to be very terse. From a user's standpoint, this requires a relatively high level of sophistication and familiarity with some very technical jargon. Depending on the technical knowledge of a particular user, the words and phrases of a property page may have little or no meaning. Novice users are often quite intimidated by property pages that contain technical terms. Consequently, they are typically reluctant to make changes to hardware device configuration values; or, if they do attempt to make changes, their lack of sophistication may lead them to make improper or erroneous device settings. In other words, to a rank beginner, it is neither easy nor obvious to know how to use property pages to properly configure specific hardware devices.

A related problem is that nowadays there are many different hardware devices being produced with the same basic functionality; however, each may have subtle variations that required different device settings. For instance, different graphics devices being manufactured today can have very different output device compatibility requirements. A generic property page could easily mislead a user by showing hardware capabilities that a particular device might lack. By way of example, the property page may include a setting for sending an output to a television, but the graphics device being used may lack that particular capability.

One prior art solution to these problems is to create custom property pages for each device. But this approach is cumbersome and lacks flexibility since a special set of property pages must be encoded for every different environment. Therefore, what is needed is a better way of exposing (or hiding) hardware capabilities to/from the end-user. SUMMARY OF THE INVENTION

The present invention comprises a software architecture for dynamic exposing capabilities of hardware devices in a computer system. In a basic embodiment, the invention comprises a user interface defined by a page description language, the user interface providing a set of user interface screens for configuring the hardware devices. A driver interface is also included to provide an extensible communication channel between the user interface and each driver associated with a hardware device. The driver interface accesses driver functions specific to each hardware device. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood more fully from the detailed description which follows and from the accompanying drawings, which however, should not be taken to limit the invention to the specific embodiments shown, but are for explanation and understanding only.

Figure 1 is a diagram of the two-tiered software architecture of the present invention.

Figure 2 illustrates one embodiment of the architecture of the present invention.

Figure 3 is an example showing a graphics display settings page as it may appear to the end-user in accordance with one embodiment of the present invention. DETAILED DESCRIPTION

A two-tiered software architecture is described. In the following description, numerous specific details are set forth, such as specific configurations, examples, display components, etc., in order to provide a thorough understanding of the invention. It will be obvious, however, to one skilled in the art, that these specific details may not be needed to practice the present invention.

The present invention is a software architecture that allows dynamic exposure of multiple hardware device capabilities with page description languages and programmatic scripting. As discussed previously, exposure of hardware capabilities has traditionally been performed either through a command line language interface, through a pre-formatted configuration file, or through one or more static configuration schemes (i.e., conventional property pages).

The software architecture of the present invention provides a generic user interface capable of supporting a wide range of hardware devices. In overcoming the drawbacks associated with these prior art techniques, the present invention advantageously uses a page description language to expose the capabilities of various hardware devices within a computer system. More specifically, the page description language is utilized to define a user interface for the hardware device. An extensible protocol is employed to allow specific capabilities of the hardware device to be automatically discovered by the user interface hosting software.

A key innovation is the technique of using a page description language to express a wide range of alternative user interfaces without altering the individual hardware or software components. This technique also facilitates the integration of information stored on the World Wide Web with the user interface screens used to configure the hardware devices. Thus, the present invention supports the integration of external information from the internet to assist the end-user in configuring a hardware device.

Another important advantage provided by the present invention is that it permits the user interface to be tailored for specific needs without having to change the underlying hardware or supporting software. In one embodiment, for example, the well-known Hypertext Markup Language (HTML) is utilized as the page description language. This easy-to-use scripting language allows a vendor to supply numerous, unique interfaces for the same hardware. A vendor or OEM can also empower its resellers and other agents to create unique versions of the user interface without changing or even having knowledge of the operation of the underlying hardware and software.

Figure 1 is a diagram illustrating the two-tiered software architecture of the present invention. At the top level of the architecture is the user interface, referred to in the diagram as common user interface (CUI) 11. Common user interface 11 is a generic, hardware-independent graphical user interface defined by a page description language. The second tier, or bottom level, of the architecture is the driver level, comprising driver interface 14 and driver core 15.

The diagram of Figure 1 also shows a CUI-Driver interface 12, which is tightly coupled with the specific driver implementation. In one embodiment, the CUI-Driver interface 12 is a custom Microsoft COM interface that encapsulates the concept of a driver call. The CUI-Driver interface 12 can be considered a thin wrapper that hides the differences between the function calls (e.g., ExtEscape, DevicelOControl, etc.) to the driver core 15. Essentially, the CUI-Driver interface 12 provides an extensible communication channel between common user interface 11 and all hardware drivers contained in driver core 15. It is this extensible communication channel that allows run-time discovery of supported hardware features.

Practitioners in the art will appreciate that CUI-Driver interface 12 provides access to all hardware specific or proprietary functions. Standard operating system calls, when available, are the preferred mechanism to invoke driver functions. When standard operating system calls are not available the CUI software may use a proprietary, driver specific call.

It should be understood that common user interface 11 is only loosely coupled to driver core 15 through CUI-Driver interface 12. The CUI software is independent of the hardware, with no hardware specific information hard-coded into its programs. This independence allows the same code to work with all hardware, assuming the particular driver supports CUI-Driver interface 12. In other words, common user interface 11 supports all drivers that have implemented CUI-Driver interface 12. Because the CUI software is independent of the hardware, it is relatively easy to extend the software to support new hardware components.

In one embodiment, common user interface 11 is patterned after the navigation model traditionally used by Web browsers. Web browsers provide a simple, easily understood model for navigation. Many users have become comfortable with and accustomed to navigating Web pages due to the popularity of the Internet. Thus, by emulating Web browser navigation techniques, the present invention allows end-users to leverage their existing knowledge.

Figure 2 is a detailed block diagram of one embodiment of the architecture of the present invention. The two-tiered nature of the architecture of Figure 2 is illustrated by the separation of the dynamic user interface elements (i.e., the common user interface 20) from the driver/hardware dependent elements (i.e., drivers 30).

At the bottom of the diagram are the individual drivers 33, each with its own associated CUI-Driver component (interface) 31. There is a one-to-one correspondence between a driver and a CUI-Driver component. For example, driver 33a is shown being connected to CUI-Driver component 31a, driver 33b to CUI-Driver component 31 b, and so on. Figure 2 shows multiple drivers 33 to represent the capability of the CUI-Driver software to communicate with drivers of various types of hardware devices (e.g., graphics, network, modem, etc.).

Note that the CUI-Driver interface is shown in the diagram as a plurality of COM components, each of which "sits" on top of an associated driver. Each CUI- Driver component 31 is independent of driver type (e.g., graphics, network, security, etc.) and has no explicit knowledge of the meaning of the data communicated across the interface. CUI-Driver components 31 provide a single consistent way of communicating with the driver software.

The CUI-Driver components basically provide a transparent pipeline between application and driver. In the Microsoft Windows® environment, there are several ways in which an application can communicate with the driver. These ways include: Escape/ExtEscape calls, DevicelOControl calls, basic input/output system (BIOS) calls, and other OS calls. These semantics of these communication methods vary widely.

It should be appreciated that the CUI-Driver component 31 is the key to seamlessly integrating the common user interface with new hardware devices. That is, the CUI software can automatically communicate with drivers that implement the CUI-Driver component interface. It should also be understood that the properties exposed by the CUI-Driver component are independently extensible by the various driver developers. In other words, driver developers can avoid development bottlenecks by extending the properties supported by the CUI-Driver component to add new properties as needed. This is simply a matter of making appropriate changes to the driver and the corresponding CUI-Driver component.

At the top of the diagram of Figure 2 are the CUI display components that are visible to the end-user. Three different types of display elements are shown: HTML pages 21 , static pages 22, and an independent hardware vendor (IHV) custom application, represented by block 23. HTML pages 21 are the custom HTML content pages that interface to the CUI-Services 25 via a set of ActiveX controls 24. Static pages 22 are a traditional set of property pages, which are also supported by the architecture of the present invention. The IHV custom application 24 provides a secondary level of control to a manufacturer (e.g., OEM) to customize the user interface. Through the IHV custom application 24 an OEM may create a new "look and feel" to the user interface, or to hide device capabilities from the end-user, without modification to the code. This capability is also available to a manufacturer of through HTML pages 21 using an HTML editor.

The ActiveX controls 24 are a well-known Microsoft technology that is used in the present invention to bridge the gap between the HTML environment and the hardware device environment. The ActiveX controls 24 provide a dispatch interface that allows scripting environments, such as Microsoft Internet Explorer™, to invoke the CUI functions.

As previously described, a Web browser may be utilized to display the HTML pages. Another approach is to use a standard Windows help engine, which is also HTML based, and which has a Web browser embedded within it. This latter approach provides the additional benefit of allowing the distribution of all the images and pages associated with the HTML pages via a single, compressed file.

The CUI-Services layer 25 exposes a set of high-level, hardware- independent interfaces that provide services for the various display elements. Each CUI-Service interface is dedicated to a particular technology, e.g., graphics settings, network settings, 3D settings, audio settings, etc. All CUI-Service interfaces are hardware independent. In this is yet another aspect of the extensible protocol of the present invention. The CUI-Services layer 25 makes calls to operating system functions to fulfill requests from the display elements. The CUI-Services layer 25 also masks the differences between various operating systems. This allows all OS-specific code to be localized within the CUI-Services modules.

Note that below the CUI-Services software layer is the driver with its corresponding implementation of the CUI-Driver component (i.e., interface). This interface exposes the driver's capabilities to the software in a consistent manner, completely abstracting the specific hardware/driver implementation. When a display element requires a property that is unique to a specific hardware platform, the CUI-Services layer 25 uses the associated CUI-Driver component 31 to obtain the information. To do this, the CUI-Services layer 25 relies on standard OS calls for standardized functions, and uses the associated CUI- Driver component for all proprietary extensions that relate to specific driver/hardware implementation.

The structure and definitions for one implementation of the interface between the CUI-Driver and CUI-Service level of software is listed in the Appendix.

Figure 3 is an example screen capture illustrating how a typical CUI page may appear to the end-user. Note that this example page shows the graphics display settings that allow the user to change the color model and screen resolution of the graphics hardware. The individual page contents appear within the CUI hosting application, which provides basic Web-like navigation services. Individual page contents are created using HTML for page layout. This approach permits a very high level of customization, for example, by a product development team or by OEM customers. The HTML-based pages invoke driver functions using ActiveX controls, as provided by the CUI software. It is appreciated that the page contents may take on any desired "look and feel".

In the example of Figure 3, the standard baseline pages consist of a "Quick Access Bar" across the top the page; a navigation bar on the left-hand side of the page; and the main page content on the right-hand side of the page. The Quick Access Bar is held consistent across all pages and provides access to the table of contents, keyword search, the technology-based home page, and other information. The navigation bar provides access to a set of context- sensitive links that lead the user to other pages related to the current page.

Claims

CLAIMS I claim:

1. A software architecture for dynamic exposure of hardware device capabilities comprising: a graphical user interface defined by a page description language; a driver interface that provides communications with a driver associated with the hardware device independent of driver type; and a service layer that communicates with the driver interface to provide services for the graphical user interface.

2. The software architecture of claim 1 further comprising: a dispatch interface to facilitate communications between the graphical user interface and the service layer.

3. The software architecture of claim 2 wherein the graphical user interface comprises one or more display components.

4. The software architecture of claim 3 wherein the page description language comprises Hypertext Markup Language (HTML) and the one or more display components include HTML pages.

5. The software architecture of claim 4 wherein the one or more display components further includes static pages.

6. The software architecture of claim 4 wherein the one or more display components further includes an application that permits customization of the graphical user interface via the Internet.

7. The software architecture of claim 2 wherein the dispatch interface comprises ActiveX controls.

8. The software architecture of claim 3 wherein the services provided by the service layer include calls to operating system functions to fulfill requests from the display components.

9. The software architecture of claim 3 wherein the service layer includes a set of proprietary extensions that specifically relate to the driver.

10. Apparatus for dynamic exposing capabilities of hardware devices in a computer system, a driver being associated each hardware device, comprising: a user interface defined by a page description language, the user interface providing a set of user interface screens for configuring the hardware devices; a driver interface that provides an extensible communication channel between the user interface and each driver, the driver interface accessing driver functions specific to each hardware device.

11.The apparatus of claim 10 wherein the page description language comprises Hypertext Markup Language (HTML).

12. The apparatus of claim 10 wherein the user interface employs a navigation model characteristic of a Web browser.

13. The apparatus of claim 10 wherein the user interface comprises one or more display components.

14. The apparatus of claim 13 wherein the one or more display components include HTML pages.

15. The apparatus of claim 13 wherein the user interface includes a service layer of software that communicates with the driver interface, the service layer providing services that include calls to operating system functions to fulfill requests from the display components.

16. The apparatus of claim 15 wherein the further comprising: a dispatch interface to facilitate communications between the user interface and the service layer.

17. The apparatus of claim 16 wherein the dispatch interface comprises ActiveX controls.

18. The apparatus of claim 16 wherein the service layer includes a set of proprietary extensions specifically related to each driver.

19. The apparatus of claim 13 wherein the one or more display components further includes an application that permits customization of the graphical user interface via the Internet.

20. A computer-readable storage medium having a configuration that represents data and instructions that cause a computer to: implement a user interface defined by a page description language, the user interface providing a set of user interface screens for configuring a set of hardware devices, a driver being associated each hardware device; implement a driver interface that provides an extensible communication channel between the user interface and each driver, the driver interface accessing driver functions specific to each hardware device.

21. The computer-readable storage medium of claim 20 wherein the computer- readable storage medium is further configured to cause the computer to implement a service layer that communicates with the driver interface, the service layer providing services that include calls to operating system functions to fulfill requests from the display components.

22. The computer-readable storage medium of claim 21 wherein the service layer includes a set of proprietary extensions specifically related to each driver.