Display-only driver: does it suit for my aim?

Hello everybody!

I need display some logo picture above all windows. This logo should never be overlapped by neither top level windows nor any other. I decided to try to implement the client application and display driver.

I started with KMDOD example project from Windows Driver Samples. I figured out how and where I can change “RGB content” of the output buffer. Then I implemented the interaction between client application and KMDOD. By interaction I mean receiving and storing required data. In my case “required data” is the size of the picture, the coordinates of the position and data buffer with RGB values of every pixel of logo. So far so well. Now I can change display logo from client application and KMDOD will draw it over every single window.

But I have some questiont and misunderstanding.
After installation this driver it replaced VM display driver and if I am correct it also will replace any vendor display driver in case of not virtual machine installation. Is it ok? Does it mean I lose some functionality given by video card vendors?
I suppose KMDOD driver works like “function driver” and it means that it will communicates directly with the device. But it seems that for my aim it is enough to have some filter driver, does not it? But I see from forum that people says that you can’t just write a “filter driver” or it is difficult to do. But all this anweres without explanation why. Or probably I should load vendor driver myself. Is it possible? Does it make any sense?

I have read a lot of topics from this forum and oficial documentation. And I can see that display drivers are “something another” and have no relation to any other driver stack. Am I right that it is not useful for my aim to figure out deeply KMDF and UMDF and I should concentrate on WDDM?

Please, can someone clarify this? Thank you for your time and help.

WHY on this good green earth would you even CONSIDER doing this in kernel mode??? What line of thinking led that to be your first choice? There must be a half-dozen ways of doing what you describe using plain, ordinary, well-supported user-mode facilities, where your coding problems will not cause the system to come crashing down. Are you just talking about a small icon that always appears ? How does an “always-on-top” window not supply that need fully and simply, with about a day and a half of development effort?

In theory, a WDDM Filter Hook driver could possibly achieve this
HOWEVER - such drivers were never supported by Windows (thus of course never documented in any way).

Only about a hand full of companies worldwide (e.g. DisplayLink USB displays) managed to successfully write WDDM Filter Hook drivers for Windows 7 and 8.1
HOWEVER - for contemporary Windows 10 and WDDM versions, NOT A SINGLE working WDDM Filter Hook driver is known worldwide.

The effort to write a WDDM Filter Hook driver for Windows 8.1:
10+ man years
In case you doubt this number: I know what I am talking about - my product www.spacedesk.net is still using a WDDM Filter Hook driver on Windows 8.1 (as do e.g. DisplayLink USB-displays).

How could anyone seriously wonder why NOT to go down this path? The answer is very simple:

Do you have the necessary expertise to talk to undocumented operating system interfaces?
Probably you don’t…

Do you have the time and the budget of 10+ man years?
Probably you don’t…

Do you want to risk such huge amount of time and budget only to develop a device driver which nobody has ever proven to really work on contemporary Windows 10 WDDM versions?
Probably you don’t…

PS: WDDM Display drivers aren’t exceptional at all! They fully and nicely fit into the regular Windows operating system driver model. WDDM Display drivers are either standard miniport drivers (all miniports are colaborating with a port driver which is regular “Function Driver” in the devce stack - dxgkrnl.sys is the port driver for WDDM niniports). Newer simpler WDDM Indirect Display Drivers are regular UMDF Function Drivers in the device stack (collaborating with IddCx framework Filter Driver and Class Extension DLL).

Marcel Ruedinger
datronicsoft

@Tim_Roberts said:
WHY on this good green earth would you even CONSIDER doing this in kernel mode??? What line of thinking led that to be your first choice? There must be a half-dozen ways of doing what you describe using plain, ordinary, well-supported user-mode facilities, where your coding problems will not cause the system to come crashing down. Are you just talking about a small icon that always appears ? How does an “always-on-top” window not supply that need fully and simply, with about a day and a half of development effort?

Hi Tim. Thank you for your answer.
I am talking about a small icon just because I simplified the task. It is not possibly to keep your applicationt above every window because there is not “super-always-on-top” mode and any always-on-top window can be cover my window. Here is perfect article with explanation why. It is a main reason why I decided to do that in kernel mode. When you say “user-mode” you mean ordinary application or user-mode driver?

