Discussion:
WDDM Driver Vidpn implementation.
(too old to reply)
krish
2009-12-09 09:47:26 UTC
Permalink
Hi,

I am trying to develop a WDDM based display driver or windows 7.I
am unable to know what need to be done in two of the calls namely

DxgkDdiEnumVidPnCofuncModality
DxgkDdiIsSupportedVidPn

I tried to add an initial vidpn topology by implementing the
DxgkDdiRecommendFunctionalVidPn call in the WDDM miniport driver.

But starting from windows 7 i am unable to get the
DxgkDdiRecommendFunctionalVidPn function call from dxgkrnl. After
searching through the MSDN documentation i found out that the function
is deprecated starting from windows 7.

msdn link: http://msdn.microsoft.com/en-us/library/ee220395.aspx

According to msdn

"On a computer running Windows 7, the display mode manager (DMM)
determines an appropriate VidPN topology to apply using VidPN history
data in the CCD database. DMM no longer determines the VidPN topology
based upon the last known good topology as it did in Windows Vista.
Consequently, on Windows 7 DMM never calls the
DxgkDdiRecommendVidPnTopology function."

If so then how to provide initial vidpn topology?
else how to add the vidpn topology in CCD persistent data base from
which the DMM determines the functional vidpn?

Else do we need to handle DxgkDdiEnumVidPnCofuncModality and
DxgkDdiIsSupportedVidPn in a special way?


I am unable to implement these two calls
DxgkDdiEnumVidPnCofuncModality and DxgkDdiIsSupportedVidPn

Please help me in this regard.

Thanks & Regards
Krish.
Ivan Brugiolo [MSFT]
2009-12-10 00:51:40 UTC
Permalink
Why do you want to provide an VidPn initial network ?
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you. This is the comment I added to a prototype
virtual WDDM 1.1 driver I was working on end-of-summer.
Be warned, EnumVidPnCofuncModality can be called a few thousands
times during PnP-start or machine boot.
The driver had 4 present-sources and 5 present-targets,
but only 3 were active. At the end they were showing up as 3 monitors
in desk.cpl.
The call sequence is only for the first path of the topology.
The other paths are not discussed for the sake of simplicity.

NTSTATUS
DxgkDdiEnumVidPnCofuncModality(
__in CONST HANDLE hAdapter,
__in CONST DXGKARG_ENUMVIDPNCOFUNCMODALITY* CONST
pEnumCofuncModalityArg
)
/*++

Routine description:

The Video-Present-Network manager associated with the Miniport
calls this function in order to make function-together `co-functional`
the video-present-modes that were associated with the supplied
video present network.
The supplied topology has some constrains, and those must not be
touched.
The outcome of this function is either some extra pinned mode
in the the mode-set for the sources or targets, or, some adjustment
on specific properties for sources or targets.

The process requires this function to be called multiple times.
A possible call sequence is:

Step 0 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
Source: N/A
Target: N/A

Step 1 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
(1 <-> 4)
Source: N/A
Target: N/A

Step 2 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
(1 <-> 4)
(2 <-> 3)
Source: N/A
Target: N/A

Step 3 - Pivot = D3DKMDT_EPT_VIDPNSOURCE
Paths: (0 <-> 0)
(1 <-> 4)
(2 <-> 3)
Source: (0 => ***@A8R8G8B8)
Target: N/A

Step 4 - Pivot = D3DKMDT_EPT_VIDPNTARGET
Paths: (0 <-> 0)
(1 <-> 4)
(2 <-> 3)
Source: (0 => ***@A8R8G8B8)
Target: (0 => ***@75Hx)

Step 5 - Pivot = D3DKMDT_EPT_SCALING
Paths: (0 <-> 0) (IdentityScaling)
(1 <-> 4)
(2 <-> 3)
Source: (0 => ***@A8R8G8B8)
Target: (0 => ***@75Hz)

Step 6 - Pivot = D3DKMDT_EPT_ROTATION
Paths: (0 <-> 0) (IdentityScaling,UnRotated)
(1 <-> 4)
(2 <-> 3)
Source: (0 => ***@A8R8G8B8)
Target: (0 => ***@75Hz)


Basically, the Video-Present-Network manager adds pieces one-by-one
to the network (because paths are being added), and, for each path,
it keeps adding constrains (for example source modes).

--*/
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Post by krish
Hi,
I am trying to develop a WDDM based display driver or windows 7.I
am unable to know what need to be done in two of the calls namely
DxgkDdiEnumVidPnCofuncModality
DxgkDdiIsSupportedVidPn
I tried to add an initial vidpn topology by implementing the
DxgkDdiRecommendFunctionalVidPn call in the WDDM miniport driver.
But starting from windows 7 i am unable to get the
DxgkDdiRecommendFunctionalVidPn function call from dxgkrnl. After
searching through the MSDN documentation i found out that the function
is deprecated starting from windows 7.
msdn link: http://msdn.microsoft.com/en-us/library/ee220395.aspx
According to msdn
"On a computer running Windows 7, the display mode manager (DMM)
determines an appropriate VidPN topology to apply using VidPN history
data in the CCD database. DMM no longer determines the VidPN topology
based upon the last known good topology as it did in Windows Vista.
Consequently, on Windows 7 DMM never calls the
DxgkDdiRecommendVidPnTopology function."
If so then how to provide initial vidpn topology?
else how to add the vidpn topology in CCD persistent data base from
which the DMM determines the functional vidpn?
Else do we need to handle DxgkDdiEnumVidPnCofuncModality and
DxgkDdiIsSupportedVidPn in a special way?
I am unable to implement these two calls
DxgkDdiEnumVidPnCofuncModality and DxgkDdiIsSupportedVidPn
Please help me in this regard.
Thanks & Regards
Krish.
Tim Roberts
2009-12-10 06:20:00 UTC
Permalink
Post by Ivan Brugiolo [MSFT]
Why do you want to provide an VidPn initial network ?
I'll take a stab at that. Because nowhere in the documentation does it say
whether or not the driver NEEDS to do so. I don't know whether you've
every read the "video present network" documentation from the point of view
of a relative newcomer, but it is as impenetrable as any technical document
I've ever read.
Post by Ivan Brugiolo [MSFT]
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you. This is the comment I added to a prototype
virtual WDDM 1.1 driver I was working on end-of-summer.
Is there any possibility that the source for your driver will be released
to the huddled masses? There are no longer any good WDDM samples, and the
API is rather vast.
--
Tim Roberts, ***@probo.com
Providenza & Boekelheide, Inc.
krish
2009-12-10 09:48:23 UTC
Permalink
Why do you want to provide anVidPninitial network ?
I'll take a stab at that.  Because nowhere in the documentation does it say
whether or not thedriverNEEDS to do so.  I don't know whether you've
every read the "video present network" documentation from the point of view
of a relative newcomer, but it is as impenetrable as any technical document
I've ever read.
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you. This is the comment I added to a prototype
virtualWDDM1.1driverI was working on end-of-summer.
Is there any possibility that the source for yourdriverwill be released
to the huddled masses?  There are no longer any goodWDDMsamples, and the
API is rather vast.
--
Providenza & Boekelheide, Inc.
Hi,

first of all my sincere thanks to Mr.Ivan and Mr.Tim for their
responses.
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you.
Regarding the above do u mean to say we need to provide the no of
video present sources and targets(children) in the start device?

If so yes i had provided them in my start device.

else r u suggesting to provide the source mode sets and target mode
sets? if so where to provide can we do the same in
DxgkDdiEnumVidPnCofuncModality?
This is the comment I added to a prototype
virtualWDDM1.1driverI was working on end-of-summer.
Regarding ur Virtual WDDM 1.1 driver i am pretty interested to know
what u did? if possible can u please share the same? it will be very
helpfull for me to understand the WDDM frame

work.
Thedriverhad 4 present-sources and 5 present-targets,
but only 3 were active. At the end they were showing up as 3 monitors
in desk.cpl.
So u had returned to OS saying that only 3 of the 5 targets were
connected.Hence only 3 monitors were seen in the desk.cpl? Now how did
u control which source will be mapped to which of

the active targets in the vidpn topology?
The Video-Present-Network manager associated with the Miniport
calls this function in order to make function-together `co-functional`
the video-present-modes that were associated with the supplied
video present network.
Here i am able traverse the paths present in the topology and provided
the source modes and target modes in DxgkDdiEnumVidPnCofuncModality?
but as i press extend the desktop to

this display i am getting unable to save Display settings error?

what is the importance of DxgkDdiIsSupportedVidPn ? how it should be
handled?
The supplied topology has some constrains, and those must not be
touched.
As per my understanding after going through MSDN documentation the
constraints are if a source or target is identified as the pivot of
the enumeration, the mode set for that source or

target must not change.

If i am wrong please rectify me? if any additional constraints are
there please explain?
Step 0 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
Source: N/A
Target: N/A
Step 1 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
(1 <-> 4)
Source: N/A
Target: N/A
Step 2 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
(1 <-> 4)
(2 <-> 3)
Source: N/A
Target: N/A
Step 3 - Pivot = D3DKMDT_EPT_VIDPNSOURCE
Paths: (0 <-> 0)
(1 <-> 4)
(2 <-> 3)
Target: N/A
As per ur above mentioned calling sequence each time
DxgkDdiEnumVidPnCofuncModality will be called first with only one
path (0 <-> 0) , second time with two paths (0 <-> 0), (1 <-> 4) and
so on with enum pivot as nopivot , how the OS knows that source id o
is mapped to target id 0 and 1 is mapped to 4?


In between in my analysis i saw DxgkDdiIsSupportedVidPn is called
before calling DxgkDdiEnumVidPnCofuncModality ? what is the need do
we need to return that the constraining vidpn is supported in
DxgkDdiIsSupportedVidPn ?

Alright by now u might have been fed up by my queries ? i will stop
here

