KMDOD driver on Non UEFI Graphics adapter

Alfred_Henry · February 26, 2015, 7:08am

We are trying to install KMDOD Driver provided with WDK 8.1 samples https://code.msdn.microsoft.com/windowshardware/Kernel-mode-display-only-49adea58 on a Non-UEFI Graphics adapter. Please share your comments on the following queries…

a. As per the below link, KMDOD driver can be installed only on UEFI compatible graphics card (or VESA). But our graphics card does not support UEFI. So Is it possible to modify the KMDOD driver such that it can be installed on an non-UEFI graphics adapter. If so what kind of functionality should be added to KMDOD driver?

b.As per our understanding , KMDOD driver have access to the physical device?s frame buffer through UEFI support only. Is it correct?

Marcel_Ruedinger · February 26, 2015, 9:54am

a: Yes, it can be modified to support non-UEFI frame buffers. Present implementation needs to transfer screen content to own frame buffer (instead of UEFI frame buffer).

b: This is the sample implementation only. I assume, it was chosen to make it usable with a wide range of graphics adapters. It can be modified as described above.

PS: The quoted link actually says “The sample can be installed on top of … UEFI …”. The word “only” does not occur in the original.

Marcel Ruedinger
datronicsoft

Alfred_Henry · February 27, 2015, 12:02am

Thanks Marcel for your quick reply

a. From our understanding, KMDOD sample driver code reads the graphics card information like Physical address, Resolution and other details using m_DxgkInterface.DxgkCbAcquirePostDisplayOwnership() function.

We assume that for porting this sample on a Non-UEFI device, need to implement some mechanism for reading graphics card device information from adapter via PCI configuration registers. No other changes expected in the provided KMDOD sample code .Is our assumption correct?

b. Our understanding is that the function Rtlcopymemory() is used to copy source images to video memory(Frame buffer). We assume this operation doesn?t require UEFI support for copying to Frame buffer. Please confirm.

Marcel_Ruedinger · February 27, 2015, 5:37am

DxgkCbAcquirePostDisplayOwnership(…) is only needed for clean handover from previous driver (e.g. UEFI GOP). KMDOD sample can easily be modified to work without invoking this function.

Physical address (e.g. PCI BARs) can be obtained by DxgkCbGetDeviceInformation(…).

Resolution and many other details are exposed by VidPn implementation (Video Present Network). This includes DxgkDdiIsSupportedVidPn(…), DxgkDdiEnumVidPnCofuncModality(…) and many more…

RtlCopyMemory(…) can be used in DOD to copy images to frame buffer. However, copying frame buffer content to mapped PCI on-board memory can be very slow. Better use DMA hardware to do this…

Marcel Ruedinger
datronicsoft

Alfred_Henry · March 3, 2015, 7:10am

Thanks Marcel for your valuable information.

We tried to modify KMDOD for Non UEFI adapter as per your comments. Our system is Windows 8 machine running on UEFI BIOS. We have a primary display adapter running on WDDM 1.2 driver. Our major tryouts are mentioned below.

On KMDOD sample driver running on UEFI compliance graphics adapter, we put a print statement to view the values of DXGK_DISPLAY_INFORMATION structure. To the same driver, we commented the DxgkCbAcquirePostDisplayOwnership(…) function and read the graphic card memory information using DxgkCbGetDeviceInformation(…) function. Video card memory address obtained is 0xE0000000.
DXGK_DISPLAY_INFORMATION structure elements are hardcoded as below (taking the values from the print obtained earlier):

m_CurrentModes[0].DispInfo.Width = 1440
m_CurrentModes[0].DispInfo.Height = 900
m_CurrentModes[0].DispInfo.Pitch = 0x2000
m_CurrentModes[0].DispInfo.PhysicAddress.LowPart = 0xE0000000
m_CurrentModes[0].DispInfo.PhysicAddress.HighPart = 0
m_CurrentModes[0].DispInfo.ColorFormat = D3DDDIFMT_X8R8G8B8
m_CurrentModes[0].DispInfo.TargetId = 0xffffffff
m_CurrentModes[0].DispInfo.AcpiId = 0

No other changes done on KMDOD code.
This KMDOD sample work fine on the UEFI compliance graphics adapter

We try out the same experiments by connecting a Non UEFI compliance graphics card. The video card memory address obtained via DxgkCbGetDeviceInformation() is 0xE0000000. Hardcoded all these values on DXGK_DISPLAY_INFORMATION structure. No other changes done in KMDOD. Our debug log says the code flow in both the UEFI and Non UEFI cases are the same. We also noticed copying source images to frame buffer memory functionality working. But no display is obtained for non UEFI. We could not find any error code paths in any other code flow paths.

Do you think is there any other dependencies related to UEFI on making KMDOD sample working over a non-UEFI adapter? Please share your thoughts?

Thanks,
Alfred

Marcel_Ruedinger · March 3, 2015, 3:10pm

Way too many degrees of freedom for remote consulting in a newsgroup. I can only make a very simple blind guess:

UEFI GOP driver did all the graphics adapter hardware initialization and configuration work. The DOD driver probably received the graphics adapter hardware in an initialized, configured and working state.
DOD driver probably received the graphics adapter hardware in an uninitialized state.
It is the DOD driver’s task to set up its hardware (e.g. during VidPn implementation as mentioned above). Does “No other changes done in KMDOD” mean “No hardware initialization and configuration code added for the non-UEFI adapter”? That could make up a solid reason why nothing shows on the screen…

PS: In addition to this, I could imagine many other reasons ranging from simple bits in DXGK_DRIVERCAPS to large issues (e.g. need of an interrupt implementation for the non-UEFI adapter).

Marcel Ruedinger
datronicsoft