From: Ivan Brugiolo [MSFT] on
I'm quoting myself from below:

> Full-Screen DX applications may have undefined behaviors, especially
> if they were not designed with revokable VidPn ownership in mind.
> We've seen certain games really misbehave when running in multi-mon
> scenarios when the ownership of one output was shared or kicked-out
> by one other owner.
>

It is normally a bug in the application.

The major classes of bugs are:
- applications designed for DEVICE_LOST now get PRESENT_OCCLUDED.
- applications gets into infinite-loops of device-recreation.

Those behaviors have been introduced with WDDM in Vista, and, Win7
does not change them, with the exception of enabling certain behaviors in
multi-mon.

--

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


"Shishir" <Shishir(a)discussions.microsoft.com> wrote in message
news:336046BB-D363-4097-AF63-4AA3931ECDDD(a)microsoft.com...
> Ivan, maybe you can help with the other thing our guys tried as below.
>
> Send WM_SYSCOMMAND message from user mode with SC_MONITORPOWER flag. This
> blanks the monitor, but D3D applications do not render after blanking
> happens. OpenGL apps work fine.
>
> Do you know why D3D apps do not render? Is there some way to work around
> this?
> Thanks
> Shishir
>
> "Ivan Brugiolo [MSFT]" wrote:
>
>> If you power-off the monitor, or you disconnect the monitor,
>> a couple of things can happen:
>> -1- the awareness of VidPn-Target connectivity detects the event
>> -2- the awareness of VidPn-Target connectivity does not detect the event
>>
>> -2- is pretty rare, and it requires broken implementations of VGA
>> connectors
>> (pre VESA standardization) or S-Video type of connectors.
>> -1- is the most common case.
>>
>> When -1- occurs, there are a couple of outcomes:
>> - there is a mode change
>> - there isn't a mode change
>>
>> If there is a mode-change, the system will try to find a new functional
>> VidPn,
>> and, it will go great lenghts (by even simulating a monitor) to do that.
>> We've seen scenarios where combinations of specific hardware and drivers
>> made the system connect the video-stack to the
>> disconnected-display-driver,
>> but, on average, that is very un-common.
>>
>> If there isn't a mode change, then what happens is that the device that
>> currently owns the VidPn is evicted, and, any attempt to re-acquire
>> ownership
>> will fail. The effect on applications depends on the type of
>> applications.
>> Vanilla GDI applications and/or windowed mode DX applications
>> should run un-affected.
>> Full-Screen DX applications may have undefined behaviors, especially
>> if they were not designed with revokable VidPn ownership in mind.
>> We've seen certain games really misbehave when running in multi-mon
>> scenarios when the ownership of one output was shared or kicked-out
>> by one other owner.
>>
>> Now, I would need to know exactly which scenario you are experiencing.
>> What makes you think that the applications run / do-not run unaffected ?
>> --
>>
>> --
>> 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
>>
>>
>> "Shishir" <Shishir(a)discussions.microsoft.com> wrote in message
>> news:F32E1579-0955-4308-8749-BCA9EEF199AD(a)microsoft.com...
>> > Ivan, thanks much for the quick repsonse. The result I am expecting is
>> > as
>> > if
>> > the monitor power button is turned off while windows and all the apps
>> > continue to run and render, unware that the monitor is off. Does that
>> > clarify
>> > it?
>> >
>> > Thanks
>> > Shishir
>> >
>> >
>> > "Ivan Brugiolo [MSFT]" wrote:
>> >
>> >> Can you clarify your expectations ?
>> >> Are you expecting to be able to power-down a display without
>> >> causing the Video Present Network Source not to loose its content ?
>> >>
>> >> I'm afraid that is architecturally impossible in WDDM, a
>> >> and, the fact that the machine bugchecks should convince you of that.
>> >>
>> >> If you carefully observe what happens to the displays when
>> >> the LUA/consent.exe prompt comes up, you will notice that the
>> >> screen is blanked-out. To visually mitigate that, the gamma-ramp of
>> >> the
>> >> monitor is modulated to black before the VidPn source is discarded
>> >> and a new empty one is created.
>> >> That is naturally only eye-candy to mask the problem that
>> >> primaries are always blanked-out when they are recreated and assigned
>> >> to a new Dxgk-Device elected as the current owner of the VidPn.
>> >>
>> >> At the fundamental level, the problem is the same as asking
>> >> if the memory manager of the OS could please give you
>> >> a page with its old content when you VirtualAlloc.
>> >> This would be a disclosure of content.
>> >> Also, even if you could get back some pages, there would
>> >> be no guarantee that the unchanged content is usable (because of
>> >> different swizzling formats, incompatible requirements of a scanout
>> >> source
>> >> and a scanout target when a new display comes-up, etc, etc).
>> >>
>> >> --
>> >>
>> >> --
>> >> 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
>> >>
>> >>
>> >> "Shishir" <Shishir(a)discussions.microsoft.com> wrote in message
>> >> news:EEC8C807-7131-49F6-AF4D-20F66E15D455(a)microsoft.com...
>> >> > Hello, we are trying to programmtically blank display for a use case
>> >> > we
>> >> > have.
>> >> >
>> >> > This used to work in XP with the OCTL
>> >> > “IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE”. But this is deprecated
>> >> > in
>> >> > Vista
>> >> > and win7.
>> >> >
>> >> > Other methods of hooking, attaching a device to monitor stack etc.
>> >> > have
>> >> > been
>> >> > tried but they either blank the d3d surface as well, or bugcheck the
>> >> > system.
>> >> >
>> >> > The Wmi Provider for CIM_DesktopMonitor doesn't help as its
>> >> > underlying
>> >> > implementation in IRP_MJ_SYSTEM_CONTROL handler for monitor driver
>> >> > is
>> >> > not
>> >> > provided by Microsoft as of now.
>> >> >
>> >> > Trying to do it using Dxgi provided powerstate function either
>> >> > crashes
>> >> > or
>> >> > with help, balnks for a short time but turns it back on again.
>> >> >
>> >> > We would like to get a supported means of doing this. Appreciate if
>> >> > Micorosft could help.
>> >> >
>> >> > Thanks
>> >> > Shishir Pardikar
>> >> > Technology Strategist,
>> >> > Citrix Systems Inc., shishir.pardikar(a)citrix.com
>> >> > 425-895-4765 (O)
>> >> >
>> >> .
>> >>
>> .
>>