JustKernel

Here I will explain about the underlying functionality of the desktop extension/ multimonitor support with respect to WindowXP and Vista/Win7. Thus , along the way I will also make comparison of Windows 2000/XP graphics architecture with Windows Vista/Win7 architecture.

Windows XP uses XPDDM architecture . This architecture consisted of the following components :

•  Userlayer GDI layer
• Kenel layer GDI layer  (Graphics Device/Drawing Engine)
• Kernel layer display driver
• Video Miniport driver
• Actual graphics hardware.

Whenever user openes any windows or perform any action that requires drawing/rendering on the screen, the OS issues drawing calls to the User mode GDI layer which passes it on the Kernel GDI layer.

Now kernel mode GDI layer based on its capabilities does the drawing /rendering itself. For the components which it can’t render, it places calls to the underlying actual display driver which then does the drawing .

Video miniport driver controls the hardware. Most of the standard drawing operations for standard bitmaps are handled by the display driver or GDI itself. But for operations which require drawing on hardware specific bitmaps or the operations which require hardware capability, device driver passes the drawing operation to the video miniport driver. Graphics driver communicates with the video miniport driver via IOCTL or it can directly access the framebuffer/video memory of the graphics adapter.

So its all the layered architecture , easy to understand and comprehend.

Support for Extension Of Desktop/ Multi Monitor in XPDDM architecture.

XPDDM allows the user to add virtual miniport driver to the graphics subsystem.  So whats required to achieve the extension functionality is the virtual miniport driver and a virtual display driver.

These two components will make the OS believe that you have another display adapter connected to the system and now you can extend your desktop.. But still some details left.. Here are they:

So what you require is

• virtual Video miniport driver
• Virtual display driver
• USB client driver.

During virtual display driver initialization you need to create a temporary surface (file / buffer area) where you will do all the drawing operation.So during AddSurface call you create this buffer. Then during bitblt etc calls you draw to this surface. Remember when you get a bitblit/copybit or stretchblt or any other drawing call , don’t do the drawing yourself.. Just punt back the call to th GDI which will do the drawing. Only thing is to  provide the dimensions of your surface to the GDI.

Note: Our virtual dispay driver will be registered for the coordinates that are in extension to our main monitor. So our display adapter will get a call when we try to move certain window outside of our main monitor region.

Now the USB driver comes into picture. As soon as the virtual dispay driver is drawing to the surface, USB driver can read from the surface and then transfer the data to the secondary monitor which is connected via USB. Now another US B functional driver present on the monitor can take the data and write it on to its frame buffer.

This article is based on my understanding of the graphics architecture and R&D work . There may be many other aspects related to the system , which I may have not covered. This is just basic initial idea based on which the developer can build the system.

Please feel free and do write to me about your queries, feedback etc.

Next articles: Desktop Extension on Vista/Win7 and architecture details of WDDM

Originally Posted On: 2011-08-09 03:15:44

Anshul Makkar,  anshul_makkar@justkernel.com

Tags: Desktop Extension- XPDM, Originally Posted On: 2011-08-09 03:15:44, Virtualmonitor