Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Modify KMDOD sample for USB display

wesleywesley Member Posts: 344
Kernel mode display-only miniport driver (KMDOD) sample

The sample is from Microsoft MSDN
http://code.msdn.microsoft.com/Kernel-mode-display-only-49adea58


Take a look of this sample code,
I found the start, stop, and workthread item.

My question are:
1. Can this driver be modified to render to USB device?
1. How large work need to be done to render the content of the desktop to the USB device.
2. My consideration is add USB read and handle parer function in Start, save the pipe handle then in the workthread to transfer the data to USB device, does it right?
«13

Comments

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,575
    KMDOD is rendering to a frame buffer, so you will have to modify that
    process to copy rectangles to your usb device. That should be do-able. I
    have no idea about other issues, such as is this the only display device on
    the platform?

    Mark Roddy


    On Thu, May 29, 2014 at 1:31 AM, wrote:

    > Kernel mode display-only miniport driver (KMDOD) sample
    >
    > The sample is from Microsoft MSDN
    > http://code.msdn.microsoft.com/Kernel-mode-display-only-49adea58
    >
    >
    > Take a look of this sample code,
    > I found the start, stop, and workthread item.
    >
    > My question are:
    > 1. Can this driver be modified to render to USB device?
    > 1. How large work need to be done to render the content of the desktop to
    > the USB device.
    > 2. My consideration is add USB read and handle parer function in Start,
    > save the pipe handle then in the workthread to transfer the data to USB
    > device, does it right?
    >
    > ---
    > 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
    >
  • wesleywesley Member Posts: 344
    Mark,

    So here copy is use CPU to do the copy?
    COPY from display memory to system memory and then transfer by USB to USB device?

    the case is PC with its own video adapter card, and connect with a monitor.
    USB to HDMI gadget is used to connect to 2nd, or 3rd TV or monitors with HDMI interface.
  • wesleywesley Member Posts: 344
    Another question

    does this driver could be used for a display adapter?

    Or any other user-mode driver needed?

    The sample description does not give very detail information about how to use this driver?
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,575
    The sample can absolutely be used for a hardware adapter. I adapted it for
    use on our xen based virtualization product for Win8, where it works with
    our virtual hardware and then we re-worked it to run on win7 with our own
    user mode renderer instead of warp. It is bare bones wddm functionality,
    but it is at least a complete and functional sample.

    Mark Roddy


    On Fri, May 30, 2014 at 5:50 AM, wrote:

    > Another question
    >
    > does this driver could be used for a display adapter?
    >
    > Or any other user-mode driver needed?
    >
    > The sample description does not give very detail information about how to
    > use this 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
    >
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,406
    [email protected] wrote:
    > So here copy is use CPU to do the copy?
    > COPY from display memory to system memory and then transfer by USB to USB device?

    There's no display memory involved. Your driver does not have access to
    the graphics memory of any other driver. Each driver maintains its own
    copy of whatever portion of the desktop it is showing. So, you will
    simply transfer from the system memory frame buffer that your driver is
    maintaining.

    Too many people think about their computers as having one desktop on one
    monitor driven by one graphics card. That model is simply incorrect. I
    can have 4 monitors driven from 4 different frame buffers written by 4
    different graphics chips. If your device is showing the whole desktop,
    I hope it is clear you cannot just "copy from display memory".


    > the case is PC with its own video adapter card, and connect with a monitor.
    > USB to HDMI gadget is used to connect to 2nd, or 3rd TV or monitors with HDMI interface.

    But, see, there is no "USB to HDMI gadget" class. That's why I asked.
    What kind of a device is it? Is it a device that already exists, or are
    you building one from scratch?

    --
    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • wesleywesley Member Posts: 344
    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?
  • wesleywesley Member Posts: 344
    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?
  • Jan_BottorffJan_Bottorff Member - All Emails Posts: 472
    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: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
    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
  • wesleywesley Member Posts: 344
    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?
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 176
    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
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,406
    [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 176
    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
  • wesleywesley Member Posts: 344
    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

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

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

    4. Can do any "cheating" to WDDM system, that USB device have it resource, then load the KMDOD driver?
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 176
    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.
  • wesleywesley Member Posts: 344
    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?
  • wesleywesley Member Posts: 344
    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.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,406
    [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • wesleywesley Member Posts: 344
    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?
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 176
    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
  • wesleywesley Member Posts: 344
    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?
  • Chris_AseltineChris_Aseltine Member Posts: 1,228
    Marcel Ruedinger wrote:

    > 2. WDDM Hook driver as described above.
    > 3. 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?
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,406
    [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Jan_BottorffJan_Bottorff Member - All Emails Posts: 472
    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 ISSN1452-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: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
    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:

    > 2. WDDM Hook driver as described above.
    > 3. 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?
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,575
    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
    >
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 176
    @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 ;-)

    Marcel Ruedinger
    datronicsoft
  • wesleywesley Member Posts: 344
    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.

    Hi, Mark

    Here your "down-leveled" is change the KMDOD sample to full graphic mode on Win7, casue Win7 WDDM1.1 could not support KMDOD?
    So if we change the KMDOD to full graphic mode driver, in Win7 we can also use the wrap usermode too?

    Thank you.
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 176
    Let me add only a few more questions...

    Down leveled? Still a DOD or a full WDDM?

    Calling DxgkInitializeDisplayOnlyDriver?
    - Never heard that this could be possible on Win7.
    - If yes, would it coexist with WDDM 1.0 and WDDM 1.1
    main graphics adapter drivers?

    Or calling DxgkInitialize?
    - How did you fake Video Memory (see my example above)?
    - Or did you "just have" the video memory because installed
    on top of some virtual machine graphics adapter hardware?

    How could such a "down leveled" driver support Windows 7 Non-Aero scenarios?
    Windows 7 Non-Aero scenarios don't rely on D3D nor WDDM User Mode Drivers
    (thus WARP does not help). DOD sample does not contain any code for Windows 7
    Non-Aero scenarios.

    How did you implement the WDDM User Mode driver code?
    Reverse translating DX10 DDI to DX10 API redirecting to Warp?
    If yes, then can you also redirect to D3D9?
    Can you also support video playback by DXVA which needs DX9 User Mode Driver?
    Does it also work in scenarios with WDDM 1.0 DX9ex main graphics adapter?

    These are only the minimum questions necessary to understand what this "down level" post is talking about. Actually, I have about 100 more such questions. Just not asking because I don't want to appear rude or ask for too much.

    Marcel Ruedinger
    datronicsoft
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,575
    No you have to have your own usermode driver, and that is a huge pile of
    work. There is no way I know of to get warp running on win7.

    Mark Roddy


    On Wed, Jun 4, 2014 at 10:00 PM, wrote:

    > 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.
    >
    > Hi, Mark
    >
    > Here your "down-leveled" is change the KMDOD sample to full graphic mode
    > on Win7, casue Win7 WDDM1.1 could not support KMDOD?
    > So if we change the KMDOD to full graphic mode driver, in Win7 we can also
    > use the wrap usermode too?
    >
    > Thank you.
    >
    >
    > ---
    > 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
    >
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,575
    The KMDOD sample can be readily modified to be a full WDDM 1.1 kernel mode
    driver, but you have to have your own usermode display driver and obviously
    no you cannot call DxgkInitializeDisplayOnlyDriver. Our usermode driver
    does DX9 and fully supports aero and non-aero modes. From our driver's
    perspective "aero" is using flips and double buffering, "non-aero" is
    single buffered. In both cases we have our own mechanism for getting
    rectangles to the actual graphics adapter, this is a VM environment, we
    just tell the user mode driver where to render and it tells us when to flip.

    I have no idea about cohabitation with other wddm drivers as that isn't an
    issue for us.

    I didn't implement the user mode driver, I implemented our win8 KMDOD,
    enhanced from the sample to be a lot more functional and to support our
    hyper-visor, and did the initial work to move that back to win7 with a
    non-warp user mode driver.

    If you want to look at how other people are doing similar things, vbox has
    an open source win7 WDDM driver, however their usermode driver is
    translating DXn to OGL.



    Mark Roddy


    On Wed, Jun 4, 2014 at 11:43 PM, wrote:

    > Let me add only a few more questions...
    >
    > Down leveled? Still a DOD or a full WDDM?
    >
    > Calling DxgkInitializeDisplayOnlyDriver?
    > - Never heard that this could be possible on Win7.
    > - If yes, would it coexist with WDDM 1.0 and WDDM 1.1
    > main graphics adapter drivers?
    >
    > Or calling DxgkInitialize?
    > - How did you fake Video Memory (see my example above)?
    > - Or did you "just have" the video memory because installed
    > on top of some virtual machine graphics adapter hardware?
    >
    > How could such a "down leveled" driver support Windows 7 Non-Aero
    > scenarios?
    > Windows 7 Non-Aero scenarios don't rely on D3D nor WDDM User Mode Drivers
    > (thus WARP does not help). DOD sample does not contain any code for
    > Windows 7
    > Non-Aero scenarios.
    >
    > How did you implement the WDDM User Mode driver code?
    > Reverse translating DX10 DDI to DX10 API redirecting to Warp?
    > If yes, then can you also redirect to D3D9?
    > Can you also support video playback by DXVA which needs DX9 User Mode
    > Driver?
    > Does it also work in scenarios with WDDM 1.0 DX9ex main graphics adapter?
    >
    > These are only the minimum questions necessary to understand what this
    > "down level" post is talking about. Actually, I have about 100 more such
    > questions. Just not asking because I don't want to appear rude or ask for
    > too much.
    >
    > Marcel Ruedinger
    > datronicsoft
    >
    > ---
    > 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
    >
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 176
    Thanks for the comprehensive info and solid base for discussion.
    So "down-leveling" actually means "writing a full WDDM 1.1 DX9 driver
    reusing kernel mode code (mostly VidPn) from DOD sample".

    While obviously feasible in this virtual machine environment, the scenario discussed in this thread (arbitrary consumer PC environment with connected USB display gadget) is very different. There it takes massive resources (again: 10 man years), if possible at all. Let us have a quick look again:

    VM environment has resources which regular consumer PCs don't have:
    ---------------------------------------------------------------------------------------
    1. VM has Video memory, regular PCs don't have (as discussed above).
    2. Your VM environment seems to have a software DX9 renderer, regular PCs don't have. One available DX9 software renderer is swiftshader. It was very expensive when we checked a longer time ago. Does anybody here know any other reasonable and affordable D3D9 software renderer?
    3. Etc.etc.etc.

    Regular consumer PCs have degrees of freedom which VM environment does not have:
    ----------------------------------------------------------------------------------------------------------
    Below, only one example issue about cohabitation with other WDDM drivers.
    In dual adapter environments (e.g. Laptops with Intel/Nvidia dual adapter combinations), NVidia has an own WDDM hook driver nvkflt.sys and nvumdshim.dll. This driver is not well behaved. Upon presence of other WDDM drivers, it always chooses one out of three options:
    1. It crashes Nvidia Control Panel.
    2. It crashes Desktop Window Manager.
    3. It crashes the whole operating system with Blue Screen of Death.
    So even if you manage to write your own compliant WDDM driver (which is already very unlikely), others will still kill you. How can you survive such violence from the tallest and strongest guys? Can you start to imagine how 10 man years can accumulate very quickly?

    PS: Nice hint about DircetX to OpenGL translation in vbox driver. Will have a close look again. Haven't looked much at this driver since we last discussed it here in October 2010.

    Marcel Ruedinger
    datronicsoft
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Writing WDF Drivers TBD 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online