turning off monitors

[Sharon_Drasnin]

hi

I found some OSROnline postings back in 2002 regarding how to turn off a display monitor. I’d like to try doing this with the goal of saving power while XP is in S0. (According to an Intel doc that is a few years old now that I read on the web, the LCD consumes 37% of the power.) I don’t have source code to the video driver or the miniport driver. I don’t know if the 3rd party driver supports an ExtEscape with a custom code to power it down either. By the way, just because I want to try this doesn’t mean I’m going to put in to use (in case you think it’s a bad idea) - at the very least, it’s a good learning experience.

Here is the posted suggestion from 2002, followed by a reply from Doron. I want to know if anybody has been successful with approach or if they have implemented anything else:
This problem was actually the reason I started device driver programming. (Though in my case it was so I could turn off the screen of my stupid laptop when I closed the lid.) You have to send IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE to \Device\Video0. You could do this from user mode if you somehow get a handle to that device (which as far as I know is impossible.) As input you give it a pointer to a ULONG that holds one of the VideoPowerXxx enums and as output give it NULL. The only way I found to get access to that device was to use IoAttachDevice, reference the pointer it returns, and then use IoDetachDevice. (Which is probably a really bad way of getting the pointer, anyone know of a better way?)

Check out IoGetDeviceObjectPointer. The DDK example kbdclass contains code which uses this function. Note that this will send a create file to the object in question and if \device\video0 can get pnp removed, you have to register for notifications on the file handle (kbdclass also does this) so that you can close it.

By the way, ::SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, (WPARAM)SC_MONITORPOWER, 2) works great at turning off the monitor (and googling results indicated it will also turn off a external monitor at the same time) but I suspect that it doesn’t save much power - but I don’t have any power measurements to back that statement up. . If anybody knows how this message is processed under the covers I’d love to know. Does it try to shut the graphics controller down?

thanks in advance…

[Sharon_Drasnin]

hi

I implemented the code and got past the STATUS_ACCESS_DENIED issue the original poster indicated, but I’m running into a problem in which the handle I pass up to the app is invalid. The DeviceIoControl() call it makes using this handle fails with error 6 (The handle is invalid.)

For the IoGetDevicePointer call, isn’t the PFILE_OBJECT *FileObject parameter the handle that the app is supposed to use?

Here’s what I’m doing:

1. add using as IOCTL to pass down a buffer that the driver is to fill device handles (there are 2 Display devices).
2. Driver calls IoGetDeviceInterfaces for GUID_DEVINTERFACE_DISPLAY_ADAPTER. It returns 2 packed wchars strings.
3. I pull apart each of the strings and pass it to IoGetDeviceObjectPointer. I did remember to set the unicode length to two times the wchar wcslen length since the unicode length has to be in bytes.
4. I return the PFILE_OBJECT *FileObject value back to the app in the buffer passed in #1 above. The app uses this as the handle to pass to DeviceIoControl()

The reason I have to do step #2 is because if I just call IoGetDeviceObjectPointer() it returns STATUS_ACCESS_DENIED.

I checked the driver and the app both are using the same handle. The value is 0x8153b990 (maybe you can tell if this is a valid handle by the address).

Perhaps I’m not returning the right parameter?
Note that I ran the OSR tool objdir.exe and I see the \Device\Video0<file:> and \Device\Video1<file:> are present but it doesn’t give me detailed info.
Perhaps there is another tool I can run.

thanks!

----- Original Message -----
From: S. Drasninmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: July 13, 2006 11:48 PM
Subject: [ntdev] turning off monitors

hi

I found some OSROnline postings back in 2002 regarding how to turn off a display monitor. I’d like to try doing this with the goal of saving power while XP is in S0. (According to an Intel doc that is a few years old now that I read on the web, the LCD consumes 37% of the power.) I don’t have source code to the video driver or the miniport driver. I don’t know if the 3rd party driver supports an ExtEscape with a custom code to power it down either. By the way, just because I want to try this doesn’t mean I’m going to put in to use (in case you think it’s a bad idea) - at the very least, it’s a good learning experience.

