Indirect Display Driver - kernel mode driver

Hi guys!

This is my first post in this forum. I’m quite new to the drivers topic, so please don’t fire me if this question “does not make sense”.

I’ve bought an usb to vga adapter which comes with a user-mode driver on it. The driver specifically is an Indirect Display Driver https://docs.microsoft.com/en-us/windows-hardware/drivers/display/indirect-display-driver-model-overview

The issue is that the display is not seen till the user logs on Windows 10. This PC is used in a domain by different users, so it’d be ideal that this driver would be kernel mode instead of user mode, so the display is seen even before the user logs on Windows. How can I accomplish it?

I’m confident this would be easy for you. In case you need to know a bit more about the driver, I show you the folder structure:

C:\PROGRAM FILES\HYC USB DISPLAY
│   config.ini
│   libusb0.dll
│   libyuv.dll
│   logo.ico
│   msvcr120.dll
│   unins000.dat
│   unins000.exe
│   WinUsbDisplay.exe
│
├───idd
│   ├───indirectdisplaybus
│   │   │   indirectdisplaybus.cat
│   │   │   IndirectDisplayBus.inf
│   │   │
│   │   ├───arm64
│   │   │       IndirectDisplayBus.sys
│   │   │
│   │   ├───x64
│   │   │       IndirectDisplayBus.sys
│   │   │
│   │   └───x86
│   │           IndirectDisplayBus.sys
│   │
│   ├───indirectdisplaydriver0
│   │   │   IndirectDisplayDriver0.cat
│   │   │   IndirectDisplayDriver0.inf
│   │   │
│   │   ├───arm64
│   │   │       IndirectDisplayDriver0.dll
│   │   │
│   │   ├───x64
│   │   │       indirectdisplaydriver0.dll
│   │   │
│   │   └───x86
│   │           indirectdisplaydriver0.dll
│   │
│   ├───indirectdisplaydriver1
│   │   │   indirectdisplaydriver1.cat
│   │   │   IndirectDisplayDriver1.inf
│   │   │
│   │   ├───arm64
│   │   │       IndirectDisplayDriver1.dll
│   │   │
│   │   ├───x64
│   │   │       IndirectDisplayDriver1.dll
│   │   │
│   │   └───x86
│   │           IndirectDisplayDriver1.dll
│   │
│   └───indirectdisplaydriver2
│       │   indirectdisplaydriver2.cat
│       │   IndirectDisplayDriver2.inf
│       │
│       ├───arm64
│       │       IndirectDisplayDriver2.dll
│       │
│       ├───x64
│       │       IndirectDisplayDriver2.dll
│       │
│       └───x86
│               IndirectDisplayDriver2.dll
│
├───lib_usb
│   │   msusbdisplay.cat
│   │   MSUSBDisplay.inf
│   │
│   ├───amd64
│   │       libusb0.dll
│   │       libusb0.sys
│   │
│   └───x86
│           libusb0.sys
│           libusb0_x86.dll
│
└───tool
    ├───arm64
    │       devcon.exe
    │
    ├───x64
    │       devcon.exe
    │       dpinst.exe
    │
    └───x86
            devcon.exe
            dpinst.exe

Kind Regards,
videoclocknet

I’m confident this would be easy for you.

You would be completely wrong. Kernel mode display drivers are hugely complicated. That’s why the indirect display driver model was created. Marcel is the real expert in this field; hopefully he will chime in, but it’s totally impossible to make this kind of change unless you were the author of the original driver and had access to the source code.

I’m not sure why this would not fire up until login. UMDF drivers can certainly run without a desktop, but perhaps there’s something in the IDDx model that needs this.

A kernel mode Display-Only-Driver could easily be wrtten in this case. Just use the Microsoft Windows Driver Kit sample Display Only Driver called KMDOD (available on GitHub underneath Windows-driver-samples video KMDOD)

The only difference to a UMDF IddCx Indirect Display Driver in user mode:

  • Kernel Mode is much more development work.
  • Kernel mode is less stable (every single software bug can crash the whole machine).

Functionality and feature set is almost the same for both:

  • Kernel Mode Display Only Driver
  • UMDF IddCx Indirect Display Driver in user mode
    After all, the IddCx framework relies on operating system supplied Kernel Mode Display Only Driver IndirectKmd.sys

This is a software developer forum, but I cannot recognize any software development knowledge in this post. All I see is information about a setup disk and its directory tree. This makes me ask the following questions:

Your concern is not seeing anything on the USB display while no user is logged in?

Isn’t this exactly the expected behavior of any Windows display?
Doesn’t Windows show the login screen on the primary display only?
Don’t the secondary display(s) remain black while login screen is shown on primary display?

What would you want to see on the USB dispplay screen while no user is logged in?
Would you want to see the login screen?
Then why not set the USB display as the primary display using Windows Display Control Panel? Then you can see the login screen on the USB display…

Marcel Ruedinger
datronicsoft

Marcel wrote a very good post and then deleted it. The bottom line here is that you are a USER of this device, and as a user there is absolutely nothing you can do about this. If you were the device DEVELOPER you could rewrite the driver, but you are not the device developer, and I guarantee you the device developer does not care about your issue. Sad face.

Thanks and yes. Even more than that: I guess that the “issue” isn’t even an issue. It is just regular expected Windows behavior which will solve the “issue” if applied correctly.

I am wondering why so many people are thinking of kernel mode first when they can’t solve a problem. Above we have a very nice example where moving to kernel mode could easily be done, but would not deliver any benefit (while of course still causing many additional problems).

PS: Actually I didn’t intend to delete this post. It just disappeared after editing. Guess the spam filter got me. I just read the forum instructions and waited for the admin to recover the post. Which then actually did happen :slight_smile:

PS2: I just noticed that my edit didn’t apply. Maybe you can still change it. The line “After all, the IddCx framework relies on operating system supplied…” should stand for itself within an own paragraph and no indent on the left hand side.

Marcel Ruedinger
datronicsoft