On Mon Mar 27 10:05:38 2023 +0000, Rémi Bernon wrote:
An alternative idea I have been toying with is to enhance
`gdi_device_manager.add_mode()` to also take a flag denoting whether to use this is as the registry and/or current mode. The win32u implementation would consult this flag to set the REGISTRY_SETTINGS (if not already set) and/or the CURRENT_SETTINGS. This would also allow us to remove the `init_registry_display_settings` code which is currently duplicated across many drivers. How does that sound? Any other suggestions? Sounds like a good idea to me.
I have updated this branch as discussed above to use the win32u CURRENT_SETTINGS storage mechanism (and also allow setting the REGISTRY_SETTINGS) from within UpdateDisplayDevices.
One question I would like some feedback on, to ensure that this approach is viable going forward:
Since win32u CURRENT_SETTINGS is now the authoritative settings source, I will eventually need to a be able to query these settings from within UpdateDisplayDevices (for example, when the Wine display mode changes, I will need to get the current settings and arrange the monitors in a manner compatible with the Wayland output logical positions). I have experimented with using the usual APIs (NtUserEnumDisplayDevices, NtUserEnumDisplaySettings) from within UpdateDisplayDevices, and with the exception of the possibility for recursion, which we can handle gracefully, this seems to work fine. I just wanted to verify that this would be an acceptable way forward. If not, I would need some other way to query win32u display settings from UpdateDisplayDevices (perhaps gdi_device_manager could be extended for this?).