Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

KMDF driver for turning off the displays

=?UTF-8?B?U3ppbMOhcmQgU3phbMOza2k=?==?UTF-8?B?U3ppbMOhcmQgU3phbMOza2k=?= Member - All Emails Posts: 4
Hi All,

Doron Holan forwarded me to this forum to ask my question here. I hope you can help me with it.

I?m writing a KMDF driver in order to be able to turn off the displays properly from a user-mode application and I?d like you to ask you whether my method is correct or not. What I do is actually get the device interfaces with IoGetDeviceInterfaces for GUID_DEVINTERFACE_DISPLAY_ADAPTER, iterate over them, get the device object pointers to them with IoGetDeviceObjectPointer so that I can build an I/O control request with IoBuildDeviceIoControlRequest and send it to them. I know that IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE is deprecated, but I don?t know what IRP I should send.

Could you help me out with this?

Thank you in advance!

Regards,
Szil?rd

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,805
    >to be able to turn off the displays properly
    >from a user-mode application

    Can you explain further, please, what you specifically mean by "turn off the displays properly"?

    You want to idle the displays in low power state?

    You want to BLANK the display (set it all black) and later turn it back to the Windows desktop?

    Can you please tell us more, so we can try to help you?

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,805
    >Can you please tell us more, so we can try to help you?

    Also, I might add, it's not simple to do this... and certainly not in a way that'll make ANY application that might happen to be running on ANY display (in a multi-display system) happy. Ordinary GUI apps might work fine, but full-screen stuff or other weirdo graphics stuff, not so much.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • =?UTF-8?B?U3ppbMOhcmQgU3phbMOza2k=?==?UTF-8?B?U3ppbMOhcmQgU3phbMOza2k=?= Member - All Emails Posts: 4
    Hi Peter,


    Thanks for your reply!


    I would either like to put the displays in D3 power state or just blank
    them. My goal is to be able to grab the desktop image of computer A and
    send it over to computer B, meanwhile the user in front of computer A would
    be facing a black screen.


    Szilard

    2018-07-10 23:21 GMT+02:00 xxxxx@osr.com :

    > >Can you please tell us more, so we can try to help you?
    >
    > Also, I might add, it's not simple to do this... and certainly not in a
    > way that'll make ANY application that might happen to be running on ANY
    > display (in a multi-display system) happy. Ordinary GUI apps might work
    > fine, but full-screen stuff or other weirdo graphics stuff, not so much.
    >
    > Peter
    > OSR
    > @OSRDrivers
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,679
    On Jul 10, 2018, at 3:02 PM, xxxxx@gmail.com wrote:
    >
    > I would either like to put the displays in D3 power state or just blank them. My goal is to be able to grab the desktop image of computer A and send it over to computer B, meanwhile the user in front of computer A would be facing a black screen.

    I'm reading between the lines here, but given your description, are you hoping to have computer A's desktop continue to be fully operational, but grab the image periodically and send it to computer B while computer A shows a black screen? If so, that's simply impossible. If you put the graphics card in computer A into D3, then it isn't going to respond to any more drawing requests.

    There are some pretty significant security considerations here. You can't steal a user's active display without his active permission.

    You need to take a look at the mechanisms that the current products use. The VNC products copy the live desktop, which must therefore remain visible. The RDP products use a separate display driver drawing into a memory buffer, but they lock the workstation.

    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • =?UTF-8?B?U3ppbMOhcmQgU3phbMOza2k=?==?UTF-8?B?U3ppbMOhcmQgU3phbMOza2k=?= Member - All Emails Posts: 4
    Hi Tim,

    It’s not the graphics card I’d like to put into D3 but the monitors.

    Regards,
    Szilard

    2018. júl. 11. dátummal, 8:42 időpontban xxxxx@probo.com írta:

    >> On Jul 10, 2018, at 3:02 PM, xxxxx@gmail.com wrote:
    >>
    >> I would either like to put the displays in D3 power state or just blank them. My goal is to be able to grab the desktop image of computer A and send it over to computer B, meanwhile the user in front of computer A would be facing a black screen.
    >
    > I'm reading between the lines here, but given your description, are you hoping to have computer A's desktop continue to be fully operational, but grab the image periodically and send it to computer B while computer A shows a black screen? If so, that's simply impossible. If you put the graphics card in computer A into D3, then it isn't going to respond to any more drawing requests.
    >
    > There are some pretty significant security considerations here. You can't steal a user's active display without his active permission.
    >
    > You need to take a look at the mechanisms that the current products use. The VNC products copy the live desktop, which must therefore remain visible. The RDP products use a separate display driver drawing into a memory buffer, but they lock the workstation.
    > —
    > Tim Roberts, xxxxx@probo.com
    > Providenza & Boekelheide, Inc.
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at:
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,679
    xxxxx@gmail.com wrote:
    >
    > It’s not the graphics card I’d like to put into D3 but the monitors.

    You can't do that without the involvement of the graphics driver,
    because the signals all get sent through the graphics card.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • R0b0t1R0b0t1 Member - All Emails Posts: 132
    On Wed, Jul 11, 2018 at 3:21 PM, xxxxx@probo.com <xxxxx@lists.osr.com> wrote:
    > xxxxx@gmail.com wrote:
    >>
    >> It’s not the graphics card I’d like to put into D3 but the monitors.
    >
    > You can't do that without the involvement of the graphics driver,
    > because the signals all get sent through the graphics card.
    >

    On Linux at least the power state of a graphics device and the state
    of the graphics device's outputs are not linked. The wording of the
    IOCTL could be interpreted to mean the same.
    "IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE," as in "set video device
    output device power state."

    If this does do what OP wants it is unfortunate it is deprecated, or
    if not, unfortunate that there seems to be no way to do as they want.

    On Windows especially I have had problems keeping some applications
    active while not drawing. It may be possible turning the screen off
    generates similar issues. Despite the graphics card still rendering,
    the OS might keep in mind that the main display is off and stop asking
    applications to render.

    Cheers,
    R0b0t1
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,679
    xxxxx@gmail.com wrote:
    >
    > It’s not the graphics card I’d like to put into D3 but the monitors.

    The last person who asked about this, in 2011, noted that LogMeIn does
    the same function.  It does so by replacing the in-box monitor driver,
    monitor.sys, with one of their own.

    https://www.osronline.com/showthread.cfm?link=214666

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,271
    If the monitors are in d3 the graphics card will stop using them as active
    displays. As a simple experiment, push the power button on an active
    display. You could put a black window in front of all the other windows on
    each display. It is an awful hacky thing to do, but it seems to be waht you
    want.

    Mark Roddy


    On Wed, Jul 11, 2018 at 4:02 AM xxxxx@gmail.com <
    xxxxx@lists.osr.com> wrote:

    > Hi Tim,
    >
    > It’s not the graphics card I’d like to put into D3 but the monitors.
    >
    > Regards,
    > Szilard
    >
    > 2018. júl. 11. dátummal, 8:42 időpontban xxxxx@probo.com <
    > xxxxx@lists.osr.com> írta:
    >
    > On Jul 10, 2018, at 3:02 PM, xxxxx@gmail.com
    > wrote:
    >
    >
    > I would either like to put the displays in D3 power state or just blank
    > them. My goal is to be able to grab the desktop image of computer A and
    > send it over to computer B, meanwhile the user in front of computer A would
    > be facing a black screen.
    >
    >
    > I'm reading between the lines here, but given your description, are you
    > hoping to have computer A's desktop continue to be fully operational, but
    > grab the image periodically and send it to computer B while computer A
    > shows a black screen? If so, that's simply impossible. If you put the
    > graphics card in computer A into D3, then it isn't going to respond to any
    > more drawing requests.
    >
    > There are some pretty significant security considerations here. You can't
    > steal a user's active display without his active permission.
    >
    > You need to take a look at the mechanisms that the current products use.
    > The VNC products copy the live desktop, which must therefore remain
    > visible. The RDP products use a separate display driver drawing into a
    > memory buffer, but they lock the workstation.
    > —
    > Tim Roberts, xxxxx@probo.com
    > Providenza & Boekelheide, Inc.
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,679
    xxxxx@gmail.com wrote:
    >
    > If the monitors are in d3 the graphics card will stop using them as
    > active displays. As a simple experiment, push the power button on an
    > active display. You could put a black window in front of all the other
    > windows on each display. It is an awful hacky thing to do, but it
    > seems to be waht you want.

    Not if I understand his concept.  I believe he wants the desktop to be
    updated and generated as usual, so he can grab a copy and send it to
    another computer.  He just doesn't want it to be visible at the
    originating machine.

    It's slimy, and it's a huge security hole.  Imagine if a hacker got a
    hold of this.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • R0b0t1R0b0t1 Member - All Emails Posts: 132
    On Wed, Jul 11, 2018 at 6:13 PM, xxxxx@probo.com <xxxxx@lists.osr.com> wrote:
    > xxxxx@gmail.com wrote:
    >>
    >> If the monitors are in d3 the graphics card will stop using them as
    >> active displays. As a simple experiment, push the power button on an
    >> active display. You could put a black window in front of all the other
    >> windows on each display. It is an awful hacky thing to do, but it
    >> seems to be waht you want.
    >
    > Not if I understand his concept. I believe he wants the desktop to be
    > updated and generated as usual, so he can grab a copy and send it to
    > another computer. He just doesn't want it to be visible at the
    > originating machine.
    >
    > It's slimy, and it's a huge security hole. Imagine if a hacker got a
    > hold of this.
    >

    There's a myriad valid reasons to do this, most of which we don't even
    know yet. Making it impossible because of "hackers" is pointless.

    If you actually want to make any progress in this regard, try to get
    API functions like CreateRemoteThread (start a thread *in another
    process?*) removed, and enforce process boundaries as strictly as user
    boundaries are enforced.

    I can just trivially debug any program you are running to scrape info
    out of it. Should we get rid of debuggers?

    Cheers,
    R0b0t1
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 131
    This discussion made me curious.
    So we just tried this "D3 approach".
    We took the DXGI Desktop Duplication API Microsoft sample.
    Removed the rendering part and redirected the duplicated content
    (to another machine over the network).
    Would it capture any screen updates during monitor D3?

    The result:
    Some Windows (drawn by GDI?) seem to be updating even while the monitor is off
    (e.g. system clock application with second hand).
    Some Windows (drawn by DirectX?) seem NOT to be updating while the monitor is off
    (e.g. system clock display in task bar, video player, etc.).

    Thus the long story can be cut very short:
    In general, this "D3 approach" is useless.
    In certain special cases, it might be applicable (if only the content of a specific subset of all Windows is needed).

    PS: Of course the "blackout approach" is useless, too (as long as the covered content needs to be retrieved at the same time).

    Marcel Ruedinger

    datronicsoft
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,271
    yeah it was entirely unclear what the actual intentions were. If the op
    just wanted to black out the screens, that's easy.

    Mark Roddy


    On Thu, Jul 12, 2018 at 5:41 AM xxxxx@datronic.de wrote:

    > This discussion made me curious.
    > So we just tried this "D3 approach".
    > We took the DXGI Desktop Duplication API Microsoft sample.
    > Removed the rendering part and redirected the duplicated content
    > (to another machine over the network).
    > Would it capture any screen updates during monitor D3?
    >
    > The result:
    > Some Windows (drawn by GDI?) seem to be updating even while the monitor is
    > off
    > (e.g. system clock application with second hand).
    > Some Windows (drawn by DirectX?) seem NOT to be updating while the monitor
    > is off
    > (e.g. system clock display in task bar, video player, etc.).
    >
    > Thus the long story can be cut very short:
    > In general, this "D3 approach" is useless.
    > In certain special cases, it might be applicable (if only the content of a
    > specific subset of all Windows is needed).
    >
    > PS: Of course the "blackout approach" is useless, too (as long as the
    > covered content needs to be retrieved at the same time).
    >
    > Marcel Ruedinger
    >
    > datronicsoft
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: <
    > http://www.osronline.com/showlists.cfm?list=ntdev>;
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • =?UTF-8?B?U3ppbMOhcmQgU3phbMOza2k=?==?UTF-8?B?U3ppbMOhcmQgU3phbMOza2k=?= Member - All Emails Posts: 4
    Hi All,

    Thanks for dealing with my issue!

    In fact it's not putting the monitors into D3 that is necessary for me, blacking out the screens would perfectly suit my needs. The only problem with this is that if I put black full-screen windows on each display (GDI or DirectX), the Desktop Duplication API grabs them too, so the user at computer B is left with black screens as well. That's the reason I chose to stick with the D3 power state and try to put the monitors into it.

    Any suggestions are welcome!

    Regards,
    Szilard

    2018. júl. 12. dátummal, 13:28 időpontban xxxxx@gmail.com írta:

    > yeah it was entirely unclear what the actual intentions were. If the op just wanted to black out the screens, that's easy.
    >
    > Mark Roddy
    >
    >
    >> On Thu, Jul 12, 2018 at 5:41 AM xxxxx@datronic.de wrote:
    >> This discussion made me curious.
    >> So we just tried this "D3 approach".
    >> We took the DXGI Desktop Duplication API Microsoft sample.
    >> Removed the rendering part and redirected the duplicated content
    >> (to another machine over the network).
    >> Would it capture any screen updates during monitor D3?
    >>
    >> The result:
    >> Some Windows (drawn by GDI?) seem to be updating even while the monitor is off
    >> (e.g. system clock application with second hand).
    >> Some Windows (drawn by DirectX?) seem NOT to be updating while the monitor is off
    >> (e.g. system clock display in task bar, video player, etc.).
    >>
    >> Thus the long story can be cut very short:
    >> In general, this "D3 approach" is useless.
    >> In certain special cases, it might be applicable (if only the content of a specific subset of all Windows is needed).
    >>
    >> PS: Of course the "blackout approach" is useless, too (as long as the covered content needs to be retrieved at the same time).
    >>
    >> Marcel Ruedinger
    >>
    >> datronicsoft
    >>
    >> ---
    >> NTDEV is sponsored by OSR
    >>
    >> Visit the list online at:
    >>
    >> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    >> Details at
    >>
    >> To unsubscribe, visit the List Server section of OSR Online at
    > --- NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,805
    In case you haven't seen it, please refer to this venerable thread in which one of the (at the time) WDDM devs discusses this exact request from a dude at Citrix:

    <http://www.adras.com/Display-Blanking-in-Windows-7.t15654-117.html>;

    There's a lot in this that's super interesting.

    >There's a myriad valid reasons to do this

    Sure... but...

    >it's a huge security hole

    This is exactly the point.

    In short... what the OP wants to do is not supported by Windows *by design* and, to put a finer point on it, support for doing exactly what he wants (the IOCTL previously mentioned) was intentionally removed because it created a security problem.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 131
    Super interesting and correct. Let me just emphasize one detail which might easily be overlooked:
    The (at the time) WDDM dev discussed it from the point of view of the WDDM driver developer!
    Thus it can clearly be seen that not even the WDDM display driver itself holds any screen content while the video output is powered down.

    Indeed there is not much left to suggest to the OP.
    Windows simply doesn't support such a thing.
    If this answer isn't appreciated, then it could also be paraphrased in many other ways:
    - When screen content is destroyed (or blacked out), then it cannot be grabbed any more.
    - Desktop Duplication API is exactly doing what it says: Duplicate.
    - Etc.etc.etc.

    Marcel Ruedinger

    datronicsoft
  • R0b0t1R0b0t1 Member - All Emails Posts: 132
    On Thu, Jul 12, 2018 at 9:54 AM, xxxxx@osr.com <xxxxx@lists.osr.com> wrote:
    > In case you haven't seen it, please refer to this venerable thread in which one of the (at the time) WDDM devs discusses this exact request from a dude at Citrix:
    >
    > <http://www.adras.com/Display-Blanking-in-Windows-7.t15654-117.html>;
    >
    > There's a lot in this that's super interesting.
    >

    Thank you, I will read it as well because I am interested in the solution.

    >>There's a myriad valid reasons to do this
    >
    > Sure... but...
    >
    >>it's a huge security hole
    >
    > This is exactly the point.
    >

    Alright, like I just pointed out, CreateRemoteThread and debuggers are
    *also* huge security holes. Why allow them?

    > In short... what the OP wants to do is not supported by Windows *by design* and, to put a finer point on it, support for doing exactly what he wants (the IOCTL previously mentioned) was intentionally removed because it created a security problem.
    >

    This is perhaps the strangest "security problem" I have read about.
    How is it actually a problem?

    It reminds me of all those CVEs that get filed for null pointer dereferences.


    On Thu, Jul 12, 2018 at 10:34 AM, xxxxx@datronic.de <xxxxx@lists.osr.com> wrote:
    > Super interesting and correct. Let me just emphasize one detail which might easily be overlooked:
    > The (at the time) WDDM dev discussed it from the point of view of the WDDM driver developer!
    > Thus it can clearly be seen that not even the WDDM display driver itself holds any screen content while the video output is powered down.
    >
    > Indeed there is not much left to suggest to the OP.
    > Windows simply doesn't support such a thing.
    > If this answer isn't appreciated, then it could also be paraphrased in many other ways:
    > - When screen content is destroyed (or blacked out), then it cannot be grabbed any more.
    > - Desktop Duplication API is exactly doing what it says: Duplicate.
    > - Etc.etc.etc.
    >

    So it looks like what I was concerned about in userspace is actually
    done at the kernel level. If the display is inactive then no drawing
    is done. So the solution, if any, would need to blackhole a fake
    display output that simply doesn't drive a real monitor.


    To elaborate on why this is problematic - this is one of the things
    that is keeping multisession logins and good remote management at bay.
    There is some financial interest for Microsoft in this; per their
    license, you should technically be buying a terminal services license
    and associated client licenses. You would also be in violation of
    their license if you, for example, installed a VNC program to get
    around the lack of remote desktop in Home versions of Windows.

    But no one cares. Portions of the Microsoft license have been struct
    down. Microsoft is also working on supporting SSH and having huge
    problems due to its own code design - to work as people would expect
    the SSH daemon would need to log people in, but if they implement this
    *the right way* per their own instructions then people are left with a
    useless program they can't use unless they spend multiple thousands of
    dollars or hack the terminal services DLL.

    Cheers,
    R0b0t1
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,805
    <quote>
    CreateRemoteThread and debuggers are
    *also* huge security holes.
    </quote>

    Are you being deliberately argumentative, or do you actually not understand that both the things you listed require SE_DEBUG_NAME privilege for a process that's not your own?

    <quote>
    To elaborate on why this is problematic - this is one of the things
    that is keeping multisession logins and good remote management at bay.
    ...
    </quote>

    Save your baseless and emotional anti-Windows rants, please, for a site where the management is sympathetic to your cause, shares your particular brand of religious zeal, and/or where other *nix fanboys congregate.

    This particular forum would fall into none of those categories.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tiago_CastroTiago_Castro Member - All Emails Posts: 6
    As Tim suggested I also have seen commercial products do this through a custom monitor driver, so it is possible...
  • R0b0t1R0b0t1 Member - All Emails Posts: 132
    On Thu, Jul 12, 2018 at 11:31 AM, xxxxx@osr.com <xxxxx@lists.osr.com> wrote:
    > <quote>
    > CreateRemoteThread and debuggers are
    > *also* huge security holes.
    > </quote>
    >
    > Are you being deliberately argumentative, or do you actually not understand that both the things you listed require SE_DEBUG_NAME privilege for a process that's not your own?
    >

    My point is to make you aware of a flaw in Microsoft's logic, yes.
    Cargo cult security is obnoxious and makes my life harder on the
    daily.

    So it was worth gating them behind a privilege - why? They're
    potentially insecure and even *if* a special permission is required in
    practice I am able to debug every program in a user's session once I
    can run code in it. Basically every OS has this "problem" and it makes
    irrelevant the vast majority of security concerns about X, Y, or Z
    because fixing those does not fix the general lack of intrauser
    permission separation.

    It's best to just remove them. Despite any purpose they might serve I
    could exploit their existence.

    > <quote>
    > To elaborate on why this is problematic - this is one of the things
    > that is keeping multisession logins and good remote management at bay.
    > ...
    > </quote>
    >
    > Save your baseless and emotional anti-Windows rants, please, for a site where the management is sympathetic to your cause, shares your particular brand of religious zeal, and/or where other *nix fanboys congregate.
    >
    > This particular forum would fall into none of those categories.
    >

    This will be my last post on the matter, sir. I apologize. As I am not
    very smart I sometimes say things I should not.

    I do not intend this to be one OS versus the other. It is more along
    the lines of "this company sold a broken product and is attempting to
    disclaim liability for it" with a touch of "this company is now being
    hoist by their own petard."

    Cheers,
    R0b0t1
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 131
    @Tiago Castro

    Question 1:
    The commercial products you have seen - which Windows version are they running on?
    Is it possible that you have seen them run on Windows 7 with an old XPDM display driver active?
    This environment only supports AERO OFF glass transparency theme disabled.
    According to the information above, the "D3 approach" might indeed work in such an environment.

    Question 2:
    The commercial products you have seen - if running on Windows 10 at all - are they maybe showing selected Windows content only instead of showing the whole desktop?

    Question 3:
    If none of the questions above can be answered with yes, then could you name these products?

    Marcel Ruedinger

    datronicsoft
  • Tiago_CastroTiago_Castro Member - All Emails Posts: 6
    @Marcel Ruedinger

    Q1. Windows 10

    Q2. Shows the whole desktop

    Q3. Not sure if it's allowed to share products as per forum rules but I can pm you if you like?
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 131
    I thought it is OK as long as it is no advertisement.
    But agreed: Better to get in touch by private mail.
    You'll easily find my email contact data on our datronicsoft website.
    Looking forward to inspect the product and see what it is really doing :-)

    Marcel Ruedinger

    datronicsoft
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,805
    > I thought it is OK as long as it is no advertisement

    It definitely IS OK... as long as it's not some sort of commercial or advocacy for a product.

    The idea isn't to not mention the names of products. The idea IS to not having people try to sell or advertise products via this forum.

    In any case, thank you very much for your consideration for the rules.

    Carry on...

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tiago_CastroTiago_Castro Member - All Emails Posts: 6
    Alright then, it's TeamViewer.
    It's not enabled by default, you have to fiddle around the settings, and it'll install a driver for you.

    Once it's enable you can connect and the monitor will be off (can't remember if it actually turns off the display or if it just shows dark colour)
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 131
    Isn't TeamViewer just using "out of the box" standard Windows functionality RDP (Remote Desktop Protocol) to support this scenario?

    Can't exactly the same functionality be achieved with two plain Windows machines?
    Run RDP client software on one machine (client).
    Then connect the client to the other machine (server) via RDP.
    Isn't the Server machine console user locked out while RDP client is active?

    This approach could possibly be a valid suggestion for the OP:
    - Just use or write a RDP client software.
    - Write a monitor driver (Power Policy Owner) which puts the server's locked out console Window monitor to sleep while a RDP client is connected (no need to capture the locked out console monitor content anyway).

    Marcel Ruedinger

    datronicsoft
  • Nathan_KiddNathan_Kidd Member - All Emails Posts: 13
    On 13/07/18 03:07 PM, xxxxx@datronic.de wrote:
    > Isn't TeamViewer just using "out of the box" standard Windows functionality RDP (Remote Desktop Protocol) to support this scenario?
    >
    > Can't exactly the same functionality be achieved with two plain Windows machines?
    > Run RDP client software on one machine (client).
    > Then connect the client to the other machine (server) via RDP.
    > Isn't the Server machine console user locked out while RDP client is active?
    >
    > This approach could possibly be a valid suggestion for the OP:
    > - Just use or write a RDP client software.
    > - Write a monitor driver (Power Policy Owner) which puts the server's locked out console Window monitor to sleep while a RDP client is connected (no need to capture the locked out console monitor content anyway).

    In my experience, though RDP can connect to "Desktop" OSes (vs
    "Server"), you're then forced to deal with that protocol which probably
    half defeats the purpose of the alternate remote desktop access
    solution. (Even if you implement alternate framegrab you are at minimum
    forced to keep the RDP connection alive with e.g. occasional frame acks,
    to prevent the session from suspending).

    A Remote Desktop Services Protocol Provider (RDSPP) can use a custom
    protocol, but only works on Windows Server. MS uses the same
    rdpcorets.dll RDSPP implementation for RDP on Desktop and Server OSes,
    but it seems they whitelist themselves for desktop OS, nobody else is
    allowed to load. (If somebody knows otherwise I'd be happy to find out how.)

    -Nathan
  • Tiago_CastroTiago_Castro Member - All Emails Posts: 6
    Not sure what those "RDP services" are but TV doesn't look like the standard RDP. With TV you get access to the remote PC but it doesn't log you in, you get the same thing you'd otherwise see on your remote monitor.
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 131
    This "Blackout" feature does exist indeed.
    It is called "Enable black screen if partner input is deactivated".
    It is definitely NOT using RDP.
    It uses a replacement of standard Windows Generic PnP Monitor driver (monitor.sys).
    It seems to work on various Win10 platforms with WDDM graphics adapters.
    There is at least one platform (Win10 x64 Nvidia GeForce GTX 980M) where it fails.
    Might be a plain bug (or might be an indicator that it is unstable using unsupported hacks).
    Hope I'll find a large enough time slot soon to analyze what it is really doing...

    Marcel Ruedinger

    datronicsoft
  • Marcel_RuedingerMarcel_Ruedinger Member Posts: 131
    Finally, the "Blackout" feature demystified:

    Standard monitor Function Driver (monitor.sys) is replaced by a different monitor Function Driver called "MonitorFunction" (TVMonitor.sys).

    This alternative monitor driver destroys standard Windows functionality (e.g. display brighntness function keys on the keyboard don't work any more).

    This alternative monitor driver achieves the "Blackout" feature by putting the monitor into D2 power state. A short look into the ACPI spec (Appendix A.6 Display Device Class) seems to indicate that D2 support is only required for CRT (Cathod Ray Tube) monitors. Other monitors might not support D2.

    This alternative monitor driver can be observed to fail on various platform ("Blackout" doesn't work). One potential explanation is lacking D2 support as stated above. Probably there are other reasons, too.

    Cool company actually (~100 employees - worth more than one billion US$ - "Unicorn" in investor's talk). This device driver, however rather appears like an unreliable old hack (from the times of CRT monitors). Wonder if/how they can/will continue supporting it in the future when already today it fails on quite a few platforms...

    Marcel Ruedinger

    datronicsoft
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!