Modify KMDOD sample for USB display

Tim

there is no USB to HDMI class device.
Because USBVideo.sys could only be used for video capture(video in, from device to host).
So I need a driver, which is video out, transfer the desktop to another monitor(with HDMI interface), by this USB to HDMI adapter, here I need to develop my own USB to HDMI device driver, extend another monitor.

Here I study the WDDM
download the KMDOD driver
download vs express 2013 trial version(90 days or 30 days?)
download the WDK 8.1 update
and compile the sample to generate the .sys, .cat, .inf.

What should I do for the next step to have a real experience of this driver?
How to use this driver to get a real experience?
How to install this driver?
Should I have another display card for this KMDOD? Cause I found, KMDOD could not be primary adapter driver.
And my PC windows 8 system, the video adapter use the WDDM1.1, so it seems that this sample could not be used at WDDM1.1 system?

After I get clear picture of this driver, at least get a user experience of this driver, then I get into the details of the codes, and then try to modify it for USB to HDMI display adapter.

So, pls help, at first, how to use this driver, and what environment needed?

Anyway, I try the compiled SampleDisplay.sys to install on my Win8 system.

System with video adapter:
intel(r) q45/q43 express chipset(Microsoft corporation - wddm1.1)
Win8 pro build 9200

Automatically update driver could not bring this driver from wddm1.1 to 1.2.

from the description of the sample:
If the current display driver is not a WDDM 1.2 compliant driver, the sample driver might fail to install, with error code 43 displayed. The KMDOD driver is actually installed, but it cannot be started. The workaround for this issue is to switch to the Microsoft Basic Display Adapter Driver before installing the KMDOD sample driver, or simply to reboot your system after installing the KMDOD sample.

the result of installing this sample, is always code 43.
No matter the previous driver video adapter used is WDDM1.1 or Microsoft Basic Display Adapter Driver.
And no matter reboot or not.

ANY ONE have come cross this issue before?
And I read the MSND, wddm architecture need user and kernel mode driver, here this sample only have kernel mode miniport driver, how does this driver work without user mode driver?

The Q45 chipset is about a 2008 era chipset, for the Core 2 Duo processors, which was back when the graphics were in the chipset and not the processor. I could easily imagine there are no WDDM 1.2 drivers available for that old a graphics chip. You might dig around the Intel website and see if there is a definitive answer.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of workingmailing@163.com
Sent: Friday, May 30, 2014 9:07 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Modify KMDOD sample for USB display

Anyway, I try the compiled SampleDisplay.sys to install on my Win8 system.

System with video adapter:
intel(r) q45/q43 express chipset(Microsoft corporation - wddm1.1)
Win8 pro build 9200

Automatically update driver could not bring this driver from wddm1.1 to 1.2.

from the description of the sample:
If the current display driver is not a WDDM 1.2 compliant driver, the sample driver might fail to install, with error code 43 displayed. The KMDOD driver is actually installed, but it cannot be started. The workaround for this issue is to switch to the Microsoft Basic Display Adapter Driver before installing the KMDOD sample driver, or simply to reboot your system after installing the KMDOD sample.

the result of installing this sample, is always code 43.
No matter the previous driver video adapter used is WDDM1.1 or Microsoft Basic Display Adapter Driver.
And no matter reboot or not.

ANY ONE have come cross this issue before?
And I read the MSND, wddm architecture need user and kernel mode driver, here this sample only have kernel mode miniport driver, how does this driver work without user mode driver?


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Another question:

frame buffer is located in system memory, not graphic memory?
so in normal case, desktop data is fetch from system memory to graphic memory, then display take place by adapter?

in this sample, who is responsible for fill the frame buffer?

  1. KMDOD sample is a DOD (Display Only Driver) driver.
  2. DOD driver is a WDDM driver.
  3. WDDM drivers need REAL graphics adapter hardware
    (graphics adapter of a virtual machine counts as REAL).

MS presentation at the first /build conference stated:
=> WDDM restriction above also applies to DOD

