System and method for graphics remapping in hypervisor

The present invention relates generally to systems and methods for graphics remapping using hypervisors.

Often users wish to electronically link their personal computer to multiple display monitors instead of a single monitor. This allows images to be presented on either a larger display or multiple displays, and can also create the appearance of having more “desktop” room. However, representing data on multiple displays that respectively use graphics adapters made by different respective vendors may not be possible on some operating systems, such as Windows Vista (a trademark of Microsoft Corp.), that do not possess the ability to accommodate multiple different graphics adapters. Different graphics adapters vary and may use different specifications, such as different “refresh rates,” which determine the number of times per second that a displayed image is regenerated.

As understood herein, when an operating system does not possess the capability to send data through multiple graphics adapters made by different vendors, either (1) an additional operating system designed to accommodate multiple displays is required or (2) a supplemental remedy installed by the personal computers vendor which allows a single vendor-modified driver to control multiple graphics adapted outputs is required.

Thus, when an operating system does not possess the capability to accommodate multiple displays, it may result in unexpected hardship for the user. Also, it may be unforeseen at the time of purchasing a personal computer that the user may later wish to employ the use of multiple displays. If not foreseen, the vendor of the personal computer may not include a supplemental remedy as stated above. Should such a circumstance occur, the user would be left without a solution for displaying data on multiple displays. The present invention provides software to be implemented in addition to a main operating system that will allow a user to display data on multiple displays using graphics adapters made by different vendors.

A hypervisor operating system implemented on a computer-readable medium can be executed by a digital processor to present to a main operating system a single virtual video driver. The hypervisor receives demanded display data from the main operating system representative of pixels and sends first pixels to a first video driver associated with a first video display and also sends second pixels to a second video driver associated with a second video display.

In some implementations the hypervisor operating system acquires one or more specifications from both of first and second graphics adapters respectively associated with the first and second displays. The specifications can be display resolutions and/or refresh rates or other parameters. In any case, the hypervisor operating system can use the specifications to generate a list of available specifications for provision thereof to the main operating system.

Also, the hypervisor operating system can query the main operating system for video monitor resolutions and/or desktop options supported by the main operating system. The desktop options can include mirroring, spanning, or cloning.

In another aspects a computer system includes a processor and at least two displays configured to display data demanded by a main operating system executable by the processor. The system also includes a computer readable medium bearing a hypervisor operating system executable by the processor to present to the main operating system one and only one display driver for receiving data from the main operating system and distributing the data to at least first and second display drivers transparently to the main operating system.

In yet another aspect, a method for presenting pixels demanded by a main operating system on at least first and second displays associated with respective first and second graphics adapters includes presenting one and only one virtual display driver to the main operating system. The method also includes distributing pixel data sent to the virtual display driver to the first and second graphics adapters.

The details of the present invention, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:

FIG. 1 is a block diagram of a non-limiting system in accordance with present principles; and

FIG. 2 is a flow chart of non-limiting logic in accordance with present principles.

Referring initially to FIG. 1 , a personal computer 10 is shown which contains a memory 12 that is used for data storage and may include non-volatile memory such as flash memory and/or volatile memory such as random access memory (RAM). The personal computer 10 also includes a processor 14 , which may be, without limitation, a PowerPC® processor available from Lenovo Corporation (or other processors common to the industry) and includes the capability to execute logic, including the logic set forth in FIG. 2 .

After booting from a lard drive in accordance with principles known in the art, the memory 12 also contains a main operating system 16 , which may manage plural applications 18 . The main operating system 16 may be, without limitation, Windows Vista (or other operating systems common to the industry).

In accordance with present principles, the main operating system 16 communicates with a hypervisor 20 that may also be stored in or booted to memory. Although only a single main O.S. 16 is shown, the preferred hypervisor 20 is capable of managing multiple operating systems on the personal computer 10 simultaneously. Moreover, the hypervisor 20 allows plural operating systems to execute functions jointly.

As shown in FIG. 1 , the hypervisor 20 can instantiate a single virtual driver 22 that can communicate with plural software-implemented display drivers 24 . A display driver 24 is provided for each of plural graphics adapters 25 that are associated with respective computer displays 26 . The adapters 25 , which may be implemented as graphics cards, can be directly attached to the computer or attached through a docking station. Each adapter 25 may have more than a single display 26 attached to it. In any case, it is to be understood that the adapters 25 shown in FIG. 1 are differently configured from each other, i.e., they are not duplicates of the same adapter.

A keyboard 28 , pointing device 30 , and/or other input devices are also typically included with the computer.

Moving to FIG. 2 , the logic for representing data on multiple displays with different actual drivers is shown. Beginning at block 32 , the logic instantiates the virtual driver 22 . Once the virtual driver 22 is evident on the hypervisor 20 , the virtual driver 22 is presented to the main operating system 16 at block 34 . The main operating system 16 regards the virtual driver 22 as the only graphics driver with which communication is held by the main O.S. 16 .