Here is the posted suggestion from 2002, followed by a reply from Doron. I want to know if anybody has been successful with approach or if they have implemented anything else:
This problem was actually the reason I started device driver programming. (Though in my case it was so I could turn off the screen of my stupid laptop when I closed the lid.) You have to send IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE to \Device\Video0. You could do this from user mode if you somehow get a handle to that device (which as far as I know is impossible.) As input you give it a pointer to a ULONG that holds one of the VideoPowerXxx enums and as output give it NULL. The only way I found to get access to that device was to use IoAttachDevice, reference the pointer it returns, and then use IoDetachDevice. (Which is probably a really bad way of getting the pointer, anyone know of a better way?)

Check out IoGetDeviceObjectPointer. The DDK example kbdclass contains code which uses this function. Note that this will send a create file to the object in question and if \device\video0 can get pnp removed, you have to register for notifications on the file handle (kbdclass also does this) so that you can close it.

By the way, ::SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, (WPARAM)SC_MONITORPOWER, 2) works great at turning off the monitor (and googling results indicated it will also turn off a external monitor at the same time) but I suspect that it doesn’t save much power - but I don’t have any power measurements to back that statement up. . If anybody knows how this message is processed under the covers I’d love to know. Does it try to shut the graphics controller down?

thanks in advance…

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></file:></file:>

[Doron_Holan]

A handle in UM is not just a straight up pointer value in KM. in windows, it is an index into a table and a slot in the table contains the object pointer (which in this case is a PFILE_OBJECT). You are just passing a useless value back to the app. Why would a UM app have more success in sending i/o then your driver would?

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, July 14, 2006 11:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] turning off monitors

hi
?
I implemented the code and got past the STATUS_ACCESS_DENIED?issue the original poster indicated,??but I’m running into a problem in which the handle I pass up to the app is invalid. The DeviceIoControl() call it makes using this handle?fails with error 6 (The handle is invalid.)?
?
?For the IoGetDevicePointer call, isn’t the ?PFILE_OBJECT? *FileObject? parameter the handle that the app is supposed to use?
?
Here’s what I’m doing:

1. add using as IOCTL to pass down a buffer that the driver is to fill device handles (there are 2 Display devices).
2. Driver calls IoGetDeviceInterfaces for GUID_DEVINTERFACE_DISPLAY_ADAPTER. It returns 2 packed wchars strings.
3. I pull apart each of the strings and pass it to IoGetDeviceObjectPointer. I did remember to set the unicode length to two times the wchar wcslen length since the unicode length has to be in bytes.
4. I return the PFILE_OBJECT? *FileObject? value back to the app in the buffer passed in #1 above. The app uses this as the handle to pass to DeviceIoControl()
   ?
   The reason I have to do step #2 is because if I just call IoGetDeviceObjectPointer() it returns STATUS_ACCESS_DENIED.
   ?
   I checked the driver and the app both are using the same handle. The value is 0x8153b990 (maybe you can tell if this is a valid handle by the address).
   ?
   Perhaps I’m not returning the right parameter?
   Note that I ran the OSR tool objdir.exe and I see the \Device\Video0 and \Device\Video1 are present but it doesn’t give me detailed info.
   Perhaps there is another tool I can run.
   ?
   thanks!
   ?
   ?
   ?
   ----- Original Message -----
   From: S. Drasnin
   To: Windows System Software Devs Interest List
   Sent: July 13, 2006 11:48 PM
   Subject: [ntdev] turning off monitors

hi
?
I found some OSROnline postings back in 2002 regarding how to turn off a display monitor. I’d like to try doing this with the goal of saving power while XP is in S0.?(According to an Intel doc that is a few years old now that I read on the web, the LCD consumes 37% of the power.) ?I don’t have source code to the video driver or the miniport driver. I don’t know if the 3rd party driver supports an ExtEscape with a?custom code?to power it down either. By the way, just because I want to try this doesn’t mean I’m going to put in to use (in case you think it’s a bad idea) - at the very least, it’s a good learning experience.
?
Here is the posted suggestion from 2002, followed by a reply from Doron. I want to know if anybody has been successful with approach or if they have implemented anything else:
This problem was actually the reason I started device driver programming. (Though in my case it was so I could turn off the screen of my stupid laptop when I closed the lid.) You have to send IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE to \Device\Video0. You could do this from user mode if you somehow get a handle to that device (which as far as I know is impossible.) As input you give it a pointer to a ULONG that holds one of the VideoPowerXxx enums and as output give it NULL. The only way I found to get access to that device was to use IoAttachDevice, reference the pointer it returns, and then use IoDetachDevice. (Which is probably a really bad way of getting the pointer, anyone know of a better way?)
?
Check out IoGetDeviceObjectPointer. The DDK example kbdclass contains code which uses this function. Note that this will send a create file to the object in question and if \device\video0 can get pnp removed, you have to register for notifications on the file handle (kbdclass also does this) so that you can close it.
?
By the way,??::SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, (WPARAM)SC_MONITORPOWER, 2) works great at turning off the monitor (and googling? results indicated it will also turn off a external monitor at the same time) but I suspect that it doesn’t save much power - but I don’t have any power measurements to back that statement up. . If anybody knows how this message is processed under the covers I’d love to know. Does it try to shut the graphics controller down?
?
thanks in advance…