please help me i am very much confused with these things and i am
unable to find any help in this regard. It seems only WDK
documentation is the only source of information i found till now which
is not in detail.

Thanks & Regards,
Krish.
Ivan Brugiolo [MSFT]
2009-12-10 21:30:03 UTC
Permalink
Post by krish
Regarding the above do u mean to say we need to provide the no of
video present sources and targets(children) in the start device?
Why would it make any sense ?

You provide sources and targets, and the user/system decide.
If you cannot support connecting a present-source, with (for example)
and S-Video target, just say the VidPn is not supported, or, remove
that path while the Co-Functional Modality is being built.
Post by krish
Regarding ur Virtual WDDM 1.1 driver i am pretty interested to know
what u did? if possible can u please share the same? it will be very
helpfull for me to understand the WDDM frame
Writing a Virtual WDDM driver has several challenges:
- you need a bus driver disguised as a PCI or PCI-ex bus.
- the bus driver need to provide an IoConnectInterruptEx-connectible
resource
- you need to simulate a DPC routine (in order to simulate DMA completion)
Toaster.sys will not be of much help here.
Post by krish
Now how didu control which source will be mapped to which of
the active targets in the vidpn topology?
I did not control that. I was offered a choice by VIDMM, and, I could veto
that
or supply a path while that dimension was still unconstrained.
Post by krish
As per my understanding after going through MSDN documentation the
constraints are if a source or target is identified as the pivot of
the enumeration, the mode set for that source or target must not change.
I think of is differently. The system is building a graph, and it has 6
constraining factors.
It restricts one factor at the time. The un-constrained factors are free for
you to change.
Post by krish
In between in my analysis i saw DxgkDdiIsSupportedVidPn is called
before calling DxgkDdiEnumVidPnCofuncModality ? what is the need do
we need to return that the constraining vidpn is supported in
DxgkDdiIsSupportedVidPn ?
Probably you are confused by the storm of calls you get.
I think it is more useful to think that `IsSupported` is called after
the system has made a decision about one parameter of the graph it is
building.
Post by krish
please help me i am very much confused with these things and i am
unable to find any help in this regard. It seems only WDK
documentation is the only source of information i found till now which
is not in detail.
I think the WDK documentation is reasonable.
You should write a DumpVidPn function (it will be around 300 lines of code,
do not dispair) and watch how it changes.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Post by krish
Post by Tim Roberts
Why do you want to provide anVidPninitial network ?
I'll take a stab at that. Because nowhere in the documentation does it say
whether or not thedriverNEEDS to do so. I don't know whether you've
every read the "video present network" documentation from the point of view
of a relative newcomer, but it is as impenetrable as any technical document
I've ever read.
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you. This is the comment I added to a prototype
virtualWDDM1.1driverI was working on end-of-summer.
Is there any possibility that the source for yourdriverwill be released
to the huddled masses? There are no longer any goodWDDMsamples, and the
API is rather vast.
--
Providenza & Boekelheide, Inc.
Hi,
first of all my sincere thanks to Mr.Ivan and Mr.Tim for their
responses.
Post by Tim Roberts
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you.
Regarding the above do u mean to say we need to provide the no of
video present sources and targets(children) in the start device?
If so yes i had provided them in my start device.
else r u suggesting to provide the source mode sets and target mode
sets? if so where to provide can we do the same in
DxgkDdiEnumVidPnCofuncModality?
Post by Tim Roberts
This is the comment I added to a prototype
virtualWDDM1.1driverI was working on end-of-summer.
Regarding ur Virtual WDDM 1.1 driver i am pretty interested to know
what u did? if possible can u please share the same? it will be very
helpfull for me to understand the WDDM frame
work.
Post by Tim Roberts
Thedriverhad 4 present-sources and 5 present-targets,
but only 3 were active. At the end they were showing up as 3 monitors
in desk.cpl.
So u had returned to OS saying that only 3 of the 5 targets were
connected.Hence only 3 monitors were seen in the desk.cpl? Now how did
u control which source will be mapped to which of
the active targets in the vidpn topology?
Post by Tim Roberts
The Video-Present-Network manager associated with the Miniport
calls this function in order to make function-together
`co-functional`
the video-present-modes that were associated with the supplied
video present network.
Here i am able traverse the paths present in the topology and provided
the source modes and target modes in DxgkDdiEnumVidPnCofuncModality?
but as i press extend the desktop to
this display i am getting unable to save Display settings error?
what is the importance of DxgkDdiIsSupportedVidPn ? how it should be
handled?
Post by Tim Roberts
The supplied topology has some constrains, and those must not be
touched.
As per my understanding after going through MSDN documentation the
constraints are if a source or target is identified as the pivot of
the enumeration, the mode set for that source or
target must not change.
If i am wrong please rectify me? if any additional constraints are
there please explain?
Post by Tim Roberts
Step 0 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
Source: N/A
Target: N/A
Step 1 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
(1 <-> 4)
Source: N/A
Target: N/A
Step 2 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
(1 <-> 4)
(2 <-> 3)
Source: N/A
Target: N/A
Step 3 - Pivot = D3DKMDT_EPT_VIDPNSOURCE
Paths: (0 <-> 0)
(1 <-> 4)
(2 <-> 3)
Target: N/A
As per ur above mentioned calling sequence each time
DxgkDdiEnumVidPnCofuncModality will be called first with only one
path (0 <-> 0) , second time with two paths (0 <-> 0), (1 <-> 4) and
so on with enum pivot as nopivot , how the OS knows that source id o
is mapped to target id 0 and 1 is mapped to 4?
In between in my analysis i saw DxgkDdiIsSupportedVidPn is called
before calling DxgkDdiEnumVidPnCofuncModality ? what is the need do
we need to return that the constraining vidpn is supported in
DxgkDdiIsSupportedVidPn ?
Alright by now u might have been fed up by my queries ? i will stop
here
please help me i am very much confused with these things and i am
unable to find any help in this regard. It seems only WDK
documentation is the only source of information i found till now which
is not in detail.
Thanks & Regards,
Krish.
krish
2009-12-14 10:11:20 UTC
Permalink
On Dec 11, 2:30 am, "Ivan Brugiolo [MSFT]"
Post by Ivan Brugiolo [MSFT]
Post by krish
Regarding the above do u mean to say we need to provide the no of
video present sources and targets(children) in the  start device?
Why would it make any sense ?
You provide sources and targets, and the user/system decide.
If you cannot support connecting a present-source, with (for example)
and S-Video target, just say the VidPn is not supported, or, remove
that path while the Co-Functional Modality is being built.
Post by krish
Regarding ur Virtual WDDM 1.1 driver i am pretty interested to know
what u did? if possible can u please share the same? it will be very
helpfull for me to understand the WDDM frame
- you need a bus driver disguised as a PCI or PCI-ex bus.
- the bus driver need to provide an IoConnectInterruptEx-connectible
resource
- you need to simulate a DPC routine (in order to simulate DMA completion)
Toaster.sys will not be of much help here.
Post by krish
Now how didu control which source will be mapped to which of
the active targets in the vidpn topology?
I did not control that. I was offered a choice by VIDMM, and, I could veto
that
or supply a path while that dimension was still unconstrained.
Post by krish
As per my understanding after going through MSDN documentation the
constraints are if a source or target is identified as the pivot of
the enumeration, the mode set for that source or target must not change.
I think of is differently. The system is building a graph, and it has 6
constraining factors.
It restricts one factor at the time. The un-constrained factors are free for
you to change.
Post by krish
In between in my analysis i saw DxgkDdiIsSupportedVidPn  is called
before calling DxgkDdiEnumVidPnCofuncModality  ? what is the need do
we need to return that the constraining vidpn is supported in
DxgkDdiIsSupportedVidPn  ?
Probably you are confused by the storm of calls you get.
I think it is more useful to think that `IsSupported` is called after
the system has made a decision about one parameter of the graph it is
building.
Post by krish
please help me i am very much confused with these things and i am
unable to find any help in this regard. It seems only WDK
documentation is the only source of information i found till now which
is not in detail.
I think the WDK documentation is reasonable.
You should write a DumpVidPn function (it will be around 300 lines of code,
do not dispair) and watch how it changes.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm
Post by krish
Why do you want to provide anVidPninitial network ?
I'll take a stab at that.  Because nowhere in the documentation does it say
whether or not thedriverNEEDS to do so.  I don't know whether you've
every read the "video present network" documentation from the point of view
of a relative newcomer, but it is as impenetrable as any technical document
I've ever read.
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you. This is the comment I added to a prototype
virtualWDDM1.1driverI was working on end-of-summer.
Is there any possibility that the source for yourdriverwill be released
to the huddled masses?  There are no longer any goodWDDMsamples, and the
API is rather vast.
--
Providenza & Boekelheide, Inc.
Hi,
first of all my sincere thanks to Mr.Ivan and Mr.Tim for their
responses.
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you.
Regarding the above do u mean to say we need to provide the no of
video present sources and targets(children) in the  start device?
If so yes i had provided them in my start device.
else r u suggesting to provide the source mode sets and target mode
sets? if so where to provide can we do the same in
DxgkDdiEnumVidPnCofuncModality?
This is the comment I added to a prototype
virtualWDDM1.1driverI was working on end-of-summer.
Regarding ur Virtual WDDM 1.1 driver i am pretty interested to know
what u did? if possible can u please share the same? it will be very
helpfull for me to understand the WDDM frame
work.
Thedriverhad 4 present-sources and 5 present-targets,
but only 3 were active. At the end they were showing up as 3 monitors
in desk.cpl.
So u had returned to OS saying that only 3 of the 5 targets were
connected.Hence only 3 monitors were seen in the desk.cpl? Now how did
u control which source will be mapped to which of
the active targets in the vidpn topology?
    The Video-Present-Network manager associated with the Miniport
    calls this function in order to make function-together
`co-functional`
    the video-present-modes that were associated with the supplied
    video present network.