At block 36 the virtual driver 22 acquires particular specifications from each graphics adapter 25 using any format for communication between the personal computer 10 and the peripheral displays 26 , one example being Display Data Channel (DDC) plug and play. One common specification that may be acquired by the virtual driver 22 is the resolution of each peripheral display 26 . The resolution of each peripheral display 26 indicates the number of pixels per square inch that may be generated on that particular display. The virtual driver 22 also may acquire from each adapter 25 the refresh rate of the associated display 26 .

In addition, at block 37 the hypervisor 20 queries the main O.S. 16 for the video monitor resolutions and/or desktop options that the main O.S. 16 supports. To illustrate, some display options include, but are not limited to, “mirroring” (where the same image is displayed on all peripheral displays 26 ), “spanning” (where a single display is spread across multiple peripheral displays 26 ), and “cloning” (where the same images is displayed on all peripheral displays 26 , but with different resolutions being used for each peripheral display 26 ).

Moving from block 37 to block 38 , the virtual driver 22 combines the different specifications of each actual driver 24 , creates a list of available specifications that match the desktop options and resolutions provided by the main operating system at block 37 , and sends this information to the main operating system 16 when, e.g., a DDC or other resolution support query is issued. If the main O.S. supports only a single unified display, the lowest refresh rate and lowest resolution from the displays 26 are used.

Accordingly, at block 40 one or more of the specifications can be selected by the main operating system 16 to generate either a single unified display or an “extended desktop” across multiple displays, depending on which capability the main operating system 16 possesses. In cases of a single unified display, the main operating system 16 believes it is generating data that is to be displayed on a single display. The main operating system 16 generates demanded display data using the lowest refresh rate of all displays connected to the personal computer 10 . Alternatively, in situations where the main operating system 16 utilizes the format of an “extended desktop” used across two displays, the main operating system 16 transmits demanded display data intended to be displayed on multiple displays, but in any case the main O.S. 16 believes that it is sending the data to a single driver, i.e., the virtual driver 22 , which is presented to the main operating system as being a driver for a single display possessing the specifications selected by the main operating system at block 40 . Thus, it is to be understood that the steps shown in FIG. 2 need not be executed in the order shown, e.g., step 34 can occur after step 40 .

At block 42 , the virtual driver 22 receives the demanded display data from the main O.S. 16 and then in effect demultiplexes the data, sending portions of the demanded data representing a first group of pixels to one display driver 24 and other portions of the demanded display data representing other pixels to the other display driver(s) 24 , for display of the data on the respective displays 26 . In mapping which pixel is sent to which driver 24 , the virtual driver 22 of the hypervisor 20 simply maps each pixel to its corresponding display using the position of the pixel in the demanded display data and the corresponding combined resolution of the aggregate displays 26 .

The tables below provide examples to illustrate the above description of the hypervisor 20 with virtual driver 22 , which can be stored on computer-readable media such as solid state memory and disk-based memory for execution by a digital processor.

The below example is broken down into monitors, graphics adapters, and combined graphics resolutions. Each graphics adapter can attach to one monitor, reporting back to the hypervisor 20 the supported resolutions. For example, consider a system that has two graphics adapters 25 attached, with the following example resolutions being sent to the hypervisor 20 at block 36 of FIG. 2 :

Monitor 1 →Graphics Adapter 1 Resolutions 640×480 800×600 1024×768 Monitor 2 →Graphics Adapter 2 Resolutions 640×480 800×600 1024×768 1280×1024

The virtual graphics driver 22 combines, at block 38 , the above resolutions into larger offerings, depending on the capabilities reported by the main O.S. 16 at block 37 . Assuming the main O.S. 16 supports wide desktop resolutions, the virtual driver 22 passes through to the main O.S. 16 the following supported resolutions, using the below table to map the pixels represented by the demanded display data to the plural displays 26 :

Main OS 1 Resolutions 640×480 (Monitor 1 ) 640×480 (Monitor 2 ) 640×480 (Mirrored) 800×600 (Monitor 1 ) 800×600 (Monitor 2 ) 800×600 (Mirrored) 1024×768 (Monitor 1 ) 1024×768 (Monitor 2 ) 800×600 (Mirrored) 1240×480 (Spans both monitors) 1280×1024 (Monitor 2 ) 1600×600 (Spans both monitors) 2048×768 (Spans both monitors)

To further illustrate the mapping, in non-limiting implementations the mapping can be done similarly to the way graphics adapters currently map pixels, with the hypervisor providing the translation from the oversize location to the physical card's supported location. The operating system can have a screen region for each object (i.e., an XY coordinate for a corner pixel). Based on the information from the multiple graphics adapters, the hypervisor can remap the information from the extended region to the narrower region covered by the display adapter. For example:

Adapter 1 : 800×600 Adapter 2 : 800×600 Virtual adapter: 1600×600

In the above example the operating system can make a call for an object at pixel location 1000×300, and then in response the hypervisor virtual adapter remaps the information to be output to “adapter 2 ” at pixel location 200×300.

While the particular SYSTEM AND METHOD FOR GRAPHICS REMAPPING IN HYPERVISOR is herein shown and described in detail, it is to be understood that the subject matter which is encompassed by the present invention is limited only by the claims.