If this is still true (I never ever re-checked again,
but I strongly assume it still is), then the answer
to the initial question above:

NO - this driver can NOT be modified to render to a USB device.
This driver is designed to operate only when installed on top of
a real graphics adapter hardware (e.g. on the PCI bus with hardware
resources).

Assumption only: The reason for the start failure described above is the
attempt to install it as a virtual display without REAL graphics
adapter hardware.

PS: If the above limitation didn’t exist, then DOD would be a great model
for development of virtual displays including low performance
non-accelerated USB displays. Real USB displays (e.g. DisplayLink)
all use hardware acceleration via WDDM hook drivers.

Marcel Ruedinger
datronicsoft

workingmailing@163.com wrote:

Another question:

frame buffer is located in system memory, not graphic memory?

For the KMDOD driver, yes.

Look, you are making exactly the mistake I warned about earlier in the
thread. You are assuming there is one master copy of a desktop image
somewhere in some graphics memory somewhere, and that all of your
monitors magically pull their displays from that master desktop image.
That is simply not the case.

If you have 4 monitors, you might have 4 different graphics adapters.
Each of those graphics adapters has its own frame buffer, separate from
all the rest. That frame buffer contains an image of ITS SECTION of the
desktop.

When a graphics command comes in, the system looks at the command to see
which of the graphics drivers will be affected by that command. Most
windows only live on one monitor, but you can certainly have one window
span multiple monitors. The system then sends that graphics command
down to EACH of the drivers that will be affected.

If you have two monitors that are echoing each other, then you have TWO
SEPARATE FRAME BUFFERS, each with an independent copy of the desktop.
Every drawing command gets done twice.

Your KMDOD driver gets put into that list as well. If your KMDOD driver
is echoing the entire desktop, then every drawing command that goes to
one of the real graphics adapters will also be sent to your driver.
Your driver is then responsible to do that drawing in its own copy of
the frame buffer, and then send it to wherever the result needs to go.
You aren’t “borrowing” someone else’s frame buffer. You have your very
own frame buffer, that YOU are maintaining (with the help of the
kernel). The images you send to your hardware come from your own
private frame buffer.

so in normal case, desktop data is fetch from system memory to graphic memory, then display take place by adapter?

I can’t tell what you are asking. In the normal case, with one graphics
adapter and one monitor, the drawing commands get send to the graphics
chip, which makes changes in its own frame buffer.

in this sample, who is responsible for fill the frame buffer?

KMDOD. That’s exactly what a “display driver” does.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Careful! Correction:

If you have two (or more) monitors that are echoing each other,
then WDDM uses only one and the same frame buffer(*) for both (all)!
DirectX drawing commands (initiated by Desktop Window Manager)
are executed one time only.

You also might want to recall the related fact that WDDM
cannot mirror across heterogeneous graphics adapters…

(*) To be precise: WDDM does not use the term “frame buffer”.
That’s why I would translate it to WDDM as
“Allocation associated with Video Present Source”.

Marcel Ruedinger
datronicsoft

Hi, Tim,
I get your opinions.
It means that for each graphic adapter on the PC, they got the drawing command, and then drawing on their own frame buffer.
You mean KMDOD is responsilbe for drawing, but the speed could be low, because it use CPU to draw instead of other adapter’s GPU.
And I can not find any command received in KMDOD sample for drawing in my own frame buffer.

Hi, Marcel,

Assumption only: The reason for the start failure described above is the
attempt to install it as a virtual display without REAL graphics
adapter hardware.

PS: If the above limitation didn’t exist, then DOD would be a great model
for development of virtual displays including low performance
non-accelerated USB displays. Real USB displays (e.g. DisplayLink)
all use hardware acceleration via WDDM hook drivers.

  1. So it seems that PCI device have resource, such as DMA, INTERRUPT, MMIO register, and especially its frame buffer
    But USB device does not, and this is the reason that KMDOD sample could not be modified to used for USB display?