Here i am able traverse the paths present in the topology and provided
the source modes and target modes in DxgkDdiEnumVidPnCofuncModality?
but as i press extend the desktop to
this display i am getting unable to save Display settings error?
what is the importance of DxgkDdiIsSupportedVidPn ? how it should be
handled?
 The supplied topology has some constrains, and those must not be
touched.
As per my understanding after going through MSDN documentation the
constraints are if a source or target is identified as the pivot of
the enumeration, the mode set for that source or
target must not change.
If i am wrong please rectify me?  if any additional constraints are
there please explain?
    Step 0 - Pivot = D3DKMDT_EPT_NOPIVOT
        Paths: (0 <-> 0)
        Source: N/A
        Target: N/A
    Step 1 - Pivot = D3DKMDT_EPT_NOPIVOT
        Paths: (0 <-> 0)
               (1 <-> 4)
        Source: N/A
        Target: N/A
    Step 2 - Pivot = D3DKMDT_EPT_NOPIVOT
        Paths: (0 <-> 0)
               (1 <-> 4)
               (2 <-> 3)
        Source: N/A
        Target: N/A
    Step 3 - Pivot = D3DKMDT_EPT_VIDPNSOURCE
        Paths: (0 <-> 0)
               (1 <-> 4)
               (2 <-> 3)
        Target: N/A
As per ur above mentioned calling sequence each time
DxgkDdiEnumVidPnCofuncModality  will be called first with only one
path (0 <-> 0) , second time with two paths (0 <-> 0), (1 <-> 4) and
so on with enum pivot as nopivot , how the OS knows that source id o
is mapped to target id 0 and 1 is mapped to 4?
In between in my analysis i saw DxgkDdiIsSupportedVidPn  is called
before calling DxgkDdiEnumVidPnCofuncModality  ? what is the need do
we need to return that the constraining vidpn is supported in
DxgkDdiIsSupportedVidPn  ?
Alright by now u might have been fed up by my queries ? i will stop
here
please help me i am very much confused with these things and i am
unable to find any help in this regard. It seems only WDK
documentation is the only source of information i found till now which
is not in detail.
Thanks & Regards,
Krish.
Thanks for ur support. I am replying after implementing ur
suggestions.
Post by Ivan Brugiolo [MSFT]
Why would it make any sense ?
You provide sources and targets, and the user/system decide.
If you cannot support connecting a present-source, with (for example)
and S-Video target, just say the VidPn is not supported, or, remove
that path while the Co-Functional Modality is being built.
Here U have suggested two ways which method is to be used

1-> to say the Vidpn is not supported in IsSupportedVIdpn funtion
2->to remove that path from the constraining vidpn topology

I am following the first one.

I wonder why microsoft doesn't specify these things in their
docementation.
Post by Ivan Brugiolo [MSFT]
- you need a bus driver disguised as a PCI or PCI-ex bus.
- the bus driver need to provide an IoConnectInterruptEx-connectible
resource
- you need to simulate a DPC routine (in order to simulate DMA completion)
Toaster.sys will not be of much help here
here u were saying toaster.sys will not be useful.can u suggest any
thing which will be useful
Is the virtual driver a filter driver which will fake the dxgkrnl.sys
and sits on top of the graphics driver.
what functionality have u achieved with the vitual driver ?
Is there any possibility of u sharing ur virtual WDDM driver. if u
Post by Ivan Brugiolo [MSFT]
Post by krish
Now how didu control which source will be mapped to which of
the active targets in the vidpn topology?
I did not control that. I was offered a choice by VIDMM, and, I could veto
that
or supply a path while that dimension was still unconstrained.
I understood ur point. As per my analysis all the paths are being made
by the OS so while the vidn is being made cofunctional we need to
discard the paths that are not required and add the required paths as
per our required topology.
Post by Ivan Brugiolo [MSFT]
I think of is differently. The system is building a graph, and it has 6
constraining factors.
It restricts one factor at the time. The un-constrained factors are free for
you to change.
Please specify the 6 constraining factors. yes i understood ur point i
even practically checked the same that only un-constrained factors can
be changed.
Post by Ivan Brugiolo [MSFT]
Probably you are confused by the storm of calls you get.
I think it is more useful to think that `IsSupported` is called after
the system has made a decision about one parameter of the graph it is
building.
Yes u r absolutely right i am very much confused by the storm of
enumvidpn and issupported calls.Debug prints are haunting me even in
my dreams too...........
Parameter of the graph u mentioned refers to source, target pinned
modes else paths in the topology ? please expalin
Post by Ivan Brugiolo [MSFT]
I think the WDK documentation is reasonable.
I dont agree with u on WDK documentation, as Tim Roberts was saying
earlier it was impenetrable technical document for me- specially for
WDDM display drivers. it was fairly straight forward for XDDM drivers.

Any ways its not in our hands to control.
Post by Ivan Brugiolo [MSFT]
You should write a DumpVidPn function (it will be around 300 lines of code,
do not dispair) and watch how it changes.
Yeah this suggestion i implemented this week end - the info which i am
viewing

1. Paths in the topology
2.Pinned Modes if any for each path
3.Source mode sets and target sets for each path

Apart from this do u mean to add any thing else in ur DumpVidpn
function? Please explain the brief lay out ur function? if possible
can u share the function DumpVidpn?if u wish u can mail me in person

I have one more query during my analysis i saw that source and target
modes are pinned on my source and targets so i felt that enum vidpn
was handled properly.

But as soon as i press extend desktop and press apply in desk.cpl i am
getting the error "unable to save display setting ". which
dxgkddiXXXXX function might be causing this?

Thanks & Regards,
krish.
Ivan Brugiolo [MSFT]
2009-12-16 09:12:19 UTC
Permalink
Post by krish
here u were saying toaster.sys will not be useful.can u suggest any
thing which will be useful
what functionality have u achieved with the vitual driver ?
At best, the bus drivers I've seen so far build a CM_RESOURCE_LIST
with some fake IO range or memory range, and, their purpose
is to make the Arbiter to make them un-available, even if they are unused.
The challenge is to fake an Interrupt resource, and, make-it go through
IoConnectInterruptEx without errors.
Maybe there are virtual-bus-drivers out there that can do that.
To the best of my research, that were not commodity or easy.
Post by krish
Is the virtual driver a filter driver which will fake the dxgkrnl.sys
and sits on top of the graphics driver.
The filter driver approach (even if somewhat popular with a manufacturer
of USB display extenders) is not viable.
Basically, any port/mini-port pair cannot be filtered `in-between`,
and, you would end-up having a bus-enumerated PnP driver that calls
DxgkInitialize in DriverEntry, and, not much more than that.
Post by krish
it was fairly straight forward for XDDM drivers.
Any ways its not in our hands to control.
I'm not sure about that. Writing a DDraw/DirectX XPDM driver
is to me as impenetrable as a WDDM one.
A vanilla XPDM driver with GDI only support is reasoanbly easy, but, that's
it.
Post by krish
1. Paths in the topology
2.Pinned Modes if any for each path
3.Source mode sets and target sets for each path
Apart from this do u mean to add any thing else in ur DumpVidpn
function? Please explain the brief lay out ur function? if possible
can u share the function DumpVidpn?if u wish u can mail me in person
My mental-model around that is:
- the paths are constrained first
- then the source mode
- then the target mode
- then the scaling/stretching
- then the rotation.
Post by krish
But as soon as i press extend desktop and press apply in desk.cpl i am
getting the error "unable to save display setting ". which
dxgkddiXXXXX function might be causing this?
You should try to get mode-change to work without desktop composition.
Mode Change with DWM-on is one other of magnitude more complex
(together with having full-screen DDraw, DX9 and DX10 full-screen
application
in a 6+ monitor configuration, orver 3 heterogenous adapters, for example).
In SystemPropertiesPerformance.exe uncheck `enable desktop composition`.
At that point, you should get only a worker-thread in CSRSS that drivers the
whole thing.
That thread does a lot of VidPn creation, followed by primary creation.

