On Thu Apr 20 02:35:06 2023 +0000, Zhiyi Zhang wrote:
I don't suppose this is what Windows does. But I guess that's why it's a semi-stub. You should be able to read the preferred timing mode from EDID. If that fails, you can fall back to the maximum resolution with the highest frequency. Also, it would be nice to have a test.
Oh yes, rc_monitor reflects current resolution and that's not what we want here, I should be better selecting that from the mode list.
Regarding EDID, are you sure reading that from EDID here worth it now? I think the mode we return here should ideally match what we can be returning elsewhere. We already fill output mode in user32/sysparams.c:set_mode_target_info() based on DEVMODEW. I guess once the difference in timing matters this should ideally match. And normally we should have DEVMODEW modes matches those from EDID. The only part which we don't have correct here is targetVideoSignalInfo.totalSize (which is bigger on Windows even on LCD monitor) and correct pixel clock and horizontal timing. We could fill that from EDID for preferred mode but I doubt it currently affects anything in practice, and whenever it does it is not apparent if reporting the correct timing but not matching QueryDisplayConfig() mode is better. And then if we want to make those timings correct, the modes returned by QueryDisplayConfig() might be not in EDID and to set that fully consistently we might need to relay that info from driver in some way besides EDID probably (e. g., xrandr has the necessary timing information per returned mode).