Driver to turn off and on monitor RRS feed

  • Question

  • Tried using power requests to turn off monitor with Away mode but it's not consistent... Need help.
    Sunday, December 22, 2019 11:21 AM

All replies

  • What calls did you make?  Show is the code.  When you say "not consistent", do you mean it works differently on different systems, or that it doesn't always work on your own system?

    And, one more -- why do you need to force the monitor to sleep, rather than use the power settings to set the timers properly?

    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Monday, December 23, 2019 7:00 AM
  • Hi Tim,

    want to make monitor go off (No sleep , system should be running (just like away mode.)), so that no body could spy/glance at machine while someone works remotely. My application is a remote app which access that machine .

    when i create and set a power request with "away mode", if any other app creates one more power request to sleep then my request looks like overridden ,not sure . Basically want to make sure my machine do not turn on monitor( or go to sleep ) until i send my protocol to wake up from my remote app.

    Is it possible to write a kernel mode driver to make other power request to be ignored by windows sub system.

     I see some remote access apps are doing the same way by writing monitor class driver to turn off the monitors (not sure ).


    Tuesday, December 24, 2019 10:18 AM
  • Maybe a WMI method exists for this.

    Or, set the monitor brightness to 0 using SetMonitorBrightness. See an example here.

    -- pa

    Wednesday, December 25, 2019 12:28 AM
  • If WMI control and SetMonitorBrightness(…) work, then this is a solution. Unfortunately it seems a bit too cool and easy to be true (probably it can only dim but not fully black out the monitor).

    Writing an own Monitor Class Driver (replacing existing Windows Monitor Class Driver) is definitely not a solution (check my detailed post about this topic in the Osronline NTDEV newsgroup in July 2018).

    I could only imagine one clean solution working in all environments:

    1. Write an empty dummy virtual WDDM IddCx Indirect Display Driver (check my post how to write a virtual IddCx driver in the Osronline NTDEV newsgroup on June 6th 2019).

    2. When the remote app connects, then use CCD API to:
    - First attach the dummy WDDM IddCx driver's monitor as a mirror.
    - Then detach the real monitor from the Windows Desktop.
    - This way screen content is preserved on the dummy monitor.

    3. When the remote app disconnects, then use CCD API to:
    - First attach the real monitor to the dummy WDDM IddCx driver's monitor as a mirror.
    - Then detach the dummy WDDM IddCx driver's monitor from the Windows Desktop.
    - This way screen content is restored from the dummy monitor to the real monitor.

    To prevent the system from going to sleep, use SetThreadExecutionState().
    This keeps Windows system and dummy WDDM IddCx monitor alive.
    Still nothing can be seen on the real monitor because it is detached.

    Marcel Ruedinger

    Wednesday, December 25, 2019 8:56 AM
  • Hi Marcel ,

    Thanks for the detailed info.

    First point looks simple and easy to implement , would it work for all types of monitors .

    Third point , we tried this approach , but having issues when we mirroring desktop in multi monitor setup , like "duplicate" and s"screen only" we see multiple virtual screens getting created , where in all screen are not going blank and seeing lot of resolution changes ...are you sure this approach works in multi monitor environment.

    Please correct me if am wrong.

    Also have seen some kernel api like  PoRequestPowerIrp to set the device state .

    Firstly , put the system e power configuration in away mode and turn off monitor using below api ,

    SendMessage(handle, WM_SYSCOMMAND, SC_MONITORPOWER, 2);

    then subsequently try ignoring any wake-up calls from userspace from custom written driver, until apps sends unblank .

    How about this??... not sure ..please help ...



    Wednesday, December 25, 2019 11:55 AM
  • Hi Pavel,

    have seen for some monitors,Brigtness cannot go low after some limit , we might only can dim not black out. Not sure if it feasible.

    will this work with all types of monitors.



    Wednesday, December 25, 2019 3:12 PM
  • Well, a short answer is that if you rely on the monitor (hardware) to completely go blank/black, and not all monitors are created equal - test them (or tel your customer to test), and only use those that behave good.

    Else, rely on the software (Windows) to stop displaying anything on the monitor. In that case you even don't need it to go 100% black, since it won't show sensitive info. With proprietary, closed source software, this is complicated :(

    -- pa

    Thursday, December 26, 2019 4:28 AM
  • Multi monitor solution should be possible albeit very difficult to implement correctly (CCD API is a beast).

    Three hard limitations:
    - Does not work on Windows 10 before 1607 e.g. 1511 (no IddCx drivers before 1607).
    - Does not work on graphics adapter < WDDM 2.0 e.g. WDDM 1.3 (no cross adapter mirror before WDDM 2.0).
    - Only works with up to 16 monitors per virtual IddCx driver (IddCx currently only seems to supports 16 monitors).

    To avoid unwanted resolution changes quite a few tricky implementations are necessary like...
    ...prevent initial attachment of any IddCx dummy monitor to avoid resolution change while not yet attached as mirror...
    ...need to attach/detach multiple mirrors in only one call to SetDisplayConfig...

    Then last but not least: Use extremely clean design and implementation to avoid leaving users without any monitors attached in case of error!

    About PoRequestPowerIrp: Just read the first line of the WDK documentation: "A DEVICE POWER POLICY OWNER calls this routine..."
    The concept of "Device Power Policy" defines a "Power Policy Owner" (PPO). There can only be one PPO in each device stack. In this case the Windows operating system Monitor Class Driver is PPO.
    If anyone other than the PPO tries to mess with Device Power Policy (e.g. try sending unauthorized Power IRPs or try stealing regular Power IRPs) you will very soon end up with a Blue Screen of Death named DRIVER_POWER_STATE_FAILURE

    Marcel Ruedinger
    Thursday, December 26, 2019 5:25 AM