From: Ivan Brugiolo [MSFT] on
>
> 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" <drvkrish99(a)gmail.com> wrote in message
news:9082da8e-3200-4b16-a4d1-aa59459b7872(a)v7g2000pro.googlegroups.com...
> On Dec 10, 11:20 am, Tim Roberts <t...(a)probo.com> wrote:
>> "Ivan Brugiolo [MSFT]" <ivanb...(a)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...(a)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(a)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.

From: krish on
On Dec 11, 2:30 am, "Ivan Brugiolo [MSFT]"
<ivanb...(a)online.microsoft.com> wrote:
> > 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 athttp://www.microsoft.com/info/cpyright.htm
>
> "krish" <drvkris...(a)gmail.com> wrote in message
>
> news:9082da8e-3200-4b16-a4d1-aa59459b7872(a)v7g2000pro.googlegroups.com...
>
> > On Dec 10, 11:20 am, Tim Roberts <t...(a)probo.com> wrote:
> >> "Ivan Brugiolo [MSFT]" <ivanb...(a)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...(a)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(a)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.

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 drvkrish99(a)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.
From: Ivan Brugiolo [MSFT] on

> 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" <drvkrish99(a)gmail.com> wrote in message
news:069df59c-963b-4d44-9e72-de7d7b8ba662(a)13g2000prl.googlegroups.com...
> On Dec 11, 2:30 am, "Ivan Brugiolo [MSFT]"
> <ivanb...(a)online.microsoft.com> wrote:
>> > 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
>> athttp://www.microsoft.com/info/cpyright.htm
>>
>> "krish" <drvkris...(a)gmail.com> wrote in message
>>
>> news:9082da8e-3200-4b16-a4d1-aa59459b7872(a)v7g2000pro.googlegroups.com...
>>
>> > On Dec 10, 11:20 am, Tim Roberts <t...(a)probo.com> wrote:
>> >> "Ivan Brugiolo [MSFT]" <ivanb...(a)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...(a)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(a)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.
>
> 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 drvkrish99(a)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.

From: krish on

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
From: krish on

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