Did you get your miniport called to create a standard
allocation for the Shadow and the Primary ?

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Post by krish
On Dec 11, 2:30 am, "Ivan Brugiolo [MSFT]"
Post by Ivan Brugiolo [MSFT]
Post by krish
Regarding the above do u mean to say we need to provide the no of
video present sources and targets(children) in the start device?
Why would it make any sense ?
You provide sources and targets, and the user/system decide.
If you cannot support connecting a present-source, with (for example)
and S-Video target, just say the VidPn is not supported, or, remove
that path while the Co-Functional Modality is being built.
Post by krish
Regarding ur Virtual WDDM 1.1 driver i am pretty interested to know
what u did? if possible can u please share the same? it will be very
helpfull for me to understand the WDDM frame
- you need a bus driver disguised as a PCI or PCI-ex bus.
- the bus driver need to provide an IoConnectInterruptEx-connectible
resource
- you need to simulate a DPC routine (in order to simulate DMA completion)
Toaster.sys will not be of much help here.
Post by krish
Now how didu control which source will be mapped to which of
the active targets in the vidpn topology?
I did not control that. I was offered a choice by VIDMM, and, I could veto
that
or supply a path while that dimension was still unconstrained.
Post by krish
As per my understanding after going through MSDN documentation the
constraints are if a source or target is identified as the pivot of
the enumeration, the mode set for that source or target must not change.
I think of is differently. The system is building a graph, and it has 6
constraining factors.
It restricts one factor at the time. The un-constrained factors are free for
you to change.
Post by krish
In between in my analysis i saw DxgkDdiIsSupportedVidPn is called
before calling DxgkDdiEnumVidPnCofuncModality ? what is the need do
we need to return that the constraining vidpn is supported in
DxgkDdiIsSupportedVidPn ?
Probably you are confused by the storm of calls you get.
I think it is more useful to think that `IsSupported` is called after
the system has made a decision about one parameter of the graph it is
building.
Post by krish
please help me i am very much confused with these things and i am
unable to find any help in this regard. It seems only WDK
documentation is the only source of information i found till now which
is not in detail.
I think the WDK documentation is reasonable.
You should write a DumpVidPn function (it will be around 300 lines of code,
do not dispair) and watch how it changes.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified
athttp://www.microsoft.com/info/cpyright.htm
Post by krish
Post by Tim Roberts
Why do you want to provide anVidPninitial network ?
I'll take a stab at that. Because nowhere in the documentation does
it
say
whether or not thedriverNEEDS to do so. I don't know whether you've
every read the "video present network" documentation from the point of view
of a relative newcomer, but it is as impenetrable as any technical document
I've ever read.
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you. This is the comment I added to a prototype
virtualWDDM1.1driverI was working on end-of-summer.
Is there any possibility that the source for yourdriverwill be released
to the huddled masses? There are no longer any goodWDDMsamples, and the
API is rather vast.
--
Providenza & Boekelheide, Inc.
Hi,
first of all my sincere thanks to Mr.Ivan and Mr.Tim for their
responses.
Post by Tim Roberts
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you.
Regarding the above do u mean to say we need to provide the no of
video present sources and targets(children) in the start device?
If so yes i had provided them in my start device.
else r u suggesting to provide the source mode sets and target mode
sets? if so where to provide can we do the same in
DxgkDdiEnumVidPnCofuncModality?
Post by Tim Roberts
This is the comment I added to a prototype
virtualWDDM1.1driverI was working on end-of-summer.
Regarding ur Virtual WDDM 1.1 driver i am pretty interested to know
what u did? if possible can u please share the same? it will be very
helpfull for me to understand the WDDM frame
work.
Post by Tim Roberts
Thedriverhad 4 present-sources and 5 present-targets,
but only 3 were active. At the end they were showing up as 3 monitors
in desk.cpl.
So u had returned to OS saying that only 3 of the 5 targets were
connected.Hence only 3 monitors were seen in the desk.cpl? Now how did
u control which source will be mapped to which of
the active targets in the vidpn topology?
Post by Tim Roberts
The Video-Present-Network manager associated with the Miniport
calls this function in order to make function-together
`co-functional`
the video-present-modes that were associated with the supplied
video present network.
Here i am able traverse the paths present in the topology and provided
the source modes and target modes in DxgkDdiEnumVidPnCofuncModality?
but as i press extend the desktop to
this display i am getting unable to save Display settings error?
what is the importance of DxgkDdiIsSupportedVidPn ? how it should be
handled?
Post by Tim Roberts
The supplied topology has some constrains, and those must not be
touched.
As per my understanding after going through MSDN documentation the
constraints are if a source or target is identified as the pivot of
the enumeration, the mode set for that source or
target must not change.
If i am wrong please rectify me? if any additional constraints are
there please explain?
Post by Tim Roberts
Step 0 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
Source: N/A
Target: N/A
Step 1 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
(1 <-> 4)
Source: N/A
Target: N/A
Step 2 - Pivot = D3DKMDT_EPT_NOPIVOT
Paths: (0 <-> 0)
(1 <-> 4)
(2 <-> 3)
Source: N/A
Target: N/A
Step 3 - Pivot = D3DKMDT_EPT_VIDPNSOURCE
Paths: (0 <-> 0)
(1 <-> 4)
(2 <-> 3)
Target: N/A
As per ur above mentioned calling sequence each time
DxgkDdiEnumVidPnCofuncModality will be called first with only one
path (0 <-> 0) , second time with two paths (0 <-> 0), (1 <-> 4) and
so on with enum pivot as nopivot , how the OS knows that source id o
is mapped to target id 0 and 1 is mapped to 4?
In between in my analysis i saw DxgkDdiIsSupportedVidPn is called
before calling DxgkDdiEnumVidPnCofuncModality ? what is the need do
we need to return that the constraining vidpn is supported in
DxgkDdiIsSupportedVidPn ?
Alright by now u might have been fed up by my queries ? i will stop
here
please help me i am very much confused with these things and i am
unable to find any help in this regard. It seems only WDK
documentation is the only source of information i found till now which
is not in detail.
Thanks & Regards,
Krish.
Thanks for ur support. I am replying after implementing ur
suggestions.
Post by Ivan Brugiolo [MSFT]
Why would it make any sense ?
You provide sources and targets, and the user/system decide.
If you cannot support connecting a present-source, with (for example)
and S-Video target, just say the VidPn is not supported, or, remove
that path while the Co-Functional Modality is being built.
Here U have suggested two ways which method is to be used
1-> to say the Vidpn is not supported in IsSupportedVIdpn funtion
2->to remove that path from the constraining vidpn topology
I am following the first one.
I wonder why microsoft doesn't specify these things in their
docementation.
Post by Ivan Brugiolo [MSFT]
- you need a bus driver disguised as a PCI or PCI-ex bus.
- the bus driver need to provide an IoConnectInterruptEx-connectible
resource
- you need to simulate a DPC routine (in order to simulate DMA completion)
Toaster.sys will not be of much help here
here u were saying toaster.sys will not be useful.can u suggest any
thing which will be useful
Is the virtual driver a filter driver which will fake the dxgkrnl.sys
and sits on top of the graphics driver.
what functionality have u achieved with the vitual driver ?
Is there any possibility of u sharing ur virtual WDDM driver. if u
Post by Ivan Brugiolo [MSFT]
Post by krish
Now how didu control which source will be mapped to which of
the active targets in the vidpn topology?
I did not control that. I was offered a choice by VIDMM, and, I could veto
that
or supply a path while that dimension was still unconstrained.
I understood ur point. As per my analysis all the paths are being made
by the OS so while the vidn is being made cofunctional we need to
discard the paths that are not required and add the required paths as
per our required topology.
Post by Ivan Brugiolo [MSFT]
I think of is differently. The system is building a graph, and it has 6
constraining factors.
It restricts one factor at the time. The un-constrained factors are free for
you to change.
Please specify the 6 constraining factors. yes i understood ur point i
even practically checked the same that only un-constrained factors can
be changed.
Post by Ivan Brugiolo [MSFT]
Probably you are confused by the storm of calls you get.
I think it is more useful to think that `IsSupported` is called after
the system has made a decision about one parameter of the graph it is
building.
Yes u r absolutely right i am very much confused by the storm of
enumvidpn and issupported calls.Debug prints are haunting me even in
my dreams too...........
Parameter of the graph u mentioned refers to source, target pinned
modes else paths in the topology ? please expalin
Post by Ivan Brugiolo [MSFT]
I think the WDK documentation is reasonable.
I dont agree with u on WDK documentation, as Tim Roberts was saying
earlier it was impenetrable technical document for me- specially for
WDDM display drivers. it was fairly straight forward for XDDM drivers.
Any ways its not in our hands to control.
Post by Ivan Brugiolo [MSFT]
You should write a DumpVidPn function (it will be around 300 lines of code,
do not dispair) and watch how it changes.
Yeah this suggestion i implemented this week end - the info which i am
viewing
1. Paths in the topology
2.Pinned Modes if any for each path
3.Source mode sets and target sets for each path
Apart from this do u mean to add any thing else in ur DumpVidpn
function? Please explain the brief lay out ur function? if possible
can u share the function DumpVidpn?if u wish u can mail me in person
I have one more query during my analysis i saw that source and target
modes are pinned on my source and targets so i felt that enum vidpn
was handled properly.
But as soon as i press extend desktop and press apply in desk.cpl i am
getting the error "unable to save display setting ". which
dxgkddiXXXXX function might be causing this?
Thanks & Regards,
krish.
krish
2009-12-28 12:04:33 UTC
Permalink
Hi Ivan,
Post by Ivan Brugiolo [MSFT]
You should try to get mode-change to work without desktop composition.
Mode Change with DWM-on is one other of magnitude more complex
(together with having full-screen DDraw, DX9 and DX10 full-screen
application
in a 6+ monitor configuration, orver 3 heterogenous adapters, for example).
In SystemPropertiesPerformance.exe uncheck `enable desktop composition`.
At that point, you should get only a worker-thread in CSRSS that drivers the
whole thing.
That thread does a lot of VidPn creation, followed by primary creation.
With your valuable suggestion i was able to make the Vidpn
cofunctional with the Windows Basic theme(with out Desktop
Composition) and extend desktop display settings is also working quiet
fine.

But as soon as i enable Aero theme screen starts to flicker . so what
DxgkDDIXXXX calls need to be handled to overcome this situation?
please suggest the handling in brief.

I am repeatedly getting call of updateActivevidpn in the miniport
driver as soon as i enable Aero theme. Any thing to do with the Vidpn
path source modes for aero?
Post by Ivan Brugiolo [MSFT]
Did you get your miniport called to create a standard
allocation for the Shadow and the Primary ?
Yes i am getting calls of DxgkDdiGetStandardAllocationDriverData? any
specific handling need to be done for Aero in this??

One more query is How OS will be distinguishing between primary and
secondary display surfaces in the case of WDDM apart from source and
target ids ? specifically with respect to Memory?
Post by Ivan Brugiolo [MSFT]
The filter driver approach (even if somewhat popular with a manufacturer
of USB display extenders) is not viable.
Basically, any port/mini-port pair cannot be filtered `in-between`,
and, you would end-up having a bus-enumerated PnP driver that calls
DxgkInitialize in DriverEntry, and, not much more than that.
How this approach is feasible with respect to WDDM architeture.
exactly how can one get access to the memory where the Drawings
happen ?


