Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

OSR Seminars


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 31  
10 Jul 18 14:02
Szilárd Szalóki
xxxxxx@gmail.com
Join Date: 10 Jul 2018
Posts To This List: 4
KMDF driver for turning off the displays

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
  Message 2 of 31  
10 Jul 18 17:07
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6243
List Moderator
KMDF driver for turning off the displays

>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
  Message 3 of 31  
10 Jul 18 17:22
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6243
List Moderator
KMDF driver for turning off the displays

>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
  Message 4 of 31  
10 Jul 18 18:02
Szilárd Szalóki
xxxxxx@gmail.com
Join Date: 10 Jul 2018
Posts To This List: 4
KMDF driver for turning off the displays

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 <xxxxx@lists.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 <...excess quoted lines suppressed...> --
  Message 5 of 31  
11 Jul 18 02:42
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 12008
KMDF driver for turning off the displays

On Jul 10, 2018, at 3:02 PM, xxxxx@gmail.com <xxxxx@lists.osr.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. --
  Message 6 of 31  
11 Jul 18 04:03
Szilárd Szalóki
xxxxxx@gmail.com
Join Date: 10 Jul 2018
Posts To This List: 4
KMDF driver for turning off the displays

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 <xxxxx@lists.osr.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. > ??? <...excess quoted lines suppressed...> --
  Message 7 of 31  
11 Jul 18 16:21
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 12008
KMDF driver for turning off the displays

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.
  Message 8 of 31  
11 Jul 18 16:45
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 123
KMDF driver for turning off the displays

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
  Message 9 of 31  
11 Jul 18 17:12
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 12008
KMDF driver for turning off the displays

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.
  Message 10 of 31  
11 Jul 18 18:07
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4100
KMDF driver for turning off the displays

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: > <...excess quoted lines suppressed...> --
  Message 11 of 31  
11 Jul 18 19:13
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 12008
KMDF driver for turning off the displays

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.
  Message 12 of 31  
11 Jul 18 19:35
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 123
KMDF driver for turning off the displays

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 <...excess quoted lines suppressed...> 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
  Message 13 of 31  
12 Jul 18 05:42
Marcel Ruedinger
xxxxxx@datronic.de
Join Date: 01 Nov 2010
Posts To This List: 131
KMDF driver for turning off the displays

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
  Message 14 of 31  
12 Jul 18 07:29
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4100
KMDF driver for turning off the displays

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 <xxxxx@lists.osr.com> 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 <...excess quoted lines suppressed...> --
  Message 15 of 31  
12 Jul 18 07:54
Szilárd Szalóki
xxxxxx@gmail.com
Join Date: 10 Jul 2018
Posts To This List: 4
KMDF driver for turning off the displays

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 <xxxxx@lists.osr.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 <xxxxx@lists.osr.com> 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 <...excess quoted lines suppressed...> --
  Message 16 of 31  
12 Jul 18 10:55
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6243
List Moderator
KMDF driver for turning off the displays

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
  Message 17 of 31  
12 Jul 18 11:35
Marcel Ruedinger
xxxxxx@datronic.de
Join Date: 01 Nov 2010
Posts To This List: 131
KMDF driver for turning off the displays

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
  Message 18 of 31  
12 Jul 18 12:11
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 123
KMDF driver for turning off the displays

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. <...excess quoted lines suppressed...> 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
  Message 19 of 31  
12 Jul 18 12:32
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6243
List Moderator
KMDF driver for turning off the displays

<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
  Message 20 of 31  
12 Jul 18 12:36
Tiago Castro
xxxxxx@gmail.com
Join Date: 20 Jan 2016
Posts To This List: 6
KMDF driver for turning off the displays

As Tim suggested I also have seen commercial products do this through a custom monitor driver, so it is possible...
  Message 21 of 31  
12 Jul 18 12:44
R0b0t1
xxxxxx@gmail.com
Join Date: 24 Mar 2017
Posts To This List: 123
KMDF driver for turning off the displays

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
  Message 22 of 31  
12 Jul 18 17:19
Marcel Ruedinger
xxxxxx@datronic.de
Join Date: 01 Nov 2010
Posts To This List: 131
KMDF driver for turning off the displays

@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
  Message 23 of 31  
13 Jul 18 04:45
Tiago Castro
xxxxxx@gmail.com
Join Date: 20 Jan 2016
Posts To This List: 6
KMDF driver for turning off the displays

@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?
  Message 24 of 31  
13 Jul 18 07:01
Marcel Ruedinger
xxxxxx@datronic.de
Join Date: 01 Nov 2010
Posts To This List: 131
KMDF driver for turning off the displays

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
  Message 25 of 31  
13 Jul 18 10:28
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6243
List Moderator
KMDF driver for turning off the displays

> 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
  Message 26 of 31  
13 Jul 18 13:16
Tiago Castro
xxxxxx@gmail.com
Join Date: 20 Jan 2016
Posts To This List: 6
KMDF driver for turning off the displays

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)
  Message 27 of 31  
13 Jul 18 15:08
Marcel Ruedinger
xxxxxx@datronic.de
Join Date: 01 Nov 2010
Posts To This List: 131
KMDF driver for turning off the displays

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
  Message 28 of 31  
13 Jul 18 16:57
Nathan Kidd
xxxxxx@spicycrypto.ca
Join Date: 12 Oct 2017
Posts To This List: 9
KMDF driver for turning off the displays

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
  Message 29 of 31  
13 Jul 18 17:30
Tiago Castro
xxxxxx@gmail.com
Join Date: 20 Jan 2016
Posts To This List: 6
KMDF driver for turning off the displays

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.
  Message 30 of 31  
16 Jul 18 15:59
Marcel Ruedinger
xxxxxx@datronic.de
Join Date: 01 Nov 2010
Posts To This List: 131
KMDF driver for turning off the displays

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
  Message 31 of 31  
17 Jul 18 07:58
Marcel Ruedinger
xxxxxx@datronic.de
Join Date: 01 Nov 2010
Posts To This List: 131
KMDF driver for turning off the displays

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
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 19:27.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license