Monitor (re)enumeration

NTDEV
1

Hi everyone, I’m new to this list but a longtime subscriber to NTFSD.

I did some searching in the list archive about an issue I’m researching, but
didn’t find an answer to my problem, which is:

When the PnP subsystem loads the Video Port, which then calls the Video
Miniport, which then enumerates child devices (such as monitors) a PnP
monitor may not be switched on yet. In that case the registry does not
receive valid, updated EDID (PnP) data for the monitor. I am looking for a
way to force all video miniports to re-enumerate child device at a time
determined by a user mode application (DLL, etc), so that I can get accurate
info about attached PnP-compatible displays.

What would be the least kludgey way of doing this? :wink:

Regards

Joe Wein

Yokohama, JP

2

The generic way of forcing device re-enumerating device in user mode is
using CM_xxx functions: CM_Locate_DevNode/CM_Reenumerate_DevNode. It will
cause IRP_MN_QUERY_DEVICE_RELATIONS(BusRelations) being sent to the root
tree specified in CM_Reenumerate_DevNode. Bus driver then would report
child(ren).

As for video miniport, the mileage may vary. Video miniport (at least ours)
in some conditions may NOT report child devices in response to an
IRP_MN_QUERY_DEVICE_RELATIONS; rather, it may trigger another enumeration in
its set_mode logic and report children in latter QDR. Believe me; you don't
want to know the reasons for doing that-:). If that was the case, you just
simply call a ChangeDisplaySettings(Ex) to trigger a SetMode.

HTH,
Calvin

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com

-----Original Message-----
From: Joe Wein [mailto:xxxxx@gmx.net]
Sent: September 21, 2004 10:40 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Monitor (re)enumeration

Hi everyone, I'm new to this list but a longtime subscriber to NTFSD.

I did some searching in the list archive about an issue I'm researching, but
didn't find an answer to my problem, which is:

When the PnP subsystem loads the Video Port, which then calls the Video
Miniport, which then enumerates child devices (such as monitors) a PnP
monitor may not be switched on yet. In that case the registry does not
receive valid, updated EDID (PnP) data for the monitor. I am looking for a
way to force all video miniports to re-enumerate child device at a time
determined by a user mode application (DLL, etc), so that I can get accurate
info about attached PnP-compatible displays.

What would be the least kludgey way of doing this? :wink:

Regards

Joe Wein

Yokohama, JP

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

You are currently subscribed to ntdev as: xxxxx@ati.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Joe,

Check out this KB article HOWTO: Force Reenumeration of a Device Tree From
an Application (
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q259697)

HTH,
Bandeep

“Joe Wein” wrote in message news:xxxxx@ntdev…
> Hi everyone, I’m new to this list but a longtime subscriber to NTFSD.
>
> I did some searching in the list archive about an issue I’m researching,
but
> didn’t find an answer to my problem, which is:
>
> When the PnP subsystem loads the Video Port, which then calls the Video
> Miniport, which then enumerates child devices (such as monitors) a PnP
> monitor may not be switched on yet. In that case the registry does not
> receive valid, updated EDID (PnP) data for the monitor. I am looking for a
> way to force all video miniports to re-enumerate child device at a time
> determined by a user mode application (DLL, etc), so that I can get
accurate
> info about attached PnP-compatible displays.
>
> What would be the least kludgey way of doing this? :wink:
>
> Regards
>
> Joe Wein
>
> Yokohama, JP
>
>
>