JustKernel

Now coming to Windows Vista/Win7 or you call it WDDM way.

With the advent of Vista, MS changed its graphics architecture drastically. It moved the device driver to the user layer and removed the concept of drawing engine (GDI). GDI, no longer played any significant role in Vista architecture.

WDDM /Vista / Win7 display architecture consists of User Layer display driver dll and kernel mode diplay miniport driver. User mode display driver dll is loaded by Microsoft Direct 3D runtime. The kernel mode display miniport driver , communicates with the Microsoft Direct X graphics kernel subsystem.

In WDDM architecture,  DirectX graphics subsystem is the main components that does the drawing and directX handling. The Microsoft Direct3D runtime and Microsoft DirectX graphics kernel subsystem  perform more of the display processing (that is, more code is in the runtime and  subsystem as opposed to the drivers). This includes code that manages video  memory and schedules DMA buffers for the graphics processing unit (GPU).

The display/Video miniport driver dynamically loads the DirectX graphics kernel subsystem i.e. dxgkrnl.sys.

Vidpn : For someone who wants to development in Vista graphics, Vidpn is another concept he should study. Video present network (Vidpn) describes associations between drawing surfaces and the targets.

How the flow goes : When a user mode application request a drawing operation , the drawing calls is passed on to Direct3D runtime which then calls the user mode display driver. The display driver passes the call to kernel mode display miniport driver which utilizes the services of DIrectX graphics kernel subsystem (dxgkrnl.sys) to do the actual drawing, creating surface, querying child (meaning : When display miniport driver gets call from display driver, it passes the call to dxgkrnl.sys which does the actual operation.).

Now the big question:  How to create Virtual display adapter/virtual display miniport driver or filter driver in Windows 7 . How to extend your desktop to multiple monitors connected connected via USB.

The answer simply is you cannot do it . Microsoft doesn’t support it .In every mailing list you will find communications with the end result that it’s not possible.

True , there is no documentation for it, there is no support for it and Virtual Miniport Driver can’t be added to the Vista/Win7 graphical subsystem by following the good man’s path of doing what’s documented.  You have to be bad and have to adopt a hack to implement it.

I argue if you can hack SSDT table, make your virus hide in ISR table, then hacking graphical subsystem is not a big thing. Its doable .. but with a hack.. So what!!!! ..

Technique:

Starting .. Simple approach. Register your driver as miniport driver.. and sideline the actual minport driver. 🙂

Make a simple skeleton display miniport driver. Write dummy of every function that’s required in a display miniport driver (details of the functions is there in the DDK). Make an entry in the registry and register your driver as the display miniport driver.

Wow you are done.. Half the battle is won. Now you will start getting calls… Attach Windbg and you will start getting calls. But  yes, remember when you will test your driver your monitor screen will turn black and you wont be able to see anything. This is because you are just receiving the drawing the calls from user mode display driver but you are not drawing anything.  That’s the fun. enjoy 🙂

Remember I wrote one line bold at the initial part of the article. The display miniport driver loads the graphical kernel subsystem i.e. dxgkrnl.sys. So now follow the next step.  Once your display miniport’s DriverEntry is called, load the dxgkrnl.sys using zwLoadDriver .

Next step. Get the function pointers from the dxgkrnl.sys . And when your display miniport driver gets a drawing call, call the corresponding drawing function in dxgkrnl.sys.

Till now what you have achieved is that instead of the actual miniport driver , now your driver is doing all the handling.

Add support for additional surfaces- virtual surfaces to support multiple USB monitors.

when you get a call for the count of child devices , return +1 (for 1 additional virtual display/monitor supported i.e if you want to add 1 additional virtual surface for drawing). For every additional monitor you want to support increment the count by 1.

For each additional monitor support you need to create one virtual surface on which all the drawing will be done. Content of this surface will be read by the USB driver and transferred to extended monitor (Details explained in Series 2 article). In the Addsurface call , add additional surface corresponding to the monitors you want to support.

Important point: There is IOCTL call also that you need to hack. .I think IOCTL is issued when you wan to change the resolution or properties of additional monitor.  Right now I am stuck in that and trying to decipher it. Will post the details soon also will post other details as and when I progress through the project.

I struggled a lot to finalize the design for supporting multimonitor in Vista.. As there was no straight forward way, so had to do lot of R&D . So I thought why not share it.. It will definitely help someone..

Tthis article is purely based on my personal understanding and R&D. Feel free to comment on it, add suggestions or give your feedback..
Originally Posted On: 2011-08-10 02:55:40

Anshul makkar, anshul_makkar@justkernel.com

Tags: Desktop Extension- WDDM, Virtualmonitor