The second thing I need to make screen black. There is the function BlackOutScreen In KMDOD example project. This function reset every byty of frame buffer to zero in irder to make screen black. Why for example I can’t use the same way to make screen black using kernel-mode facilities from user mode application. It looks reasonable and reliable, doesn’t it?

VOID BASIC_DISPLAY_DRIVER::BlackOutScreen(D3DDDI_VIDEO_PRESENT_SOURCE_ID SourceId)
{
    PAGED_CODE();

    UINT ScreenHeight = m_CurrentModes[SourceId].DispInfo.Height;
    UINT ScreenPitch = m_CurrentModes[SourceId].DispInfo.Pitch;

    PHYSICAL_ADDRESS NewPhysAddrStart = m_CurrentModes[SourceId].DispInfo.PhysicAddress;
    PHYSICAL_ADDRESS NewPhysAddrEnd;
    NewPhysAddrEnd.QuadPart = NewPhysAddrStart.QuadPart + (ScreenHeight * ScreenPitch);

    if (m_CurrentModes[SourceId].Flags.FrameBufferIsActive)
    {
        BYTE* MappedAddr = reinterpret_cast<BYTE*>(m_CurrentModes[SourceId].FrameBuffer.Ptr);

        // Zero any memory at the start that hasn't been zeroed recently
        if (NewPhysAddrStart.QuadPart < m_CurrentModes[SourceId].ZeroedOutStart.QuadPart)
        {
            if (NewPhysAddrEnd.QuadPart < m_CurrentModes[SourceId].ZeroedOutStart.QuadPart)
            {
                // No overlap
                RtlZeroMemory(MappedAddr, ScreenHeight * ScreenPitch);
            }
            else
            {
                RtlZeroMemory(MappedAddr, (UINT)(m_CurrentModes[SourceId].ZeroedOutStart.QuadPart - NewPhysAddrStart.QuadPart));
            }
        }

        // Zero any memory at the end that hasn't been zeroed recently
        if (NewPhysAddrEnd.QuadPart > m_CurrentModes[SourceId].ZeroedOutEnd.QuadPart)
        {
            if (NewPhysAddrStart.QuadPart > m_CurrentModes[SourceId].ZeroedOutEnd.QuadPart)
            {
                // No overlap
                // NOTE: When actual pixels were the most recent thing drawn, ZeroedOutStart & ZeroedOutEnd will both be 0
                // and this is the path that will be used to black out the current screen.
                RtlZeroMemory(MappedAddr, ScreenHeight * ScreenPitch);
            }
            else
            {
                RtlZeroMemory(MappedAddr, (UINT)(NewPhysAddrEnd.QuadPart - m_CurrentModes[SourceId].ZeroedOutEnd.QuadPart));
            }
        }
    }

    m_CurrentModes[SourceId].ZeroedOutStart.QuadPart = NewPhysAddrStart.QuadPart;
    m_CurrentModes[SourceId].ZeroedOutEnd.QuadPart = NewPhysAddrEnd.QuadPart;

}

@Marcel_Ruedinger said:
In theory, a WDDM Filter Hook driver could possibly achieve this
HOWEVER - such drivers were never supported by Windows (thus of course never documented in any way).

Only about a hand full of companies worldwide (e.g. DisplayLink USB displays) managed to successfully write WDDM Filter Hook drivers for Windows 7 and 8.1
HOWEVER - for contemporary Windows 10 and WDDM versions, NOT A SINGLE working WDDM Filter Hook driver is known worldwide.

The effort to write a WDDM Filter Hook driver for Windows 8.1:
10+ man years
In case you doubt this number: I know what I am talking about - my product www.spacedesk.net is still using a WDDM Filter Hook driver on Windows 8.1 (as do e.g. DisplayLink USB-displays).

How could anyone seriously wonder why NOT to go down this path? The answer is very simple:

Do you have the necessary expertise to talk to undocumented operating system interfaces?
Probably you don’t…

Do you have the time and the budget of 10+ man years?
Probably you don’t…

Do you want to risk such huge amount of time and budget only to develop a device driver which nobody has ever proven to really work on contemporary Windows 10 WDDM versions?
Probably you don’t…