---

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

---

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

S. Drasnin wrote:

hi

I implemented the code and got past the STATUS_ACCESS_DENIED issue the
original poster indicated, but I’m running into a problem in which the
handle I pass up to the app is invalid. The DeviceIoControl() call it
makes using this handle fails with error 6 (The handle is invalid.)

For the IoGetDevicePointer call, isn’t the *PFILE_OBJECT*
***/FileObject /parameter the handle that the app is supposed to use?

Nope… HANDLEs are per-process (usually) abstractions.
PFILE_OBJECTs are valid in any process context, pointers
to an object in kernel memory (can’t be accessed by usermode.)

I think there is a call to create a handle from a PFILE_OBJECT
(I don’t remember for sure) – make sure you are making the call
in the right process context though… (that per-process thing.)

Thanks,

Joseph

[Sharon_Drasnin]

Doron:

I implemented what was in the original posting just to see if I could get it to work. (You can read below to see what was described.)

So are you saying forget trying to get the UM handle. (I was trying to do this since CreateFile won’t work in this case.)
Can you suggest something that would work. Sending I/O via the driver directly.

I set a breakpoint in the driver after the IoGetDeviceObjectPointer() call and looked at the DriverObject. The DriverName is right so I think the calls themselves might be ok.

thanks

----- Original Message -----
From: Doron Holanmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: July 14, 2006 11:48 AM
Subject: RE: [ntdev] turning off monitors

A handle in UM is not just a straight up pointer value in KM. in windows, it is an index into a table and a slot in the table contains the object pointer (which in this case is a PFILE_OBJECT). You are just passing a useless value back to the app. Why would a UM app have more success in sending i/o then your driver would?

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, July 14, 2006 11:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] turning off monitors

hi

I implemented the code and got past the STATUS_ACCESS_DENIED issue the original poster indicated, but I’m running into a problem in which the handle I pass up to the app is invalid. The DeviceIoControl() call it makes using this handle fails with error 6 (The handle is invalid.)

For the IoGetDevicePointer call, isn’t the PFILE_OBJECT *FileObject parameter the handle that the app is supposed to use?

Here’s what I’m doing:
1) add using as IOCTL to pass down a buffer that the driver is to fill device handles (there are 2 Display devices).
2) Driver calls IoGetDeviceInterfaces for GUID_DEVINTERFACE_DISPLAY_ADAPTER. It returns 2 packed wchars strings.
3) I pull apart each of the strings and pass it to IoGetDeviceObjectPointer. I did remember to set the unicode length to two times the wchar wcslen length since the unicode length has to be in bytes.
4) I return the PFILE_OBJECT *FileObject value back to the app in the buffer passed in #1 above. The app uses this as the handle to pass to DeviceIoControl()

The reason I have to do step #2 is because if I just call IoGetDeviceObjectPointer() it returns STATUS_ACCESS_DENIED.

I checked the driver and the app both are using the same handle. The value is 0x8153b990 (maybe you can tell if this is a valid handle by the address).

Perhaps I’m not returning the right parameter?
Note that I ran the OSR tool objdir.exe and I see the \Device\Video0<file:> and \Device\Video1<file:> are present but it doesn’t give me detailed info.
Perhaps there is another tool I can run.

thanks!

----- Original Message -----
From: S. Drasnin
To: Windows System Software Devs Interest List
Sent: July 13, 2006 11:48 PM
Subject: [ntdev] turning off monitors

hi

