WDDM Display Only Driver to create a Virtual Display/Monitor

I am a student who just started in Windows Driver Development. The project I am trying to do is to create a Virtual Monitor and capturing its framebuffer.

The examples that Microsoft have about Display Drivers is a KMDOD and i don’t know if i will be capable of archiving my goal using this type of driver.

Another doubt i have is that if KMDOD can use a real GPU to render the windows on the display. In WDDM 1.2 features documentation it says that “Windows handles the 2-D or 3-D rendering by using software-simulated GPU.” but on MS forums “Even WDDM Display-Only-Drivers (which do not have a WDDM User Mode Driver) need actual graphics adapter hardware.” so i do not know if the rendering would be done by HW GPU or SF GPU.

You would be much better off targeting Win7 (or XP) and starting with the sample XPDM mirror driver. A WDDM mirror is way outside the scope of a student project.

But is the XPDM model compatible on windowws 8.1 and above? I tougth it was not.
Also the extrictly the feature i need is not mirror one but to create an independent virtual display i don’t know if that can be achieved with mirror driver.

No, it’s not. Mark’s point (and he is entirely correct) is that a WDDM driver is a very complicated beast, and is clearly not a good place for a beginner to start. If you are creating your own project, you should make another choice. The USB world is a much better place to learn about driver development. There are hundreds and hundreds of little USB experimenter’s boards where you can control both the firmware on the device and the driver on the host.

What’s the point of a virtual monitor that’s not a mirror? If the user can’t see the results, he’s never going to drag any windows to it, and he won’t be able to interact with the windows to click any buttons.

The procjet has to be a display driver is not an option to change the driver type since what is wanted to archive with the driver is to capture the framebuffer to send it over the network. As KMDOD semed the easier option is what i’ve choose but still has the doubts about virtualized GPU

You are aware, I hope, that there are dozens of products out there that do this, including several that are open source. Many of them do it with no kernel drivers at all. Have you looked at any of the VNC products?

And if you want to capture a framebuffer, why would you not want to capture the live desktop? What is the point of capturing an invisible screen? I just don’t think you have thought through this effort at all.

In the scenario where it will work hooking functions is not an option since there are some incompativilities with that method. Aslo the monitors are needed to switch them between primary monitor when aplications are lanched to have one aplication in their own display to avoid superposition between them.

Okay i’ve followed your recommendation and choosed to change to XPDM, apart from VirtualMonitor project source code where can i find more examples to create a virtual monitor? thanks!

Your whole concept seems very strange to me. How is the user going to move an application to a monitor that he cannot see? How will he ever know that it is where it belongs? I just don’t think you have worked through the user stories here. If you want to have a single application send its window over the network to another computer for remote display, there are traditional ways of doing that which are MUCH less trouble than writing a display driver.

The Windows 7 (7600) DDK includes an XPDM mirror driver sample. That is probably your best starting point. Remember that the ONLY difference between a normal display driver and a mirror driver is the way it is configured. You would just change the user-mode app in that sample to configure the driver as an “extend the desktop” monitor instead of a mirror monitor.

The long story can be cut very short:
Creating virtual display monitors was never supported by recent Windows versions(since Windows 7). End of story.

Two types of WDDM display drivers can reasonably be written by regular driver developers:
WDDM DOD Display Only Drivers (e.g. KMDOD).
WDDM IddCx Indirect Display Drivers.
The downside of both: Currently they both need real hardware.
The downside of Display Only Drivers: No GPU acceleration.

For those who want to go beyond the regular and documented scope of Windows operating system support and really write a contemporary virtual display driver: Write a USB bus driver which emulates a USB bus with connected display device (e.g. DisplayLink USB display). Then install this WDDM IddCx Indirect Display sample on the virtual USB driver’s emulated display device: https://github.com/kfroe/IndirectDisplay
Voila - there is your virtual display!

Hint: I heard that the above named IddCx sample can supposedly even be operated without hardware when starting Windows with “Driver Signature Enforcement” disabled (F7).

Marcel Ruedinger
datronicsoft

As a note to the original poster, Mr. Ruedinger knows what he is talking about.

Hello @Tim_Roberts @Marcel_Ruedinger,

I’m a student working on a project to capture the desktop of an Azure Windows 10 virtual machine using Microsoft Desktop Duplication API. Unfortunately, since there is no monitor, the second I exit the RDP session the API stops working. It appears I need a “virtual display adapter” to “fake” having a monitor so that the Desktop Duplication API can work. This sample you @Marcel_Ruedinger have linked appears to be the best thing I’ve found in a week of searching to fix this issue, do you happen to know if it can fix my problem? Is there anything else I should be aware of/look at to fix this problem?

As a summary: I’m looking to capture the desktop of a Windows 10 headless VM, and it appears I need a “virtual display adapter” to trick the GPU into actually rendering the desktop since there is no monitor.

Thanks for your help, I really appreciate it!

Philippe

@philippemnoel In your studies, have you learned what necroposting is? Cuz, you know, we discourage it here. As you know, because you’ve done this:

Peter

Once you end the RDP session, there is no desktop. What, exactly, do you plan to capture? Without RDP, what applications are going to be running? Where will they get their input? I don’t think you’ve thought this through.

Hi @Marcel_Ruedinger,
i read your discuss and I want to make sure whether my understanding is correct:
1.I have to write a USB bus driver which enumerated the graphic devices and connected the graphic card. I assume that it can help me to leverage discrete GPU resource to generate desktop. Is it correct?
2.Then install the IddCx driver on my USB bus driver. And I assume that my IDDCx driver should get the virtual monitor with black screen, is that correct?
3.Hook the graphic source and usb driver target.
4.Deal with graphic image data (MSDN: video memory management and GPU schedule). And I assume that my IDDCx driver will get the desktop image of virtual display, is it correct?

@KangLee, you need to start a new thread, and ask your questions after tell us what you’re actually doing. You have tacked your reply on to the end of a long dead conversation. which may or may not apply to your situation, and your list above has a number of contradictions. Do you actually have USB hardware? If not, then why on earth would you think you need a USB driver? If so, then it’s not really a virtual display, it’s a real display.

Sorry for making this dead thread even longer and even more dead. However, to avoid confusing even more people, I cannot leave this “understanding” of my post uncommented:

In this “understanding” mentioned above, I can only see confused fragments of statements which I cannot relate to my post in any way. I wouldn’t even know where to start. I cannot even list all errors which I can spot immediately when reading this “understanding”. Just a few examples:

  1. The USB bus driver has nothing to do with the graphics card (no matter if discrete or not).
  2. There is never any black screen involved (at least if you do everything correctly).
  3. There is nothing to hook. If you had read my other posts here (the days of WDDM Filter Hook drivers are over), then you would know this.

I have only one possible explanation how anyone could come up with exactly such kind of a a messed up “understanding”: There is a very questionable WDDM USB sample on GitHub. Two of this sample’s major flaws:

  1. It claims to be Open Source USB WDDM. But only irrelevant USB code is Open Source. The relevant WDDM code needs to be obtained separately and binary only. This fact is deliberately hidden behind confusing and ineffective description and software architecture (exactly the same confusion which I recognize in the above “understanding”).

  2. It is a WDDM Filter Hook Driver. Dead technology since 2016 (Windows 10 1607). Dead PCs since 2018 (Windows 10 1803) in many cases when WDDM Filter Hook drivers are installed.

Marcel Ruedinger
datronicsoft