Thanks & Regards,
krish
krish
2009-12-28 12:04:42 UTC
Permalink
Hi Ivan,
Post by Ivan Brugiolo [MSFT]
You should try to get mode-change to work without desktop composition.
Mode Change with DWM-on is one other of magnitude more complex
(together with having full-screen DDraw, DX9 and DX10 full-screen
application
in a 6+ monitor configuration, orver 3 heterogenous adapters, for example).
In SystemPropertiesPerformance.exe uncheck `enable desktop composition`.
At that point, you should get only a worker-thread in CSRSS that drivers the
whole thing.
That thread does a lot of VidPn creation, followed by primary creation.
With your valuable suggestion i was able to make the Vidpn
cofunctional with the Windows Basic theme(with out Desktop
Composition) and extend desktop display settings is also working quiet
fine.

But as soon as i enable Aero theme screen starts to flicker . so what
DxgkDDIXXXX calls need to be handled to overcome this situation?
please suggest the handling in brief.

I am repeatedly getting call of updateActivevidpn in the miniport
driver as soon as i enable Aero theme. Any thing to do with the Vidpn
path source modes for aero?
Post by Ivan Brugiolo [MSFT]
Did you get your miniport called to create a standard
allocation for the Shadow and the Primary ?
Yes i am getting calls of DxgkDdiGetStandardAllocationDriverData? any
specific handling need to be done for Aero in this??

One more query is How OS will be distinguishing between primary and
secondary display surfaces in the case of WDDM apart from source and
target ids ? specifically with respect to Memory?
Post by Ivan Brugiolo [MSFT]
The filter driver approach (even if somewhat popular with a manufacturer
of USB display extenders) is not viable.
Basically, any port/mini-port pair cannot be filtered `in-between`,
and, you would end-up having a bus-enumerated PnP driver that calls
DxgkInitialize in DriverEntry, and, not much more than that.
How this approach is feasible with respect to WDDM architeture.
exactly how can one get access to the memory where the Drawings
happen ?


Thanks & Regards,
krish
Ivan Brugiolo [MSFT]
2009-12-28 21:59:42 UTC
Permalink
Post by krish
But as soon as i enable Aero theme screen starts to flicker . so what
DxgkDDIXXXX calls need to be handled to overcome this situation?
please suggest the handling in brief.
I am repeatedly getting call of updateActivevidpn in the miniport
driver as soon as i enable Aero theme. Any thing to do with the Vidpn
path source modes for aero?
Now that the basic part works, you should try
with a DX10 application going full-screen on one monitor.
First the monitor not owned by your WDDM driver,
then to the monitor owned by your driver.
Post by krish
I am repeatedly getting call of updateActivevidpn in the miniport
driver as soon as i enable Aero theme. Any thing to do with the Vidpn
path source modes for aero?
You should do nothing. In Windows7, dwm.exe is designed to
'inherit' or 'fully-match' the GDI-mode that was set by CDD.
That is, the VidPn should not functionally change, even if there
will be different kind of primary pair that you will be asked to create
and scan-out.
If you debug the 2-backbuffer-shapchain DX10 application going
full-screen, you should have that code-path covered.
Post by krish
Yes i am getting calls of DxgkDdiGetStandardAllocationDriverData? any
specific handling need to be done for Aero in this??
You should not get a Standard-Allocation call for a user-mode owned
shapchain.
Post by krish
One more query is How OS will be distinguishing between primary and
secondary display surfaces in the case of WDDM apart from source and
target ids ? specifically with respect to Memory?
I'm not sure I understand the question.
CDD creates two Standard Allocations per VidPn-source.
One `sharedprimary` and one `shadow`.
Dwm.exe (and any DX10/DX9/DDraw application) creates non-standard
allocations.
The idea of the `shadow` is that is is always CPU visible. That's why it
should
be created in an Aperture segment. That depends on how you described
your segments when you were asked to.
Post by krish
How this approach is feasible with respect to WDDM architeture.
exactly how can one get access to the memory where the Drawings
happen ?
If you are wishing to go the bus-enumerated devices approach, then
the approach is viable, but, you will have some difficulty in simulating
the PCI-bus features (Interrupt and memory-mapping being some).
What is not viable is piggy-backing on
an existing WDDM driver by call interception means.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Post by krish
Hi Ivan,
Post by Ivan Brugiolo [MSFT]
You should try to get mode-change to work without desktop composition.
Mode Change with DWM-on is one other of magnitude more complex
(together with having full-screen DDraw, DX9 and DX10 full-screen
application
in a 6+ monitor configuration, orver 3 heterogenous adapters, for example).
In SystemPropertiesPerformance.exe uncheck `enable desktop composition`.
At that point, you should get only a worker-thread in CSRSS that drivers the
whole thing.
That thread does a lot of VidPn creation, followed by primary creation.
With your valuable suggestion i was able to make the Vidpn
cofunctional with the Windows Basic theme(with out Desktop
Composition) and extend desktop display settings is also working quiet
fine.
But as soon as i enable Aero theme screen starts to flicker . so what
DxgkDDIXXXX calls need to be handled to overcome this situation?
please suggest the handling in brief.
I am repeatedly getting call of updateActivevidpn in the miniport
driver as soon as i enable Aero theme. Any thing to do with the Vidpn
path source modes for aero?
Post by Ivan Brugiolo [MSFT]
Did you get your miniport called to create a standard
allocation for the Shadow and the Primary ?
Yes i am getting calls of DxgkDdiGetStandardAllocationDriverData? any
specific handling need to be done for Aero in this??
One more query is How OS will be distinguishing between primary and
secondary display surfaces in the case of WDDM apart from source and
target ids ? specifically with respect to Memory?
Post by Ivan Brugiolo [MSFT]
The filter driver approach (even if somewhat popular with a manufacturer
of USB display extenders) is not viable.
Basically, any port/mini-port pair cannot be filtered `in-between`,
and, you would end-up having a bus-enumerated PnP driver that calls
DxgkInitialize in DriverEntry, and, not much more than that.
How this approach is feasible with respect to WDDM architeture.
exactly how can one get access to the memory where the Drawings
happen ?
Thanks & Regards,
krish
krish
2009-12-29 15:09:38 UTC
Permalink
Hi ivan,

I was able to understand ur post in bits and pieces but
not entirely, may be as i am not familiar with the DX10 stuff.
Post by Ivan Brugiolo [MSFT]
Now that the basic part works, you should try
with a DX10 application going full-screen on one monitor.
First the monitor not owned by your WDDM driver,
then to the monitor owned by your driver.
Do mean to say that i need to check the driver calls when DX10
application is running in full screen mode.can u suggest any simple
DX10 application other than the heavy 3D games? I am trying with
Cascades demo application but it seems to work only on NVIDIA cards.
Post by Ivan Brugiolo [MSFT]
You should do nothing. In Windows7, dwm.exe is designed to
'inherit' or 'fully-match' the GDI-mode that was set by CDD.
That is, the VidPn should not functionally change, even if there
will be different kind of primary pair that you will be asked to create
and scan-out.
Yeah i understood so i need not medle with currently functional vidpn.
Post by Ivan Brugiolo [MSFT]
If you debug the 2-backbuffer-shapchain DX10 application going
full-screen, you should have that code-path covered.
"2-backbuffer-shapchain"- what is this? is this an DX10 application,
if so i googled for the same but couldnt find ? can u elaborate more
on this.
Post by Ivan Brugiolo [MSFT]
You should not get a Standard-Allocation call for a user-mode owned
shapchain.
u mean to say for shapchain application i shouldnt get the Standard-
Allocation call? once i explore that application i will let u know.
Post by Ivan Brugiolo [MSFT]
I'm not sure I understand the question.
My query was in the filter driver approach for WDDM u mentioned how
come the filter driver distinguishes primary and secondary( created by
the Filter). for the secondary how it allocates the memory and
accesess the same secondary sutrface memory.

Is there any way to provide memory to the OS to draw in WDDM as it
was done earlier in xddm in DrvEnableSurface.
Post by Ivan Brugiolo [MSFT]
CDD creates two Standard Allocations per VidPn-source.
One `sharedprimary` and one `shadow`.
Dwm.exe (and any DX10/DX9/DDraw application) creates non-standard
allocations.
The idea of the `shadow` is that is is always CPU visible. That's why it
should
be created in an Aperture segment. That depends on how you described
your segments when you were asked to.
So the two standard allocations will be allocated in
GetStandardAllocation call- as per my understanding.

so as per ur explanation shadow surface will be identical ( same
contents) to the shared primary except that shadow is visible in
system memory of CPU.
what abt the STANDARDALLOCATION_GDISURFACE which is used for for GDI
hardware acceleration and Desktop Windows Manager (DWM) redirection.is
this the memory used During desktop composition.

How the Non-standard allocations created by DWM and other DX
application visible to driver? any call in specific?

where to provide the segment descriptions?
Post by Ivan Brugiolo [MSFT]
If you are wishing to go the bus-enumerated devices approach, then
the approach is viable, but, you will have some difficulty in simulating
the PCI-bus features (Interrupt and memory-mapping being some).
What is not viable is piggy-backing on
an existing WDDM driver by call interception means.
Ok what are the hardships in Bus-Enumerated devices approach, as u
mentioned earlier can u share ur Virtual Bus enumerated WDDM driver
for reference?

I am quiet confused regarding the memory mapping in WDDM, can u please
direct me to some links where i can clarify myself ? r u can give an
insight on the same.

Thanks & Regards,
Krish.
Ivan Brugiolo [MSFT]
2009-12-29 19:01:11 UTC
Permalink
Post by krish
Do mean to say that i need to check the driver calls when DX10
application is running in full screen mode.can u suggest any simple
DX10 application other than the heavy 3D games? I am trying with
Cascades demo application but it seems to work only on NVIDIA cards.
You really need to start from something really simple, because
you are interested to develop the user-mode part of WDDM,
and, you want to start from one application going full-screen
and clearing the back-buffer with a solid color.
Check this book for something really simple ISBN-10: 1598633619.
Post by krish
"2-backbuffer-shapchain"- what is this? is this an DX10 application,
if so i googled for the same but couldnt find ? can u elaborate more
on this.
DXGI_SWAP_CHAIN_DESC DescSC;
ZeroMemory(&DescSC, sizeof(DescSC));
DescSC.BufferDesc.Width = 1024;
DescSC.BufferDesc.Height = 768;
DescSC.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
DescSC.SampleDesc.Count = 1;
DescSC.SampleDesc.Quality = 0;
DescSC.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
DescSC.BufferCount = 2;
DescSC.OutputWindow = hWnd;
DescSC.Windowed = TRUE;
DescSC.SwapEffect = DXGI_SWAP_EFFECT_DISCARD;
DescSC.Flags = 0;