I found some OSROnline postings back in 2002 regarding how to turn off a display monitor. I’d like to try doing this with the goal of saving power while XP is in S0. (According to an Intel doc that is a few years old now that I read on the web, the LCD consumes 37% of the power.) I don’t have source code to the video driver or the miniport driver. I don’t know if the 3rd party driver supports an ExtEscape with a custom code to power it down either. By the way, just because I want to try this doesn’t mean I’m going to put in to use (in case you think it’s a bad idea) - at the very least, it’s a good learning experience.

Here is the posted suggestion from 2002, followed by a reply from Doron. I want to know if anybody has been successful with approach or if they have implemented anything else:
This problem was actually the reason I started device driver programming. (Though in my case it was so I could turn off the screen of my stupid laptop when I closed the lid.) You have to send IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE to \Device\Video0. You could do this from user mode if you somehow get a handle to that device (which as far as I know is impossible.) As input you give it a pointer to a ULONG that holds one of the VideoPowerXxx enums and as output give it NULL. The only way I found to get access to that device was to use IoAttachDevice, reference the pointer it returns, and then use IoDetachDevice. (Which is probably a really bad way of getting the pointer, anyone know of a better way?)

Check out IoGetDeviceObjectPointer. The DDK example kbdclass contains code which uses this function. Note that this will send a create file to the object in question and if \device\video0 can get pnp removed, you have to register for notifications on the file handle (kbdclass also does this) so that you can close it.

By the way, ::SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, (WPARAM)SC_MONITORPOWER, 2) works great at turning off the monitor (and googling results indicated it will also turn off a external monitor at the same time) but I suspect that it doesn’t save much power - but I don’t have any power measurements to back that statement up. . If anybody knows how this message is processed under the covers I’d love to know. Does it try to shut the graphics controller down?

thanks in advance…

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServerhttp:

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServerhttp:

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServerhttp:</http:></http:></http:></http:></http:></http:></file:></file:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

[Sharon_Drasnin]

I built up a device io control request in the driver (see below) and sent it to the device object returned from the IoGetDEviceObjectPointer().
Using IrpTracker, I verfied that this was getting down to the driver that manages the display.
However, the driver must not like that IOCTL - it’s returning INVALID_DEVICE_REQUEST.

I know this is a long shot, but perhaps I’m calling IoBuildDeviceIoControlRequest with the wrong parameters.
I don’t really know much about video drivers - maybe a lot of them just don’t support that IOCTL or maybe I messed something else up.

ULONG VideoPowerValue = VideoPowerOff;
irp = IoBuildDeviceIoControlRequest( IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE,
DeviceObject,
&VideoPowerValue, sizeof(ULONG),
NULL, 0, // no output buffer
TRUE,
&event,
&ioStatus);

thanks
----- Original Message -----
From: S. Drasninmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: July 14, 2006 12:16 PM
Subject: Re: [ntdev] turning off monitors

Doron:

I implemented what was in the original posting just to see if I could get it to work. (You can read below to see what was described.)

So are you saying forget trying to get the UM handle. (I was trying to do this since CreateFile won’t work in this case.)
Can you suggest something that would work. Sending I/O via the driver directly.

I set a breakpoint in the driver after the IoGetDeviceObjectPointer() call and looked at the DriverObject. The DriverName is right so I think the calls themselves might be ok.

thanks

----- Original Message -----
From: Doron Holanmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: July 14, 2006 11:48 AM
Subject: RE: [ntdev] turning off monitors

A handle in UM is not just a straight up pointer value in KM. in windows, it is an index into a table and a slot in the table contains the object pointer (which in this case is a PFILE_OBJECT). You are just passing a useless value back to the app. Why would a UM app have more success in sending i/o then your driver would?

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, July 14, 2006 11:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] turning off monitors

hi

I implemented the code and got past the STATUS_ACCESS_DENIED issue the original poster indicated, but I’m running into a problem in which the handle I pass up to the app is invalid. The DeviceIoControl() call it makes using this handle fails with error 6 (The handle is invalid.)

For the IoGetDevicePointer call, isn’t the PFILE_OBJECT *FileObject parameter the handle that the app is supposed to use?

Here’s what I’m doing:
1) add using as IOCTL to pass down a buffer that the driver is to fill device handles (there are 2 Display devices).
2) Driver calls IoGetDeviceInterfaces for GUID_DEVINTERFACE_DISPLAY_ADAPTER. It returns 2 packed wchars strings.
3) I pull apart each of the strings and pass it to IoGetDeviceObjectPointer. I did remember to set the unicode length to two times the wchar wcslen length since the unicode length has to be in bytes.
4) I return the PFILE_OBJECT *FileObject value back to the app in the buffer passed in #1 above. The app uses this as the handle to pass to DeviceIoControl()

