I’m a long time C/C++developer, but new to driver development. The company I work for has a remote control product. It captures video output using a video mirror driver, and shuts the host machine’s monitors off using SC_MONITORPOWER. Unfortunately, not all video cards correctly shut off the monitors, and I’ve been given the job of fixing this.
Is it possible to write a video filter driver that woulds sit below our video mirror driver, which would send a blank screen to the monitors rather than the “real” video? Or would it be possible to do this from within our mirror driver? I’m not clear on what make a mirror driver a mirror driver. It is some flag or configuration, or it just called that because that’s what it does and doesn’t have an inherent restrictions on what it can or cannot do?
I’m a long time C/C++developer, but new to driver development. The company I work for has a remote control product. It captures video output using a video mirror driver, and shuts the host machine’s monitors off using SC_MONITORPOWER. Unfortunately, not all video cards correctly shut off the monitors, and I’ve been given the job of fixing this.
You can’t. The video driver is the only entity that knows how to
program its chips to signal the monitor to go black. If it does not
respond to the standard request to kill power, then there’s nothing you
can do. You can’t black out the frame buffer, because that would black
out your view as well.
Is it possible to write a video filter driver that woulds sit below our video mirror driver, which would send a blank screen to the monitors rather than the “real” video? Or would it be possible to do this from within our mirror driver? I’m not clear on what make a mirror driver a mirror driver. It is some flag or configuration, or it just called that because that’s what it does and doesn’t have an inherent restrictions on what it can or cannot do?
All display drivers are peers. Each one covers some portion of the
desktop. Yours happens to cover the same region as one of the primary
graphics chips. The name is steeped in the mists of antiquity, because
there WAS a time that mirror drivers were special. Plus, like all
drivers, display drivers are separate from one another. You are in a
separate driver stack from the visible display drivers, so you can’t
command their hardware.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks for responding. Ok, so if our mirror driver is a peer to all other display drivers, then how do I get a driver inserted into the visible display drivers? Or is that not possible for architectural (or security reasons?
Referencing the diagram at https://msdn.microsoft.com/en-us/Library/Windows/Hardware/ff570589(v=vs.85).aspx is there no place I can insert a driver that would intercept the video information and transform it to all black, while at the same time capturing the real video information (not necessarialy in the same driver)?
Another approach I thought of would be to call WTSDisconnectSession on the host computer when a remote connection is made. That causes the host computer to display the logon screen, which is just as good as a blank screen for our purposes. The only problem is, how to I capture video output in the “disconnected” session? Everything is still running and the output must be buffered somewhere, but I have no idea where. I assume that our mirror driver is just going to forward what’s on the physical screen since it’s loaded at the kernel level and not per-user. Is there such a thing as a “per-user” video driver that would capture video information regardless of whether the session was connected? Obviously Terminal Services does that, but I can’t find any info on how it does it.
Windows display mirror drivers are a bit like zombies - not completely dead, but not really alive either.
Windows mirror drivers are based on XPDM display driver model. XPDM actually isn’t supported any more on Windows 8 and above. Even on Windows 7, attachment of a mirror driver did already disable AERO glass transparency look (DWM Desktop Composition) which is the exclusive display render path of Windows 8 and above.
Already on WinHEC 2008, Microsoft stated “Mirror drivers must go away!”. The replacement: DXGI Desktop Duplication API.
Still mirror drivers are present in recent WDKs and even supposedly working on contemporary Windows versions under limited circumstances. I wonder if anyone outside of Microsoft knows exactly what these limited circumstances are and if/when mirror drivers will eventually REALLY be eliminated.
Link above - Windows Display Driver Model (WDDM) Architecture
For simple architectural reasons, no filter driver can be inserted around WDDM display drivers.
Windows operating system architecture defines filters drivers ONLY for WDM drivers (single d). WDDM display drivers are not WDM drivers, but miniport drivers. Windows cannot define any general filtering mechanism for miniport drivers because miniport/port driver communication is device class specific.
“Per-user” video driver
Actually it is not a “per-user” display driver, it is a “per DirectX D3D application” display driver. It is a .DLL called “WDDM User Mode Driver” which is loaded into each one of these applications. Display content is located in a primary DX D3D surface of the current full screen DX D3D application. Most of the time this translates to Desktop Windows Manager (Dwm.exe).
Back to the original questions:
Is it possible to write a video filter driver (such does not exist in Windows OS architecture) that would sit below our video mirror driver (zombie with unclear capabilities and expiration date).
…mirror driver, which would send a blank screen to the monitors…
Mirror driver is NOT related to the original display graphics hardware in any way. If a mirror driver is attached, then Windows just renders twice. One time to the original adapter, another time to the mirror.
Thanks Marcel. I understand mirror drivers are going away at some point, but for the immediate time being we’re only concerned with Windows 7. And AFAIK, our mirror driver has been tested on Windows 8 and 10 and does work. The driver hasn’t been touched in a couple of years (according to source control).
Anyhow, back to the original problem. I need to capture the screen and transmit it to the remote, while blanking the screen on the host machine so nobody can observe what the remote user is doing.
Currently we’re shutting power off to the monitors but this doesn’t work in all cases, and seems a less than clean solution anyhow. Since video drivers are peers, can I write to the driver that’s controlling the physical monitor without affecting our mirror driver? I’ve tried creating a Direct3D hardware overlay, but not having any success so far getting that to work.
Ideally what I’d like to do is to capture the video output in a session that has has been detached from the console. If I call WTSDisconnectSession() I can get the current user’s session to detach from the physical monitors, but our mirror driver then captures Window’s logon screen instead of the disconnected session (which is understandable).
Cutting the long story short: If a solution exists, then it is NOT an element of the intersection set between regular Windows driver development solutions, clean solutions and solutions based on standard operating system mechanisms. Scope and complexity are larger than what can be described in a simple newsgroup thread anyway.
An acceptable approximation of a solution can probably be achieved by a combination of hacks. No single approach will work in all situations (as already observed above). E.g. Windows 7 has three completely different rendering paths:
XPDM main graphics driver (rendering by XPDM driver)
WDDM main graphics driver AERO OFF (block transfer rendering by WDDM kernel mode driver)
WDDM main graphics driver AERO ON (double buffer flip style rendering by WDDM user mode driver).
The amount of time needed for developing an initial approximation might even be finite and reasonable. Sill it will always remain a moving target. Example: NVidia release a new WDDM display driver about every 6 weeks. The next one might already break some of these hacks again.