PnP Monitors: emulating AMD's behavior of never disconnecting them

Hello,
today I got one very weird question and I was wondering how to answer it, so I thought it was the case to ask some real experts, since I basically know the bare minimum for PnP devices.

Basically, I was asked if it is possible to have a monitor showing in Device Manager even if it is physically disconnected and have no experience with that.

The case in point is that there is an application running which spans multiple displays and when one goes off, it must keep working without getting from Windows any message to move/change layout. It's probably something that has to do with user-level software, but that part is basically a black box to me.

To my surprise, I learned that when you setup EDID emulation on AMD drivers, they become "Generic PnP Monitors" and are actually forever showing, even if I disconnect or disable them.

I have no clue to how they do, though, because my PnP knowledge is limited by practical use.

As far as I know, IRP_MN_SURPRISE_REMOVAL is issued by the PNP Manager when the device is detected as not present anymore, that must be always handled with a STATUS_SUCCESS and after it it looks like it's too late to have it still active and showing, so I was thinking to make a class lower filter driver which simply lies to the bus manager for device relations.

But since everything looks pretty weird to me, I think it's a good idea to ask the community if that's legit and/or if there's a better plan.

What do you think? Is this a stupid question?

Monitors do not have a memory. There is a continuous stream of pixels travelling down whatever path you're using (VGA, HDMI, DP, USB). If that pixel stream is interrupted, the display goes black.

"Generic PnP Monitor" simply means there was enough EDID for the computer to know what resolutions are avaiable. Nothing more.

Some smart televisions have the ability to retain and display the last frame they saw, because they are decoding MPEG streams and already need to keep the last few frames in memory. Monitors don't have that need.

I suspect this is some consequence of 'EDID emulation' with your graphics card. It is hard to say more than that without knowing which card and what other settings that you have

Yes, thanks for the input.

I am just wondering how that can reproduced. Not a lot of clues that don't involve massive intervention.

Reading your message again, it seems that you have some UM app with a GUI that behaves badly when it receives WM_DISPLAYCHANGE / WM_SETTINGCHANGE and related messages that happen when a monitor is unplugged, and you are asking how that sequence can be suppressed?

Then saying that it can be suppressed by another graphics card (some AMD model), and you want to add this feature to your own driver?

No, never talked of user mode.
My interest is purely in what happens to the monitor.

After AMD's EDID emulation, the two monitors appear as "Generic PNP monitor" on Device Manager.

From that point onward, disconnecting a monitor physically doesn't make the device disappear, as if it weren't actually a PNP device.

That indeed has the side effect of not sending WM_DISPLAYCHANGE to user mode, and that's the desirable property I was asked to reproduce without AMD mojo.

I am limited in accessing the machine showing this behaviour, so I thought I could ask if someone around here has maybe more experience with PNP to chime in and say "hey, maybe that can be reproduced by doing XXX!".

I am basically at square one: I studied E-Edid and found nothing which could encode this behaviour. I managed to check the registry hive of the target machine for lower filters because for what I know about PNP, as long as the bus driver does answer properly to a device relations query IRP, the PNP manager won't ask for a surprise removal and this whole mess could be avoided, but it looks to me a crazily complex solution for this question.

Now I'm thinking that a control DO could just interpose and propagate IRPs to the devices, but that's even crazier.

I'm basically looking for a lead. My answer would be "I'll try a lower filter first and then I would write a control DO if that fails", but I wonder if there's a smarter approach to this.

And no, unfortunately it appears that the machine can't run windbg, but I'm all ears anyway (in case I managed to have something reproducing this locally) if there's anything to attempt besides the usual !devnode.

Thank you all for your interest in the issue, at the moment.

If you are asking 'how did AMD do it', then the high level answer seems simple enough. When this mode / setting is activated, instead of reporting the real monitors, it reports 'emulated' monitors. These emulated monitors don't match any real ones, so Windows selects "Generic PNP monitor". And whatever the physical hardware says, their driver never indicates that they go away, so they don't. Probably this is some kind of test mode or designed to be used with task station or industrial hardware

If you are asking how to do the same sort of thing in a driver that you have written / are maintaining, then other than that high level sort of description, and answering specific questions related to a DDI, probably no one here can help much. It is your source.

If you are asking how to do the same sort of thing with any old graphics card, probably you don't.

If you are asking how to do the same sort of thing with a specific graphics card + driver (not manufactured by your company) that might be possible but it won't be easy

If you are asking something else, I am totally confused :wink: