Repository navigation
[indirect display driver (IDD)] Question: dynamic resolution support and selection at runtime #1400
Description
I have an IDD (non remote) that is supposed to support and select new resolutions at runtime. The idea is that the user resizes their local window, the IDD receives the new resolution, which, of course, can be any value and sets it. But i still want to keep a few defaul resolution e.g: 1280x720, 1600x1200, 1920x1080... so the user can select those manually. So my two options to archive this would be:
- Hot Plug the monitor with a new preferred resolution in the EDID. But every hot plug seems to create new registry entries. Windows automatically sets the preferred resolution for a while until there are too many registry entries; then a random resolution is set. Another downside is that since the monitor is gone for a short amount, a msft display is enabled and open application windows get thrown around.
- Use IddCxMonitorUpdateModes to update the modes at runtime and use a userspace app to select the resolution. I never got this properly to work. If I call IddCxMonitorUpdateModes with the list of old(static) and the new resolution, the monitor goes black for a blink and then is back. But the new resolution does not appear in the windows display settings menu. Also, if I try to set the resolution with SetDisplayConfig, I can only set the sourceMode and not targetMode otherwise the function throws an error. But it seems I also have to set it to targetMode, otherwise the image is distorted. Am I missing something here? The only way this somewhat works is by only sending the preferred resolution, but not the static ones.
I assume that the second option makes more sense. if it works?
Activity
z0Kng commentedon Aug 5, 2026
Yes, I verified that the values passed to
IddCxMonitorUpdateModesare correct, and it returns that it has succeeded. The interesting thing I noticed is that when I create another fake monitor, disable the current monitor (not hotplug, just disable the path) update the modes, enable it again it works correctly.Ix3WUhpgTPE commentedon Aug 17, 2026
Have you tried using the
IddCxMonitorGetModeCountfunction after callingIddCxMonitorUpdateModesto verify if the new modes are actually being registered? It might be useful to log the available modes immediately after your update to check if they include the new resolution or if the call is indeed succeeding without reflecting changes. Additionally, ensure that the mode descriptor you're passing includes the correct attributes, especially the flags related to resolution support.darlcydney26 commentedon Aug 17, 2026
Have you tried validating the mode list structure being passed to
IddCxMonitorUpdateModes? In particular, ensure that the new resolution is correctly formatted and aligns with the expected parameters for width, height, and refresh rates. It might also help to log the values inside the mode list right before the update call to see if they are as expected. Additionally, if the monitor goes black briefly, it suggests a mode switch is happening, but it could be that the new modes are not being registered correctly, so checking the return count withIddCxMonitorGetModeCountright after the update might shed some light on what's occurring.Bbk1AtJJF8 commentedon Oct 18, 2026
After calling IddCxMonitorUpdateModes, have you explicitly triggered a target mode query by returning STATUS_SUCCESS from your EvtIddCxMonitorQueryModes callback to ensure the OS actually reconciles the new mode list against the active display path?
z0Kng commentedon Oct 19, 2026
I found a solution: set SDC_FORCE_MODE_ENUMERATION in SetDisplayConfig so that windows updates the GDI mode list.