HRET(Factory->MakeWindowAssociation(hWnd, 0));

HRET(Factory->CreateSwapChain(m_Device, &DescSC, m_SwapChain));
Post by krish
My query was in the filter driver approach for WDDM u mentioned how
come the filter driver distinguishes primary and secondary( created by
the Filter). for the secondary how it allocates the memory and
accesess the same secondary sutrface memory.
I speculate that the `WDDM-filter` adds a couple of VipPn-Sources.
Sources are sequential from 0 to the number reported by the MiniPort,
so, that number assignment is well-knonw.
Then, the VidPn-Source is passed down to
DxgkDdiGetStandardAllocationDriverData,
where you can store-in in the private data for your allocation.
Post by krish
Is there any way to provide memory to the OS to draw in WDDM as it
was done earlier in xddm in DrvEnableSurface.
No, no way. That is one of the fundamental differences XPDM / WDDM.
WDDM has a full-fledge video-memory-manager.
You describe the segments to it in DXGKQAITYPE_QUERYSEGMENT.
Then, it will require you to perform
page-in / page-out operations, from Memory-Space to Aperture,
by building DMA-paging command-buffers.
Post by krish
So the two standard allocations will be allocated in
GetStandardAllocation call- as per my understanding.
No, they will be create in DxgkDdiCreateAllocation.
Actually, you will be required to describe the allocation
requirements, and then VidMM will carve them out from the segments.
Post by krish
so as per ur explanation shadow surface will be identical ( same
contents) to the shared primary except that shadow is visible in
system memory of CPU.
They may have the same `pixel content`, but, they will likely not
have the same physical content (because of swizzling and other Ram-Dac
constrains),
they will not have the same content at the same time (because of DxgkPresent
is a trigger for an Async-DMA) and they will not be equally accessible
from the CPU and/or the bus.
Post by krish
what abt the STANDARDALLOCATION_GDISURFACE which is used for for GDI
hardware acceleration and Desktop Windows Manager (DWM) redirection.is
this the memory used During desktop composition.
This is really a trick to create a non-standard allocation from kernel-mode
so that it can be shared across processes. You can skip this for now,
since it will become relevant after you've solved other issues.
Post by krish
How the Non-standard allocations created by DWM and other DX
application visible to driver? any call in specific?
The user-mode driver provide private data to describe them.
Then, the data is passed to kernel-mode as part of Allocation-Creation.
Post by krish
where to provide the segment descriptions?
You do that in DXGKQAITYPE_QUERYSEGMENT
Post by krish
Ok what are the hardships in Bus-Enumerated devices approach, as u
mentioned earlier can u share ur Virtual Bus enumerated WDDM driver
for reference?
The difficulties of the bus approach are to simulate a functional
PCI/AGP/PCIex bus,
including interrupt.
I cannot share a piece of work that was only in week 3 of a
potentially 3/6 month project to get to a meaningful completion level.
Also, I'm not sure that is aligned with current or future thinking
with regard of the WDDM driver development support,
because I'm not involved with Desktop-Graphics anymore.
Post by krish
I am quiet confused regarding the memory mapping in WDDM, can u please
direct me to some links where i can clarify myself ? r u can give an
insight on the same.
If you are confused, then I think you started the wrong point.
To me understanding the VidMM model interaction with the segments
you describe is more important than the VidPn management.
At the end-of-the-day, the user will pick a mode and stay with it for the
day,
while it will perform operations that will create and destroy allocations.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Post by krish
Hi ivan,
I was able to understand ur post in bits and pieces but
not entirely, may be as i am not familiar with the DX10 stuff.
Post by Ivan Brugiolo [MSFT]
Now that the basic part works, you should try
with a DX10 application going full-screen on one monitor.
First the monitor not owned by your WDDM driver,
then to the monitor owned by your driver.
Do mean to say that i need to check the driver calls when DX10
application is running in full screen mode.can u suggest any simple
DX10 application other than the heavy 3D games? I am trying with
Cascades demo application but it seems to work only on NVIDIA cards.
Post by Ivan Brugiolo [MSFT]
You should do nothing. In Windows7, dwm.exe is designed to
'inherit' or 'fully-match' the GDI-mode that was set by CDD.
That is, the VidPn should not functionally change, even if there
will be different kind of primary pair that you will be asked to create
and scan-out.
Yeah i understood so i need not medle with currently functional vidpn.
Post by Ivan Brugiolo [MSFT]
If you debug the 2-backbuffer-shapchain DX10 application going
full-screen, you should have that code-path covered.
"2-backbuffer-shapchain"- what is this? is this an DX10 application,
if so i googled for the same but couldnt find ? can u elaborate more
on this.
Post by Ivan Brugiolo [MSFT]
You should not get a Standard-Allocation call for a user-mode owned
shapchain.
u mean to say for shapchain application i shouldnt get the Standard-
Allocation call? once i explore that application i will let u know.
Post by Ivan Brugiolo [MSFT]
I'm not sure I understand the question.
My query was in the filter driver approach for WDDM u mentioned how
come the filter driver distinguishes primary and secondary( created by
the Filter). for the secondary how it allocates the memory and
accesess the same secondary sutrface memory.
Is there any way to provide memory to the OS to draw in WDDM as it
was done earlier in xddm in DrvEnableSurface.
Post by Ivan Brugiolo [MSFT]
CDD creates two Standard Allocations per VidPn-source.
One `sharedprimary` and one `shadow`.
Dwm.exe (and any DX10/DX9/DDraw application) creates non-standard
allocations.
The idea of the `shadow` is that is is always CPU visible. That's why it
should
be created in an Aperture segment. That depends on how you described
your segments when you were asked to.
So the two standard allocations will be allocated in
GetStandardAllocation call- as per my understanding.
so as per ur explanation shadow surface will be identical ( same
contents) to the shared primary except that shadow is visible in
system memory of CPU.
what abt the STANDARDALLOCATION_GDISURFACE which is used for for GDI
hardware acceleration and Desktop Windows Manager (DWM) redirection.is
this the memory used During desktop composition.
How the Non-standard allocations created by DWM and other DX
application visible to driver? any call in specific?
where to provide the segment descriptions?
Post by Ivan Brugiolo [MSFT]
If you are wishing to go the bus-enumerated devices approach, then
the approach is viable, but, you will have some difficulty in simulating
the PCI-bus features (Interrupt and memory-mapping being some).
What is not viable is piggy-backing on
an existing WDDM driver by call interception means.
Ok what are the hardships in Bus-Enumerated devices approach, as u
mentioned earlier can u share ur Virtual Bus enumerated WDDM driver
for reference?
I am quiet confused regarding the memory mapping in WDDM, can u please
direct me to some links where i can clarify myself ? r u can give an
insight on the same.
Thanks & Regards,
Krish.
krish
2010-01-21 15:42:10 UTC
Permalink
Hi Ivan,

Sorry for replying late as i was going through the Book u suggested
(it was pretty helpful) and going through the User Mode driver part of
the WDDM.
Post by Ivan Brugiolo [MSFT]
You really need to start from something really simple, because
you are interested to develop the user-mode part of WDDM,
and, you want to start from one application going full-screen
and clearing the back-buffer with a solid color.
Check this book for something really simple ISBN-10: 1598633619.
Regarding the User Mode Driver i am facing the problem of loading the
USER MODE driver.can u plaese explain how to load my user Mode driver
for the secondary in addition to the existing User mode driver(for
primary) as i dont have a UserModeDriverName registry key in Display
Class registry.

can u suggest the ways how we can load the user mode driver so that i
can support D3D calls for my secondary??


Thanks & Regards
Krish
Post by Ivan Brugiolo [MSFT]
"2-backbuffer-shapchain"- what is this?  is this an DX10 application,
if so i googled for the same but couldnt find ? can u elaborate more
on this.
        DXGI_SWAP_CHAIN_DESC DescSC;
        ZeroMemory(&DescSC, sizeof(DescSC));
        DescSC.BufferDesc.Width = 1024;
        DescSC.BufferDesc.Height = 768;
        DescSC.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
        DescSC.SampleDesc.Count = 1;
        DescSC.SampleDesc.Quality = 0;
        DescSC.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
        DescSC.BufferCount = 2;
        DescSC.OutputWindow = hWnd;
        DescSC.Windowed = TRUE;
        DescSC.SwapEffect = DXGI_SWAP_EFFECT_DISCARD;
        DescSC.Flags = 0;
        HRET(Factory->MakeWindowAssociation(hWnd, 0));
        HRET(Factory->CreateSwapChain(m_Device, &DescSC, m_SwapChain));
