Graphic miniport question in Windows 7

Hi,

When a miniport indicates that child status has changed and I know that this child is a monitor, how can I figure out the relationship between ChildUid and VidPnSrcId ?
Given that I have the DeviceHandle and MiniportDeviceContext.

Thanks,
Anatoly.

PS: I could be wrong with terminology, so please correct me where needed.

Hi Anatoly,
Are you doing this from actual graphics driver or from some sort of wrapper that intercept these calls?
In any case there is no direct way to query the current topology(from DxgKrnl) in kernel mode and figure out the source to which this ChildUid belongs. You would need to save the topology info from vidpn supplied in CommitVidpn and compare the ChildUid’s in the topology to find the source for each.

Thanks,
Dhiren

Hi, thanks.

It’s a wrapper.

I need to know if a monitor is connected to specific vidpnsource.
Are you saying it is not possible before commitvidpn is called?

Thank You,
Anatoly.

Hi Anatoly,

I am guessing that you are intercepting DxgkCbIndicateChildStatus call to know if a monitor got connected or disconnected.

So there are 2 cases here.

  1. Monitor got connected. Then it means monitor is not part of current topology. It might get enabled and attached to a source based on profile information. In this case you wont know untill next commitVidpn call comes in, which would attach this monitor to some source.

  2. Monitor got disconnected. Then you need to have the information saved about current topology to find out if this monitor was attached to some source.

And information about current topology can only be known during CommitVidpn. So in each commitVidpn call you need to save the information about current topology( vidpn source ID to ChildUid mapping). And use this information in DxgkCbIndicateChildStatus callback to know the source id to which this ChildUid belonged.
So the seq has to be follows.

  1. CommitVidpn ( VidPnSourceID 0 Attached to ChildUid 0x100 ) - You would need to intercept this call as well and save this information( fetched via VidPn and Topology Interface) in your driver.
  2. DxgkCbInidicateChildStatus Callback. Use the above saved topology information to find the ChildUid to VidPnSourceId mapping.

If you dont find the ChildUid in Topology it means it has not been enabled yet and it might get enabled in next CommitVidPn call.
Hope this info makes sense.

Thanks,
Dhiren.

Hi Dhiren,

There are no status calls if the monitor is already connected. I just need to know if there is a coonection to vidpnsrc, not neccesarily which target is connected.
Do you know what D3DKMTGetDisplayModeList returns for VidPnSrc that does not have a monitor connected? Do you know if D3DKMTGetDisplayModeList eventually calls the miniport or retrieves info cached in “vidpn manager”? What if I call it before any vidpn is committed.

What do you think?

Thanks,
Anatoly.

Hi Anatoly,

D3DKMTGetDisplayModeList would return your global adapter mode list( and not the monitor specific mode list) if its called for VidPn source which is not attached to any target.
If would be helpful to know ‘where’ do you need this information. Is it in kernel mode or user mode? D3DKMTGetDisplayModeList api is a OGL function. So far i was trying to answer your question asusming that you have some sort of interceptor over actual kernel mode Graphics driver.

And in case your entire setup is on some form of usermode OGL driver you can call CCD interface “QueryDisplayConfig” to know vidPnsource to target connections i.e. the path information.

Can you elaborate a bit more on how do you get to know the child status has changed?

Thanks,
Dhiren

Hello Dhiren,

Regarding the child status, either the dxgkrnl calls DxgkDdiQueryChildStatus or the minitport calls DxgkCbIndicateChildStatus. Eventually dxgkrnl calls DxgkDdiCommitVidPn.
The information is needed in kernel, but I also have a service that helps to cover user-mode interfaces.

Thanks again for the input.
Anatoly.