Do you think, if it is not a PCI based but USB video adapter, the following function call will failed?
For the reason of there’s no POST device for this USB adapter, especially no frame buffer?
And I not very clear about what is a POST device?
DxgkCbAcquirePostDisplayOwnership

  1. where can i find the WDDM hook driver sample?

  2. Does this hook driver is used to fetch frame buffer content from other video adapter, and then transfer to USB device?

  3. Can do any “cheating” to WDDM system, that USB device have it resource, then load the KMDOD driver?

  1. Yes, true. What is post device? UEFI GOP protocol based BIOS display driver in Windows pre-boot environment handing over the frame buffer to WDDM driver. WDDM drivers can work without this as long as they have hardware resources as discussed above.

  2. No sample. We developed such a driver. Between 35,000 and 50.000 lines of extremely difficult source code. Engineering time 10 man years.

  3. It fakes additional monitor on other graphics adapters and then transfers the content of the shared (mirror) or additional (extend) frame buffer to USB. This is quite tricky and needs different approaches for different graphics adapters. Lots of reverse engineering necessary.

  4. Yes, there are various approaches. One of them is creating a separate virtual device and fake hardware resources for it (not fake hardware resources on USB device). I know two companies who do this by writing a bus driver or a bus filter driver faking hardware resources (*). Careful, this approach is a hack! Resource arbiter interface for WDM bus drivers is not documented and not available to driver developers on purpose.

(*) Both companies virtual WDDM drivers have virtually no market share due to lack of quality, features and performance.

Marcel Ruedinger
datronicsoft.

Thank you, it seems that you are work for DisplayLink.

BTW, I have another question, cause WDDM framework need user mode and kernel mode driver.
Here the KMDOD sample is a KMD, should I also need to develop a user mode driver, or can use the existing user mode driver in system, but if it is the later case, which user mode driver it could be used?

I think both you and the other two companies is take win7, Win8, and Win8.1 all OS into account.
Cause KMDOD only support Win8 WDDM1.2.

But I have a think:
If replace KMDOD with FULL KMD, then it is support for all os above.

in this case, use the full kmd miniport driver to install on a USB device(by some cheating to os), this could be for USB display, and could lower the workload bus/bus filter driver.

workingmailing@163.com wrote:

I think both you and the other two companies is take win7, Win8, and Win8.1 all OS into account.
Cause KMDOD only support Win8 WDDM1.2.

But I have a think:
If replace KMDOD with FULL KMD, then it is support for all os above.

Correct. Do not underestimate that task. It only took you once
sentence to say it, but it would take you a very long time to do it.

in this case, use the full kmd miniport driver to install on a USB device(by some cheating to os), this could be for USB display, and could lower the workload bus/bus filter driver.

The first part is true. I don’t know what you mean by “lower the
workload bus/bus filter driver.” You’ll still be sending the same bits
across the wire. You’re simply letting the GPU draw them into graphics
memory, instead of allowing Microsoft’s software renderer to draw them
into system memory. You then have the task to figure out how to let the
boot display driver in to the club.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

As you known, Windows have native USB VIDEO CLASS driver.

Now USB-IF release the USB AV class spec, especially for USB display.
Displaylink is also the member of this spec contributor.

Can you, the experts, give a calculation of the time, money, on the USB AV class driver development?

Or any company, software design house who could supplied this USB AV class driver service?

I don’t know any details of this USB display class spec, nor DisplayLink’s involvement. In your previous thread here, Microsoft confirmed that Windows does not support this class. Thus developing such a class driver will not help you to use your USB to HDMI gadget for TV screens as a Windows display.

You only have three options:

  1. WDDM DOD - you can possibly do alone. But only Windows 8.1 and above.
  2. WDDM Hook driver as described above.
  3. WDDM virtual graphics adapter driver. Same effort: ~10 man years.

All USB display manufacturers use 2.
I have implemented both 2+3.

List rules say: Do not use the lists to advertise your product or service!
Thus I cannot answer your question about software design house
who could supply WDDM drivers and services.

