Prev: 32 bit process & 64 bit driver, 32/64 bit pointer?
Next: INF Questions ()
From: heejune on 11 Feb 2010 21:59
hello, what I'm about to to is a developing WDDM driver to support
external device such as USB monitor. So I started researching through
debugging with R200 samples to understand display framework, and seems
quite confusing.

here's few questions.

1. as far as I understood, to support multimonitors, let's say we've
got two monitors and to use another as extended monitor, WDDM display
driver should build multiple present paths(here two paths, for
example). So I suspected at first that display driver had to create
and add present path for newly attached monitor with
pfnCreateNewPathInfo & pfnAddPath during
DxgkDdiRecommendFunctionalVidPn or DxgkDdiEnumVidPnCofuncModality got
called. But while debugging I couldn't find out anything mentioned
above actually happened.. But I saw present path was built as two, so
does that mean VidPN manager actually build another present path
instead of WDDM driver?

2. well, the approach way that I thought to implement this extern
monitor support, is developing WDDM filter which deceives dxgkrnl to
have another child and make another present path for it. I'd like to
hear others thought or tips how this does go work alright.

Thank you.
From: Ivan Brugiolo [MSFT] on 12 Feb 2010 04:48
You should research the posts on this forum on
the subject over the last few months, because the topic was discussed at
length.

-1-
You should not build anything in the miniport.
The user will build a video-present-network by virtue of using `desk.cpl`,
Win-P, or any combination of SetDisplayConfig or ChangeDisplaySettings.
The role of the miniport is to veto any topology that is not compatible
with internal constrains, either directly or by removing non co-functional
modalities from the topology.

-2-
Filtering DxgKrnl is not supported, and not recommended.
You are in the undocumented land, and, the fact that some product
with some market success use that path is not of any encouragement
to that route.

--
--
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"heejune" <heejune(a)gmail.com> wrote in message
news:60d50439-339d-4b79-ae08-85ccf300d39c(a)w27g2000pre.googlegroups.com...
> hello, what I'm about to to is a developing WDDM driver to support
> external device such as USB monitor. So I started researching through
> debugging with R200 samples to understand display framework, and seems
> quite confusing.
>
> here's few questions.
>
> 1. as far as I understood, to support multimonitors, let's say we've
> got two monitors and to use another as extended monitor, WDDM display
> driver should build multiple present paths(here two paths, for
> example). So I suspected at first that display driver had to create
> and add present path for newly attached monitor with
> pfnCreateNewPathInfo & pfnAddPath during
> DxgkDdiRecommendFunctionalVidPn or DxgkDdiEnumVidPnCofuncModality got
> called. But while debugging I couldn't find out anything mentioned
> above actually happened.. But I saw present path was built as two, so
> does that mean VidPN manager actually build another present path
> instead of WDDM driver?
>
> 2. well, the approach way that I thought to implement this extern
> monitor support, is developing WDDM filter which deceives dxgkrnl to
> have another child and make another present path for it. I'd like to
> hear others thought or tips how this does go work alright.
>
> Thank you.

From: heejune on 16 Feb 2010 19:32
yes, that posts you and other usenet fellows had here was really
valuable resource and good start point. I appreciate your answer
again.

On Feb 12, 6:48 pm, "Ivan Brugiolo [MSFT]"
<ivanb...(a)online.microsoft.com> wrote:
> You should research the posts on this forum on
> the subject over the last few months, because the topic was discussed at
> length.
>
> -1-
> You should not build anything in the miniport.
> The user will build a video-present-network by virtue of using   `desk.cpl`,
> Win-P, or any combination of SetDisplayConfig or ChangeDisplaySettings.
> The role of the miniport is to veto any topology that is not compatible
> with internal constrains, either directly or by removing non co-functional
> modalities from the topology.
>
> -2-
> Filtering DxgKrnl is not supported, and not recommended.
> You are in the undocumented land, and, the fact that some product
> with some market success use that path is not of any encouragement
> to that route.
>
> --
> --
> This posting is provided "As Is" with no warranties, and confers no rights.
> Use of included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm
>
> "heejune" <heej...(a)gmail.com> wrote in message
>
> news:60d50439-339d-4b79-ae08-85ccf300d39c(a)w27g2000pre.googlegroups.com...
>
>
>
> > hello, what I'm about to to is a developing WDDM driver to support
> > external device such as USB monitor. So I started researching through
> > debugging with R200 samples to understand display framework, and seems
> > quite confusing.
>
> > here's few questions.
>
> > 1. as far as I understood, to support multimonitors, let's say we've
> > got two monitors and to use another as extended monitor, WDDM display
> > driver should build multiple present paths(here two paths, for
> > example). So I suspected at first that display driver had to create
> > and add present path for newly attached monitor with
> > pfnCreateNewPathInfo & pfnAddPath during
> > DxgkDdiRecommendFunctionalVidPn or DxgkDdiEnumVidPnCofuncModality got
> > called. But while debugging I couldn't find out anything mentioned
> > above actually happened.. But I saw present path was built as two, so
> > does that mean VidPN manager actually build another present path
> > instead of WDDM driver?
>
> > 2. well, the approach way that I thought to implement this extern
> > monitor support, is developing WDDM filter which deceives dxgkrnl to
> > have another child and make another present path for it. I'd like to
> > hear others thought or tips how this does go work alright.
>
> > Thank you.

From: Tim Roberts on 18 Feb 2010 02:27
"Ivan Brugiolo [MSFT]" <ivanbrug(a)online.microsoft.com> wrote:
>
>-2-
>Filtering DxgKrnl is not supported, and not recommended.
>You are in the undocumented land, and, the fact that some product
>with some market success use that path is not of any encouragement
>to that route.

Although this is the company line, the fact is there are reasonable things
users want to do that simply cannot be done any other way.

I know quite a number of companies are waiting with bated breath for any
hint of support for WDDM mirroring/shadowing.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Ivan Brugiolo [MSFT] on 18 Feb 2010 04:35
Given that Mirroring/Shadowing is not supported in WDDM 1.0/1.1
(and it is not supported for Microsoft itself, since
Remote-Desktop-Multimon,
Live-Mesh, Desktop-Sharing and Live-Meeting, etc etc,
all suffer from the same limitations), the only other supported route is
XPDM.
When XPDM will be architecturally removed, rest reassured that
mirroring/shadowing
possibly with a different driver model, will be added back to the WDDM path.

And, it is more likely that XPDM compliant solutions
will be made work in the new model more than unsupported solutions will be.

--

--
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" <timr(a)probo.com> wrote in message
news:8qqpn5l0tefthhb6dbi7a1ctevaoirl1d2(a)4ax.com...
> "Ivan Brugiolo [MSFT]" <ivanbrug(a)online.microsoft.com> wrote:
>>
>>-2-
>>Filtering DxgKrnl is not supported, and not recommended.
>>You are in the undocumented land, and, the fact that some product
>>with some market success use that path is not of any encouragement
>>to that route.
>
> Although this is the company line, the fact is there are reasonable things
> users want to do that simply cannot be done any other way.
>
> I know quite a number of companies are waiting with bated breath for any
> hint of support for WDDM mirroring/shadowing.
> --
> Tim Roberts, timr(a)probo.com
> Providenza & Boekelheide, Inc.

 | 
Pages: 1
Prev: 32 bit process & 64 bit driver, 32/64 bit pointer?
Next: INF Questions ()