The reason I have to do step #2 is because if I just call IoGetDeviceObjectPointer() it returns STATUS_ACCESS_DENIED.

I checked the driver and the app both are using the same handle. The value is 0x8153b990 (maybe you can tell if this is a valid handle by the address).

Perhaps I’m not returning the right parameter?
Note that I ran the OSR tool objdir.exe and I see the \Device\Video0<file:> and \Device\Video1<file:> are present but it doesn’t give me detailed info.
Perhaps there is another tool I can run.

thanks!

----- Original Message -----
From: S. Drasnin
To: Windows System Software Devs Interest List
Sent: July 13, 2006 11:48 PM
Subject: [ntdev] turning off monitors

hi

I found some OSROnline postings back in 2002 regarding how to turn off a display monitor. I’d like to try doing this with the goal of saving power while XP is in S0. (According to an Intel doc that is a few years old now that I read on the web, the LCD consumes 37% of the power.) I don’t have source code to the video driver or the miniport driver. I don’t know if the 3rd party driver supports an ExtEscape with a custom code to power it down either. By the way, just because I want to try this doesn’t mean I’m going to put in to use (in case you think it’s a bad idea) - at the very least, it’s a good learning experience.

Here is the posted suggestion from 2002, followed by a reply from Doron. I want to know if anybody has been successful with approach or if they have implemented anything else:
This problem was actually the reason I started device driver programming. (Though in my case it was so I could turn off the screen of my stupid laptop when I closed the lid.) You have to send IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE to \Device\Video0. You could do this from user mode if you somehow get a handle to that device (which as far as I know is impossible.) As input you give it a pointer to a ULONG that holds one of the VideoPowerXxx enums and as output give it NULL. The only way I found to get access to that device was to use IoAttachDevice, reference the pointer it returns, and then use IoDetachDevice. (Which is probably a really bad way of getting the pointer, anyone know of a better way?)

Check out IoGetDeviceObjectPointer. The DDK example kbdclass contains code which uses this function. Note that this will send a create file to the object in question and if \device\video0 can get pnp removed, you have to register for notifications on the file handle (kbdclass also does this) so that you can close it.

By the way, ::SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, (WPARAM)SC_MONITORPOWER, 2) works great at turning off the monitor (and googling results indicated it will also turn off a external monitor at the same time) but I suspect that it doesn’t save much power - but I don’t have any power measurements to back that statement up. . If anybody knows how this message is processed under the covers I’d love to know. Does it try to shut the graphics controller down?

thanks in advance…

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServerhttp:

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServerhttp:

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServerhttp:

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</http:></http:></http:></http:></http:></http:></file:></file:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

[Sharon_Drasnin]

I got turning off of the displays to work. My error below was that I set it to generate an internal I/o control - once I sent the IoBuildDeviceIoControl() parameter from true to false it worked.

----- Original Message -----
From: S. Drasninmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: July 14, 2006 1:09 PM
Subject: Re: [ntdev] turning off monitors

I built up a device io control request in the driver (see below) and sent it to the device object returned from the IoGetDEviceObjectPointer().
Using IrpTracker, I verfied that this was getting down to the driver that manages the display.
However, the driver must not like that IOCTL - it’s returning INVALID_DEVICE_REQUEST.

I know this is a long shot, but perhaps I’m calling IoBuildDeviceIoControlRequest with the wrong parameters.
I don’t really know much about video drivers - maybe a lot of them just don’t support that IOCTL or maybe I messed something else up.

ULONG VideoPowerValue = VideoPowerOff;
irp = IoBuildDeviceIoControlRequest( IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE,
DeviceObject,
&VideoPowerValue, sizeof(ULONG),
NULL, 0, // no output buffer
TRUE,
&event,
&ioStatus);

thanks
----- Original Message -----
From: S. Drasninmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: July 14, 2006 12:16 PM
Subject: Re: [ntdev] turning off monitors

Doron:

I implemented what was in the original posting just to see if I could get it to work. (You can read below to see what was described.)

So are you saying forget trying to get the UM handle. (I was trying to do this since CreateFile won’t work in this case.)
Can you suggest something that would work. Sending I/O via the driver directly.