PS: I never worked for DisplayLink.

Marcel Ruedinger
datronicsoft

thank you very much Marcel.

Here I can’t capture you at:
Microsoft confirmed that Windows does not support this class. Thus developing such a class driver will not help you to use your USB to HDMI gadget for TV screens as a Windows display.

MS have USBVideo.sys for webcam USB device, it is a AVStream/BDA architectured USB device driver.
USBVideo.sys is not design for USB AV class, especially/such as USB display.
In this case, before Microsoft support USB AV class in it native (will or will not, also who knowns).
In this stage, we need to develop a USB AV class driver for USB to HDMI device.

Another is, KMDOD need user mode driver to develop or not?

Marcel Ruedinger wrote:

  1. WDDM Hook driver as described above.
  2. WDDM virtual graphics adapter driver. Same
    effort: ~10 man years.

You said your driver was 50,000 lines of code. Why would that take ten man years to develop?

workingmailing@163.com wrote:

As you known, Windows have native USB VIDEO CLASS driver.

Now USB-IF release the USB AV class spec, especially for USB display.
Displaylink is also the member of this spec contributor.

Can you, the experts, give a calculation of the time, money, on the USB AV class driver development?

Or any company, software design house who could supplied this USB AV class driver service?

Supporting USB AV class is not the hard part. It is largely a
combination of USB Video Class and USB Audio Class. The hard part is
the WDDM part. Frankly, I doubt we’ll ever see that from Microsoft.

It’s worth pointing out that Windows 8 now includes the “Desktop
Duplication API”, in which user-mode applications now have a supported
mechanism for getting a surface that contains an image of the entire
desktop. It’s possible that a lot of the magic that has been done in
the past in this area can now be done through this API.

http://msdn.microsoft.com/en-us/library/windows/desktop/hh404487.aspx


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

If you look at typical developer productivity, something like 5,000-10,000 lines of debugged tested system level code per developer man-year is about right. I know there are periods when my productivity is way higher than that, but I have informally kept track of how many lines of code I and the teams I’m on produced per year and have come to the conclusion those numbers are realistic. Even though a developer may crank our 1000 lines of new code one day, he may also then spend the next 3 days testing it, and a day in meetings, and a few days reading newsgroup messages. Don’t forget there are the bugs you spend 2 weeks on, and don’t find a fix for, so you get zero lines of code done for that 2 weeks. The average vs short burst productivity is often vastly different.

There are a number of papers on the Internet that look at developer productivity. I remember one analysis about a Cisco switch OS, and an analysis about Linux kernel development seems like good comparable projects for driver development.

I see the paper at http://www.sjm06.com/SJM%20ISSN1452-4864/7_1_2012_May_1_170/7_1_65-75.pdf has a bunch of references to development productivity.

Estimating 5-10 man-years for a production quality complex kernel driver that’s 50K lines of code is not unrealistic. If you translate this to dollars, one rule of thumb is $250K per developer man-year (salary/overhead/equipment/office space), so that could be a $2+ million project.

It’s possible in the OPs case, management had not planned on driver development costing $2 million (5 developers for 2 years), yet that’s what it may take to be competitive.

The interesting things about code development productivity is it tends to stay the same number of lines of code across different languages, which is why you get more functionally in a certain time in say C# than C. There are metrics about how “dense” different languages are, like C++ I believe is around twice the functional density as C.

For a while I’ve made rough estimates on project size by estimating how many lines of code I thought it would be, and then assuming 7K-10K lines per developer man-year (use an environment adjustment factor). The tricky part is finding some valid comparable project to estimate the lines of code, although you can often find things like open source or other sample projects that you decide are “similar” complexity, and you can easily measure their lines of code. Estimating also gets a lot harder when you have some existing code. I know of one project where it was like a man-year just to get the existing header files to compile. I sometimes make an estimate of new code plus modifying existing code, applying some adjustment factor (like 0.5) to the existing code. You can work with the existing code for a while and measure your progress to tune the adjustment factor. Adjustment factors can also be > 1.0, when it takes longer to modify existing code than it would take to write it from scratch. If you have to make existing code work on a new platform, without breaking it on another platform, adjustment factors > 1.0 happen.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, June 4, 2014 7:56 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Modify KMDOD sample for USB display

