WDDM Driver Vidpn implementation.

[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.

[Ivan Brugiolo [MSFT]]

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 => 1024x768@A8R8G8B8)
Target: N/A

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

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

Step 6 - Pivot = D3DKMDT_EPT_ROTATION
Paths: (0 <-> 0) (IdentityScaling,UnRotated)
(1 <-> 4)
(2 <-> 3)
Source: (0 => 1024x768@A8R8G8B8)
Target: (0 => 1024x768@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

"krish" <drvkr...@gmail.com> wrote in message
news:e9d6f77e-62bf-49d5...@v15g2000prn.googlegroups.com...

[Tim Roberts]

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote:
>
>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.

>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, ti...@probo.com
Providenza & Boekelheide, Inc.

[krish]

On Dec 10, 11:20 am, Tim Roberts <t...@probo.com> wrote:
> "Ivan Brugiolo [MSFT]" <ivanb...@online.microsoft.com> wrote:
>
>
>
> >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.
> --

> Tim Roberts, t...@probo.com
> 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)
> Source: (0 => 1024x768@A8R8G8B8)
> 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]]

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

"Tim Roberts" <ti...@probo.com> wrote in message
news:3k41i51t1ugeb38ae...@4ax.com...

[Ivan Brugiolo [MSFT]]

>
> 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.

>
> 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.

> 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.

> 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.

>
> 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.

>
> 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

"krish" <drvkr...@gmail.com> wrote in message

news:9082da8e-3200-4b16...@v7g2000pro.googlegroups.com...

[krish]

On Dec 11, 2:30 am, "Ivan Brugiolo [MSFT]"

> "krish" <drvkris...@gmail.com> wrote in message

Thanks for ur support. I am replying after implementing ur
suggestions.

> 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.

> 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

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
wish to u can mail me at drvkr...@gmail.com.

> > 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.

> 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.

> 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

> 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.

> 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]]

> 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.

> 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.

> 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.

> 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.

> 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

"krish" <drvkr...@gmail.com> wrote in message

news:069df59c-963b-4d44...@13g2000prl.googlegroups.com...

[krish]

Hi Ivan,

> 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?

> 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?

> 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]

Hi Ivan,

> 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?

> 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?

> 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.

[Ivan Brugiolo [MSFT]]

> 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.

> 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.

> 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.

> 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.

> 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

"krish" <drvkr...@gmail.com> wrote in message

news:49c20542-f35a-4f16...@n16g2000yqm.googlegroups.com...

[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.

> 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.

> 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.

> 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.

> 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.
>

> 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.

> 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?

> 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]]

>
> 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.

> "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 at
http://www.microsoft.com/info/cpyright.htm

"krish" <drvkr...@gmail.com> wrote in message

news:3fa7aa9f-1476-4f8e...@d20g2000yqh.googlegroups.com...

[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.

> 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

> "krish" <drvkris...@gmail.com> wrote in message

[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.

--

--
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

"krish" <drvkr...@gmail.com> wrote in message

news:a56387d2-31e2-4e9e...@c4g2000yqa.googlegroups.com...

[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.

[Ivan Brugiolo [MSFT]]

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

"krish" <drvkr...@gmail.com> wrote in message

news:bba811b0-5e7f-4d60...@k35g2000yqb.googlegroups.com...

[psh...@gmail.com]

I am finding this issue any help

TRANSLATOR_BuildDriverTopologyFromOsVidPn: Topology has no paths!

and display becomes blank.