Hi,
I have a video miniport driver. One of the features we support is to change the switch from one monitor to another monitor at run time without using the “display properties” application (we use our own GUI). Once that happens the miniport figures out a new set of modes that the new monitor supports which may not be the same as the ones that the old monitor supported.
The problem is that from an OS standpoint, it asked for the modes at bootup time and it doesn’t know that the underlying monitors have changed. I want to force the OS to do a DrvGetModes again to get the new modes but I don’t know how to communicate it back to the OS to do so.
Anyone has any ideas?
TIA!
Bagh
> I have a video miniport driver. One of the features we
support is to change the switch from one monitor to another
monitor at run time without using the “display properties”
application (we use our own GUI). Once that happens the
miniport figures out a new set of modes that the new monitor
supports which may not be the same as the ones that the old
monitor supported.
The problem is that from an OS standpoint, it asked for the
modes at bootup time and it doesn’t know that the underlying
monitors have changed. I want to force the OS to do a
DrvGetModes again to get the new modes but I don’t know how
to communicate it back to the OS to do so.
Anyone has any ideas?
While the documentation for EnumDisplaySettings at
http://msdn2.microsoft.com/en-us/library/ms533265.aspx
suggests iModeNum has two special values (-1 and -2 according to
winuser.h), the value ((DWORD)-4) has been handed down to me from
previous generations of programmers as the way to prod Windows to call
DrvGetModes.
lpszDeviceName needs to contain the name of your driver, and lpDevMode
can point to an empty DEVMODE structure with just the dmSize member
filled in with sizeof(DEVMODE).
Hope this helps,
Tim.
Yes that seems to work!! Thanks!!!