none
KMDOD for two display monitors - Second monitor not getting detected. RRS feed

  • Question

  • Dear all,

    I am trying to experiment with sample KMDOD provided with WDK for Windows 8.

    I have a primary adapter (Intel based) connected to my Windows PC to which my primary monitor is connected.

    I also have a Nvidia Geforce GTX750 (UEFI enabled) connected as my secondary adapter with two display ports - VGA and DVI.

    I have tested the sample KMDOD driver as such with Nvidia. I got it working and my desktop extension feature worked fine without any modification. Now I am trying to customize KMDOD driver for display outputs in Nvidia card for desktop extension support.

    For that, I have updated MAX_CHILDREN to 2 and MAX_VIEWS retained as 1. I hope there will be two video present targets and one video present source. On skimming through KMDOD source code, i found it is designed in an extensible way so that only minimal modification needed to provide support multiple display targets.

    But on testing, i found my second monitor connected to Nvidia adapter is not getting detected.

    I have put debug prints to analyse the issue. I found:

    EnumVidPnCofuncModality() and IsSupportedVidPn() is being called a large number of times and EnumVidPnCofuncModality() is considering VidPnSource ID: 0 and vidPnTargetID:0 and VidPnSourceID:0 and VidPnTargetID:1. But always the number of paths remain as 1 only. For some reason, the second path is not getting added to the topology. From debug prints, I see pinned modes have values..

    The following are my queries:

    1. For customizing for two video targets, does the UEFI GOP only reading the required details from only one monitor connected to secondary adapter. Is that the reason the second one not being detected? Any other hardware initialization required for providing two output support?

    2. How to tell VidPn that there is a second monitor connected to Nvidia adapter and make it working? Do we need to provide EDID for this? KMDOD sample driver not providing EDID..

    3. From my debug prints, i see RecommendMonitorModes() is not being called in the customized KMDOD driver.

    Please share your thoughts on this concern.

    Thanks,

    Dayal

    Monday, March 23, 2015 5:19 AM

Answers

  • This driver sample has an upper edge to operating system software (DirectX kernel graphics) and a lower edge to graphics adapter hardware. To achieve this goal, both have to be implemented in a correct manner.

    Upper edge: Is the monitor connection status reported correctly in QueryChildStatus(...)? The Video Present Network parameter of IsSupported(...) and EnumCofunc(...) usually does not include any path unless there is a monitor connected to the Video Present Target. No EDID needed for minimum working implementation.

    Lower edge: Was there any code added to properly program the NVidia hardware? I would not know any places where to get such code or related NVidia hardware documentation. This is why I doubt that the above mentioned approach can succeed. The only small chance of feasibility which I can see is taking code from NVidia Open Source Linux driver (this is only a wild guess - no time to check details).

    Monday, March 23, 2015 4:45 PM

All replies

  • This driver sample has an upper edge to operating system software (DirectX kernel graphics) and a lower edge to graphics adapter hardware. To achieve this goal, both have to be implemented in a correct manner.

    Upper edge: Is the monitor connection status reported correctly in QueryChildStatus(...)? The Video Present Network parameter of IsSupported(...) and EnumCofunc(...) usually does not include any path unless there is a monitor connected to the Video Present Target. No EDID needed for minimum working implementation.

    Lower edge: Was there any code added to properly program the NVidia hardware? I would not know any places where to get such code or related NVidia hardware documentation. This is why I doubt that the above mentioned approach can succeed. The only small chance of feasibility which I can see is taking code from NVidia Open Source Linux driver (this is only a wild guess - no time to check details).

    Monday, March 23, 2015 4:45 PM
  • Thank you for your suggestions.

    I have checked QueryChildStatus(). Its getting monitor connected status..

    A trivial query from my side. In the KMDOD sample code, source mode sets, monitor mode sets and target mode sets are hard-coded except the width, height values. Even then, it claims to work with UEFI capable adapters. These mode sets do have a hardware dependency, right? So is that the UEFI GOP driver possibly doing rest of the initialization to make the adapter capable to plot. Is my understanding correct?

    If that is the case, after reading per https://msdn.microsoft.com/en-us/library/windows/hardware/dn932836%28v=vs.85%29.aspx, I assume only one of my monitors has been initialized by UEFI GOP during boot time and that is where my pre-OS boot screen is displayed. So I should do rest of the initialization of the hardware manually.

    Can anyone share your viewpoints on this?


    • Edited by dayal2007 Friday, March 27, 2015 10:05 AM
    Friday, March 27, 2015 10:04 AM
  • On the lower edge (hardware), this Display Only Driver supports only one source mode/resolution (e.g. received from UEFI GOP).

    Only on the upper edge (operating system), this driver sample shows more than one mode/resolution.

    How can this work when the lower edge does not support multiple resolutions? This can easily be read from the sourcecode: Upper edge only exposes resolutions smaller than the one supported by the lower edge. If smaller resolution is selected, it only uses the center part of the screen and blacks out the rest.

    For doing anything more on the lower edge (e.g. adding second monitor), see my post above. In this case, probably EVERYTHING needs to be done manually. Probably not reasonable to rely on whatsoever was previously done by UEFI GOP. Handing over frame buffer from UEFI to WDDM driver is for flicker free transition only. Reducing the WDDM driver developer's amount of labor and/or initialization code is NOT the purpose (even though that's exactly what this sample elegantly does).

    Friday, March 27, 2015 10:03 PM