I set a breakpoint in the driver after the IoGetDeviceObjectPointer() call and looked at the DriverObject. The DriverName is right so I think the calls themselves might be ok.

thanks

----- Original Message -----
From: Doron Holanmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: July 14, 2006 11:48 AM
Subject: RE: [ntdev] turning off monitors

A handle in UM is not just a straight up pointer value in KM. in windows, it is an index into a table and a slot in the table contains the object pointer (which in this case is a PFILE_OBJECT). You are just passing a useless value back to the app. Why would a UM app have more success in sending i/o then your driver would?

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.commailto:xxxxx [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, July 14, 2006 11:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] turning off monitors

hi

I implemented the code and got past the STATUS_ACCESS_DENIED issue the original poster indicated, but I’m running into a problem in which the handle I pass up to the app is invalid. The DeviceIoControl() call it makes using this handle fails with error 6 (The handle is invalid.)

For the IoGetDevicePointer call, isn’t the PFILE_OBJECT *FileObject parameter the handle that the app is supposed to use?

Here’s what I’m doing:
1) add using as IOCTL to pass down a buffer that the driver is to fill device handles (there are 2 Display devices).
2) Driver calls IoGetDeviceInterfaces for GUID_DEVINTERFACE_DISPLAY_ADAPTER. It returns 2 packed wchars strings.
3) I pull apart each of the strings and pass it to IoGetDeviceObjectPointer. I did remember to set the unicode length to two times the wchar wcslen length since the unicode length has to be in bytes.
4) I return the PFILE_OBJECT *FileObject value back to the app in the buffer passed in #1 above. The app uses this as the handle to pass to DeviceIoControl()

The reason I have to do step #2 is because if I just call IoGetDeviceObjectPointer() it returns STATUS_ACCESS_DENIED.

I checked the driver and the app both are using the same handle. The value is 0x8153b990 (maybe you can tell if this is a valid handle by the address).

Perhaps I’m not returning the right parameter?
Note that I ran the OSR tool objdir.exe and I see the \Device\Video0<file:> and \Device\Video1<file:> are present but it doesn’t give me detailed info.
Perhaps there is another tool I can run.

thanks!

----- Original Message -----
From: S. Drasnin
To: Windows System Software Devs Interest List
Sent: July 13, 2006 11:48 PM
Subject: [ntdev] turning off monitors

hi

I found some OSROnline postings back in 2002 regarding how to turn off a display monitor. I’d like to try doing this with the goal of saving power while XP is in S0. (According to an Intel doc that is a few years old now that I read on the web, the LCD consumes 37% of the power.) I don’t have source code to the video driver or the miniport driver. I don’t know if the 3rd party driver supports an ExtEscape with a custom code to power it down either. By the way, just because I want to try this doesn’t mean I’m going to put in to use (in case you think it’s a bad idea) - at the very least, it’s a good learning experience.

Here is the posted suggestion from 2002, followed by a reply from Doron. I want to know if anybody has been successful with approach or if they have implemented anything else:
This problem was actually the reason I started device driver programming. (Though in my case it was so I could turn off the screen of my stupid laptop when I closed the lid.) You have to send IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE to \Device\Video0. You could do this from user mode if you somehow get a handle to that device (which as far as I know is impossible.) As input you give it a pointer to a ULONG that holds one of the VideoPowerXxx enums and as output give it NULL. The only way I found to get access to that device was to use IoAttachDevice, reference the pointer it returns, and then use IoDetachDevice. (Which is probably a really bad way of getting the pointer, anyone know of a better way?)

Check out IoGetDeviceObjectPointer. The DDK example kbdclass contains code which uses this function. Note that this will send a create file to the object in question and if \device\video0 can get pnp removed, you have to register for notifications on the file handle (kbdclass also does this) so that you can close it.

By the way, ::SendMessage(HWND_BROADCAST, WM_SYSCOMMAND, (WPARAM)SC_MONITORPOWER, 2) works great at turning off the monitor (and googling results indicated it will also turn off a external monitor at the same time) but I suspect that it doesn’t save much power - but I don’t have any power measurements to back that statement up. . If anybody knows how this message is processed under the covers I’d love to know. Does it try to shut the graphics controller down?

thanks in advance…

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServerhttp:

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServerhttp:

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServerhttp:

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</http:></http:></http:></http:></http:></http:></file:></file:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>