My query was in the filter driver approach for WDDM u mentioned  how
come the filter driver distinguishes primary and secondary( created by
the Filter). for the secondary how it allocates the memory and
accesess the same secondary sutrface memory.
I speculate that the `WDDM-filter` adds a couple of VipPn-Sources.
Sources are sequential from 0 to the number reported by the MiniPort,
so, that number assignment is well-knonw.
Then, the VidPn-Source is passed down to
DxgkDdiGetStandardAllocationDriverData,
where you can store-in in the private data for your allocation.
Is there any way to provide  memory to the OS to draw in WDDM as it
was done earlier in xddm in DrvEnableSurface.
No, no way. That is one of the fundamental differences XPDM / WDDM.
WDDM has a full-fledge video-memory-manager.
You describe the segments to it in DXGKQAITYPE_QUERYSEGMENT.
Then, it will require you to perform
page-in / page-out operations, from Memory-Space to Aperture,
by building DMA-paging command-buffers.
So the two standard allocations will be allocated in
GetStandardAllocation call- as per my understanding.
No, they will be create in DxgkDdiCreateAllocation.
Actually, you will be required to describe the allocation
requirements, and then VidMM will carve them out from the segments.
so as per ur explanation shadow surface will be identical ( same
contents) to the shared primary except that shadow  is visible in
system memory of CPU.
They may have the same `pixel content`, but, they will likely not
have the same physical content (because of swizzling and other Ram-Dac
constrains),
they will not have the same content at the same time (because of DxgkPresent
is a trigger for an Async-DMA) and they will not be equally accessible
from the CPU and/or the bus.
what abt the STANDARDALLOCATION_GDISURFACE  which is used for for GDI
hardware acceleration and Desktop Windows Manager (DWM) redirection.is
this the memory used During desktop composition.
This is really a trick to create a non-standard allocation from kernel-mode
so that it can be shared across processes. You can skip this for now,
since it will become relevant after you've solved other issues.
How the Non-standard allocations created by DWM and other DX
application visible to driver? any call in specific?
The user-mode driver provide private data to describe them.
Then, the data is passed to kernel-mode as part of Allocation-Creation.
where to provide the segment descriptions?
You do that in DXGKQAITYPE_QUERYSEGMENT
Ok what are the hardships in Bus-Enumerated devices approach, as u
mentioned earlier can u share ur Virtual Bus enumerated WDDM driver
for reference?
The difficulties of the bus approach are to simulate a functional
PCI/AGP/PCIex bus,
including interrupt.
I cannot share a piece of work that was only in week 3 of a
potentially 3/6 month project to get to a meaningful completion level.
Also, I'm not sure that is aligned with current or future thinking
with regard of the WDDM driver development support,
because I'm not involved with Desktop-Graphics anymore.
I am quiet confused regarding the memory mapping in WDDM, can u please
direct me to some links where i can clarify myself ? r u can give an
insight on the same.
If you are confused, then I think you started the wrong point.
To me understanding the VidMM model interaction with the segments
you describe is more important than the VidPn management.
At the end-of-the-day, the user will pick a mode and stay with it for the
day,
while it will perform operations that will create and destroy allocations.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm
Hi ivan,
              I was able to understand ur post in bits and pieces but
not entirely, may be as i am not familiar with the DX10 stuff.
Post by Ivan Brugiolo [MSFT]
Now that the basic part works, you should try
with a DX10 application going full-screen on one monitor.
First the monitor not owned by your WDDM driver,
then to the monitor owned by your driver.
Do mean to say that i need to check the driver calls when DX10
application is running in full screen mode.can u suggest any simple
DX10 application other than the heavy 3D games? I am trying with
Cascades demo application but it seems to work only on NVIDIA cards.
Post by Ivan Brugiolo [MSFT]
You should do nothing. In Windows7, dwm.exe is designed to
'inherit' or 'fully-match' the GDI-mode that was set by CDD.
That is, the VidPn should not functionally change, even if there
will be different kind of primary pair that you will be asked to create
and scan-out.
Yeah i understood so i need not medle with currently functional vidpn.
Post by Ivan Brugiolo [MSFT]
If you debug the 2-backbuffer-shapchain DX10 application going
full-screen, you should have that code-path covered.
"2-backbuffer-shapchain"- what is this?  is this an DX10 application,
if so i googled for the same but couldnt find ? can u elaborate more
on this.
Post by Ivan Brugiolo [MSFT]
You should not get a Standard-Allocation call for a user-mode owned
shapchain.
u mean to say for shapchain application i shouldnt get the  Standard-
Allocation call? once i explore that application i will let u know.
Post by Ivan Brugiolo [MSFT]
I'm not sure I understand the question.
My query was in the filter driver approach for WDDM u mentioned  how
come the filter driver distinguishes primary and secondary( created by
the Filter). for the secondary how it allocates the memory and
accesess the same secondary sutrface memory.
Is there any way to provide  memory to the OS to draw in WDDM as it
was done earlier in xddm in DrvEnableSurface.
Post by Ivan Brugiolo [MSFT]
CDD creates two Standard Allocations per VidPn-source.
One `sharedprimary` and one `shadow`.
Dwm.exe (and any DX10/DX9/DDraw application) creates non-standard
allocations.
The idea of the `shadow` is that is is always CPU visible. That's why it
should
be created in an Aperture segment. That depends on how you described
your segments when you were asked to.
So the two standard allocations will be allocated in
GetStandardAllocation call- as per my understanding.
so as per ur explanation shadow surface will be identical ( same
contents) to the shared primary except that shadow  is visible in
system memory of CPU.
what abt the STANDARDALLOCATION_GDISURFACE  which is used for for GDI
hardware acceleration and Desktop Windows Manager (DWM) redirection.is
this the memory used During desktop composition.
How the Non-standard allocations created by DWM and other DX
application visible to driver? any call in specific?
where to provide the segment descriptions?
Post by Ivan Brugiolo [MSFT]
If you are wishing to go the bus-enumerated devices approach, then
the approach is viable, but, you will have some difficulty in simulating
the PCI-bus features (Interrupt and memory-mapping being some).
What is not viable is piggy-backing on
an existing WDDM driver by call interception means.
Ok what are the hardships in Bus-Enumerated devices approach, as u
mentioned earlier can u share ur Virtual Bus enumerated WDDM driver
for reference?
I am quiet confused regarding the memory mapping in WDDM, can u please
direct me to some links where i can clarify myself ? r u can give an
insight on the same.
Thanks & Regards,
Krish.
Ivan Brugiolo [MSFT]
2010-01-21 20:10:48 UTC
Permalink
You do not need a user mode driver per monitor.
The very fact that you ask the question raises the doubt if you have
minimally understood the model for which you are asked to provide a driver.

The user mode driver is loaded by a runtime
(DDraw/D3D9/DXGI/D3d10Level9, etc, etc).
It is loaded once per process per runtime instance.
The user mode driver coordinate with the runtime (through a callback
interface) things such as mode-change, present, render, resource creation
and the such.