Marcel Ruedinger wrote:

  1. WDDM Hook driver as described above.
  2. WDDM virtual graphics adapter driver. Same
    effort: ~10 man years.

You said your driver was 50,000 lines of code. Why would that take ten man years to develop?

The KM DOD works with the in-box (win8+) usermode “warp” driver. You only
need your own usermode driver for win7. Oh, and the sample can be readily
down-leveled to win7 support.

Mark Roddy

On Tue, Jun 3, 2014 at 9:08 AM, wrote:

> Thank you, it seems that you are work for DisplayLink.
>
> BTW, I have another question, cause WDDM framework need user mode and
> kernel mode driver.
> Here the KMDOD sample is a KMD, should I also need to develop a user mode
> driver, or can use the existing user mode driver in system, but if it is
> the later case, which user mode driver it could be used?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

@Chris

Code metrics and their relevance to driver development actually are one of our favorite topics for late night engineering discussions here. This subject has already accelerated the consumption of countless mugs of Bavarian beer and glasses of French red wine (even a few Californian Pinot Noirs recently)…
Yet, the result is only theoretic - no proven answer!
I guess that’s the nature of code metrics anyway…
This applies even more to the simplest one of all:
“Lines of code per day”.

Just two tiny thoughts about this question (keeping things short and readable):

Paragraph One - Borderline range of the simple metrics:

  1. Window drivers average “Lines of code per day”:
    Our simplest rule of thumb for development of average simplest WDM or miniport drivers is 10.000 lines of code and 6 weeks core development time (average after almost two decades of Windows driver development experience).
    => Window drivers average “Lines of code per day”: ~300
    (very high value, probably because most of the code is copied from samples).

  2. Critical high quality embedded systems code:
    From our defense, aviation, medical and automotive embedded customers developing critical code (typically non-Windows embedded), we heard numbers ranging as low as
    => “Lines of code per day”: ~4

Obviously, our WDDM code is much closer to critical highest quality embedded systems code than to average driver code. This is boiling down to ~20 “Lines of code per day”. I can confirm that every single one of these lines is covered with blood sweat and tears.

Paragraph Two - WDDM specific:

After the first one and a half years, we only had a stable Windows 7 Non Aero implementation with sufficient performance. What takes so long? Example: Faking video memory seems simple at first. When supporting multiple monitors, it needs more contiguous memory than regular PCs have. If video memory is “CPU visible”, then DirectX Kernel allocates it as contiguous memory which is completely useless due to wrong caching attributes (write combined). For multiple monitors, it allocates too much of it so it will not get any (not even upon early boot). Actually a bizarre situation: Useless and unavailable memory prevents DirectX kernel from operating and you cannot prevent DirectX kernel from allocating and probing it. If you make the memory “Non-CPU visible”, then the same problem has a different name: “Swizzling Range”. Dead end for every regular driver developer. Massive loss of time for anyone who is able to create a workaround…

…I promised to keep it short…

…finally after 10 man years of development, the performance reaches 26-28FPS on 1080p video playback (Windows 7 AERO, Windows 8 and 8.1). Happy customers use it worldwide BUT unfortunately, this is the absolute limit. There is no way to ever get it any faster than that! Need a completely different solution for 1080p at 60FPS: Full WDDM Filter Hook Driver

If you are interested in more details about our favorite late night engineering discussion topics “Code Metrics” or “WDDM Pitfalls”, feel invited, but don’t forget to bring a solid supply of French red wine (1997 Chateau Cheval Blanc is my favorite one).

@Jan. Interesting contribution! You would be invited without need to bring any substances :wink:

Marcel Ruedinger
datronicsoft