On Thu Mar 30 18:17:17 2023 +0000, Alexandros Frantzis wrote:
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?).
I'd suggest moving the `add_mode` change to a separate MR and splitting it more, keeping driver changes separate and moving code around (for instance in winemac) before doing actual logic changes.
I'm also not sure to see why you need to separate registry initialization from current mode. I'd think that you could just have a `BOOL current` argument, which may be true while enumerating the modes, and in which case in addition to adding the mode to the list, it would also write the `ENUM_CURRENT_SETTINGS` index, and, if not set yet, the `ENUM_REGISTRY_SETTINGS` too.
If, for some reason, the current mode may not be one of the enumerated modes, then maybe a separate `set_current_mode` callback would be better than overriding `add_mode`. And it would set the `ENUM_CURRENT_SETTINGS` and `ENUM_REGISTRY_SETTINGS` the same way as described above.