You can have one user-mode driver piloting 6 monitors (for example),
all from the same application. This is what dwm.exe normally does,
and other multi-mon DX applications as well.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Post by krish
Hi Ivan,
Sorry for replying late as i was going through the Book u suggested
(it was pretty helpful) and going through the User Mode driver part of
the WDDM.
Post by Ivan Brugiolo [MSFT]
You really need to start from something really simple, because
you are interested to develop the user-mode part of WDDM,
and, you want to start from one application going full-screen
and clearing the back-buffer with a solid color.
Check this book for something really simple ISBN-10: 1598633619.
Regarding the User Mode Driver i am facing the problem of loading the
USER MODE driver.can u plaese explain how to load my user Mode driver
for the secondary in addition to the existing User mode driver(for
primary) as i dont have a UserModeDriverName registry key in Display
Class registry.
can u suggest the ways how we can load the user mode driver so that i
can support D3D calls for my secondary??
Thanks & Regards
Krish
Post by Ivan Brugiolo [MSFT]
Post by krish
"2-backbuffer-shapchain"- what is this? is this an DX10 application,
if so i googled for the same but couldnt find ? can u elaborate more
on this.
DXGI_SWAP_CHAIN_DESC DescSC;
ZeroMemory(&DescSC, sizeof(DescSC));
DescSC.BufferDesc.Width = 1024;
DescSC.BufferDesc.Height = 768;
DescSC.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
DescSC.SampleDesc.Count = 1;
DescSC.SampleDesc.Quality = 0;
DescSC.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
DescSC.BufferCount = 2;
DescSC.OutputWindow = hWnd;
DescSC.Windowed = TRUE;
DescSC.SwapEffect = DXGI_SWAP_EFFECT_DISCARD;
DescSC.Flags = 0;
HRET(Factory->MakeWindowAssociation(hWnd, 0));
HRET(Factory->CreateSwapChain(m_Device, &DescSC, m_SwapChain));
Post by krish
My query was in the filter driver approach for WDDM u mentioned how
come the filter driver distinguishes primary and secondary( created by
the Filter). for the secondary how it allocates the memory and
accesess the same secondary sutrface memory.
I speculate that the `WDDM-filter` adds a couple of VipPn-Sources.
Sources are sequential from 0 to the number reported by the MiniPort,
so, that number assignment is well-knonw.
Then, the VidPn-Source is passed down to
DxgkDdiGetStandardAllocationDriverData,
where you can store-in in the private data for your allocation.
Post by krish
Is there any way to provide memory to the OS to draw in WDDM as it
was done earlier in xddm in DrvEnableSurface.
No, no way. That is one of the fundamental differences XPDM / WDDM.
WDDM has a full-fledge video-memory-manager.
You describe the segments to it in DXGKQAITYPE_QUERYSEGMENT.
Then, it will require you to perform
page-in / page-out operations, from Memory-Space to Aperture,
by building DMA-paging command-buffers.
Post by krish
So the two standard allocations will be allocated in
GetStandardAllocation call- as per my understanding.
No, they will be create in DxgkDdiCreateAllocation.
Actually, you will be required to describe the allocation
requirements, and then VidMM will carve them out from the segments.
Post by krish
so as per ur explanation shadow surface will be identical ( same
contents) to the shared primary except that shadow is visible in
system memory of CPU.
They may have the same `pixel content`, but, they will likely not
have the same physical content (because of swizzling and other Ram-Dac
constrains),
they will not have the same content at the same time (because of DxgkPresent
is a trigger for an Async-DMA) and they will not be equally accessible
from the CPU and/or the bus.
Post by krish
what abt the STANDARDALLOCATION_GDISURFACE which is used for for GDI
hardware acceleration and Desktop Windows Manager (DWM) redirection.is
this the memory used During desktop composition.
This is really a trick to create a non-standard allocation from kernel-mode
so that it can be shared across processes. You can skip this for now,
since it will become relevant after you've solved other issues.
Post by krish
How the Non-standard allocations created by DWM and other DX
application visible to driver? any call in specific?
The user-mode driver provide private data to describe them.
Then, the data is passed to kernel-mode as part of Allocation-Creation.
Post by krish
where to provide the segment descriptions?
You do that in DXGKQAITYPE_QUERYSEGMENT
Post by krish
Ok what are the hardships in Bus-Enumerated devices approach, as u
mentioned earlier can u share ur Virtual Bus enumerated WDDM driver
for reference?
The difficulties of the bus approach are to simulate a functional
PCI/AGP/PCIex bus,
including interrupt.
I cannot share a piece of work that was only in week 3 of a
potentially 3/6 month project to get to a meaningful completion level.
Also, I'm not sure that is aligned with current or future thinking
with regard of the WDDM driver development support,
because I'm not involved with Desktop-Graphics anymore.
Post by krish
I am quiet confused regarding the memory mapping in WDDM, can u please
direct me to some links where i can clarify myself ? r u can give an
insight on the same.
If you are confused, then I think you started the wrong point.
To me understanding the VidMM model interaction with the segments
you describe is more important than the VidPn management.
At the end-of-the-day, the user will pick a mode and stay with it for the
day,
while it will perform operations that will create and destroy
allocations.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified
athttp://www.microsoft.com/info/cpyright.htm
Post by krish
Hi ivan,
I was able to understand ur post in bits and pieces but
not entirely, may be as i am not familiar with the DX10 stuff.
Post by Ivan Brugiolo [MSFT]
Now that the basic part works, you should try
with a DX10 application going full-screen on one monitor.
First the monitor not owned by your WDDM driver,
then to the monitor owned by your driver.
Do mean to say that i need to check the driver calls when DX10
application is running in full screen mode.can u suggest any simple
DX10 application other than the heavy 3D games? I am trying with
Cascades demo application but it seems to work only on NVIDIA cards.
Post by Ivan Brugiolo [MSFT]
You should do nothing. In Windows7, dwm.exe is designed to
'inherit' or 'fully-match' the GDI-mode that was set by CDD.
That is, the VidPn should not functionally change, even if there
will be different kind of primary pair that you will be asked to create
and scan-out.
Yeah i understood so i need not medle with currently functional vidpn.
Post by Ivan Brugiolo [MSFT]
If you debug the 2-backbuffer-shapchain DX10 application going
full-screen, you should have that code-path covered.
"2-backbuffer-shapchain"- what is this? is this an DX10 application,
if so i googled for the same but couldnt find ? can u elaborate more
on this.
Post by Ivan Brugiolo [MSFT]
You should not get a Standard-Allocation call for a user-mode owned
shapchain.
u mean to say for shapchain application i shouldnt get the Standard-
Allocation call? once i explore that application i will let u know.
Post by Ivan Brugiolo [MSFT]
I'm not sure I understand the question.
My query was in the filter driver approach for WDDM u mentioned how
come the filter driver distinguishes primary and secondary( created by
the Filter). for the secondary how it allocates the memory and
accesess the same secondary sutrface memory.
Is there any way to provide memory to the OS to draw in WDDM as it
was done earlier in xddm in DrvEnableSurface.
Post by Ivan Brugiolo [MSFT]
CDD creates two Standard Allocations per VidPn-source.
One `sharedprimary` and one `shadow`.
Dwm.exe (and any DX10/DX9/DDraw application) creates non-standard
allocations.
The idea of the `shadow` is that is is always CPU visible. That's why it
should
be created in an Aperture segment. That depends on how you described
your segments when you were asked to.
So the two standard allocations will be allocated in
GetStandardAllocation call- as per my understanding.
so as per ur explanation shadow surface will be identical ( same
contents) to the shared primary except that shadow is visible in
system memory of CPU.
what abt the STANDARDALLOCATION_GDISURFACE which is used for for GDI
hardware acceleration and Desktop Windows Manager (DWM) redirection.is
this the memory used During desktop composition.
How the Non-standard allocations created by DWM and other DX
application visible to driver? any call in specific?
where to provide the segment descriptions?
Post by Ivan Brugiolo [MSFT]
If you are wishing to go the bus-enumerated devices approach, then
the approach is viable, but, you will have some difficulty in simulating
the PCI-bus features (Interrupt and memory-mapping being some).
What is not viable is piggy-backing on
an existing WDDM driver by call interception means.
Ok what are the hardships in Bus-Enumerated devices approach, as u
mentioned earlier can u share ur Virtual Bus enumerated WDDM driver
for reference?
I am quiet confused regarding the memory mapping in WDDM, can u please
direct me to some links where i can clarify myself ? r u can give an
insight on the same.
Thanks & Regards,
Krish.
krish
2010-01-23 09:34:02 UTC
Permalink
Hi ivan,

Thanks for ur prompt reply.You are absolutely right in specifying
that only one user mode driver is required to drive all the extended
monitors, provided u have only one miniport driver driving all the
extended surfaces.

But in my case it is a special scenario where i am creating the
extended surface through my own miniport driver ( a virtual kind of
thing), so how to provide the D3D support through a usermode driver
for my extended surface.

Thanks & Regards,
krish.
Post by Ivan Brugiolo [MSFT]
You do not need a user mode driver per monitor.
The very fact that you ask the question raises the doubt if you have
minimally understood the model for which you are asked to provide a driver.
The user mode driver is loaded by a runtime
(DDraw/D3D9/DXGI/D3d10Level9, etc, etc).
It is loaded once per process per runtime instance.
The user mode driver coordinate with the runtime (through a callback
interface) things such as mode-change, present, render, resource creation
and the such.
You can have one user-mode driver piloting 6 monitors (for example),
all from the same application. This is what dwm.exe normally does,
and other multi-mon DX applications as well.
Ivan Brugiolo [MSFT]
2010-01-24 03:12:07 UTC
Permalink
There is nothing that you are extending in this case.
If you have a Virtual WDDM miniport, then your machine is in the
heterogeneous adapter scenario (assuming you have already
a physical adapter, otherwise it will be homogeneous adater).
The appropriate runtime will first create a user-mode adapter
logically matching each miniport, and, each adapter will create a device,
and then your user-mode driver will be asked
for private data that will be passed DxgkDdiCreateAllocation.
Natually there can be multiple adapters handles per process,
multiple devices per process, and multiple allocations per adapter.
One of multiple allocations can be elected to become the current
scanout surface (one at the time, off course, assuming the VidPn
configuration
and the device ownership is correct).
The mechanism used to express a miniport qualifier
for the other user mode constructs depends on the runtime:
DDraw/DX8/DX9c will use HMONITOR.
D3D9l/DXGI/D3D10/D3D11 will use Adapter-LUIDs.
At the user-mode driver level, that is not transparent to you
and you will deal with adapter handles, device handles,
resource/allocation handles and the such.
The user-mode runtimes and DxgKrnl.sys will do the mapping,
and will call your miniport appropriately.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Post by krish
Hi ivan,
Thanks for ur prompt reply.You are absolutely right in specifying
that only one user mode driver is required to drive all the extended
monitors, provided u have only one miniport driver driving all the
extended surfaces.
But in my case it is a special scenario where i am creating the
extended surface through my own miniport driver ( a virtual kind of
thing), so how to provide the D3D support through a usermode driver
for my extended surface.
Thanks & Regards,
krish.
Post by Ivan Brugiolo [MSFT]
You do not need a user mode driver per monitor.
The very fact that you ask the question raises the doubt if you have
minimally understood the model for which you are asked to provide a driver.
The user mode driver is loaded by a runtime
(DDraw/D3D9/DXGI/D3d10Level9, etc, etc).
It is loaded once per process per runtime instance.
The user mode driver coordinate with the runtime (through a callback
interface) things such as mode-change, present, render, resource creation
and the such.
You can have one user-mode driver piloting 6 monitors (for example),
all from the same application. This is what dwm.exe normally does,
and other multi-mon DX applications as well.
Ivan Brugiolo [MSFT]
2009-12-10 21:16:10 UTC
Permalink
I cannot speak on the record, [also because I no longer
work in desktop/graphics related technologies], but, there
was some talk around releasing a sample WDDM driver
based on the SoftPCI simulation framework,
once that sample would have been migrated to D3D10-11/WDDM1.1.

The general problem with releasing sources of WDDM drivers,
is the difference between WDDM 1.0 and 1.1 and the still
missing or incomplete features from DX9/DX10/DX11 both
in kernel and user mode. Many folks would have want that
the DX9 implementation based on WDDM 1.0 would never have existed.
But, at the time Vista released, there was not enough
commodity DX10 hardware available in the market.
Moreover DXGI/DX10/DX11 does not have DXVA2 support, and,
providing a long-term good example for all technologies
is largely complex exercise.


--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Post by Tim Roberts
Post by Ivan Brugiolo [MSFT]
Why do you want to provide an VidPn initial network ?
I'll take a stab at that. Because nowhere in the documentation does it say
whether or not the driver NEEDS to do so. I don't know whether you've
every read the "video present network" documentation from the point of view
of a relative newcomer, but it is as impenetrable as any technical document
I've ever read.
Post by Ivan Brugiolo [MSFT]
If you provide the sources (and their changes) and the targets
(those do not change), then the System will pick a resolution
for you. This is the comment I added to a prototype
virtual WDDM 1.1 driver I was working on end-of-summer.
Is there any possibility that the source for your driver will be released
to the huddled masses? There are no longer any good WDDM samples, and the
API is rather vast.
--
Providenza & Boekelheide, Inc.
p***@gmail.com
2015-03-17 23:05:40 UTC
Permalink
I am finding this issue any help

TRANSLATOR_BuildDriverTopologyFromOsVidPn: Topology has no paths!

and display becomes blank.

Loading...