PS: WDDM Display drivers aren’t exceptional at all! They fully and nicely fit into the regular Windows operating system driver model. WDDM Display drivers are either standard miniport drivers (all miniports are colaborating with a port driver which is regular “Function Driver” in the devce stack - dxgkrnl.sys is the port driver for WDDM niniports). Newer simpler WDDM Indirect Display Drivers are regular UMDF Function Drivers in the device stack (collaborating with IddCx framework Filter Driver and Class Extension DLL).

Marcel Ruedinger
datronicsoft

Hi, Marcel. More than just clearly explanation about WDDM Filter Hook driver. Thank you very much.

Yes, really? Your remaining questions indicate that you still don’t fully understand. Maybe a few more hints below can help:

  1. You can only mess with your own WDDM driver, but you can never mess with other people’s WDDM drivers.

  2. Other people’s WDDM drivers do not have such simple framebuffers as your KMDOD example. They might be flipping between different framebuffers, they might be using overlays, the might page video memory in and out using virtual memory hardware (just to name a few examples).

  3. Even if you were able to hack other people’s WDDM drivers, then you would spend at least the first one of the 10+ man years only to reliably find the constantly changing frame buffers (and overlays, etc.) at every moment in time in all situations. But then you still haven’t managed to show anything on the screen yet. You might then find out that real framebuffers are tiled (just to mention the first and simplest one of hundreds of nasty details).

I can only think of one potentially feasible solution:

  • If I remember correctly, then WDK KMDOD sample keeps the configured POST display and does not touch it.
  • If that’s true, then you can install KMDOD example to replace the actual NVIDIA, Intel, AMD or VMWare display driver.
  • Then you lose a lot of resolutions, a lot of performance and many other display features (also VMWare features).
  • Then you have a very slow and primitive display, but it is yours.
  • Your KMDOD based driver can now fully control the very slow and primitive display.
  • You can now overlay whatever you want and you can blackout whatever you want whenever you want.

Marcel Ruedinger
datronicsoft

1 Like

If this is for a closed system, then you can replace the display driver with your own and do whatever you want. if this is for a general purpose project, this is infeasible since the design of the OS prevents it

Very good point! Thanks for mentioning! Actually obvious, but I have been misunderstood here about even more obvious facts already before…

One question, though: What makes you think that the design of the operating system prevents this? On every retail system the NVIDIA, AMD or INTEL GPU driver can easily be replaced by Microsoft Basic Display on the fly. This can either be done manually using Device Manager or by a SetupAPI application. If I am not missing anything, then the only thing needed is the security privilege to install device drivers. Same should apply to KMDOD which is very similar to a stripped down version of Microsoft Basic Display.

Marcel Ruedinger
datronicsoft

well, the idea of a requirement like this seems valid only in the case of a closed system. no mass distributed product should want to override the ordinary way in which Windows decides what pixels should be painted with what at a given location. That would be malware. But might be a valid requirement for a closed of special purpose system

yes, it is possible to replace the normal driver with another one, but unless you control the system, the next windows update will change the selection. And group policy can be assigned by administrators that affects this process too. again, if you control everything, then no problem. if intended for mass distribution, then there is no chance that this will work

Did you point out anything specific to displays here?

Or were you just referring to the two different topics below?

  • How to replace an OS supplied In-Box Driver?
  • How to replace a driver with a hardware vendor driver available on Windows Update?

These apply to a wide range of hardware besides displays. Probably they have already thoroughly been discussed/documented here and/or somewhere else before…

I personally would rather avoid buzzwords like “malware”. They tend to fill the gap opened by lack of facts and details with confusion and emotions (both preventing fruitful engineering discussions). Even the above mentioned case might be a valid solution if e.g. applied to secondary graphics adapters only and with full consent and awarenesss of the end-user (e.g. video wall solution with many additional older graphics adapters).

PS: Probably not necessary to discuss malware here anyway. Malware usually tries to hide from users. If malware was the intention here, then the above approach would be a very clumsy devising. Most users would immediately notice it (due to the reduction of display quality, performance and features).

Marcel Ruedinger
datronicsoft

I do not believe that anything I said pertains specifically to display drivers. I Agree that emotional decision making is usually wrong. I am sure that you know much more about display drivers than I do, but I don’t agree that most users will immediately notice a degradation in video quality and I further doubt that even informed users will impartially and objectively connect something that they agreed to install with that degradation. Informed and competent users yes - but for mass market distribution I think not