I don't really know what you need to keep with each mode
The (portable) properties I would like to be able to store and retrieve are per device rather than per mode, hence the idea for some new win32u API to set/get per device private data which would be stored in the registry (the set part could actually be part of the `struct gdi_adapter` setup). The other requirement is that I would need to access the data from arbitrary points in the driver, not just from within a display settings change context.
I guess I could store the per-device properties in DEVMODEW driver extra data (and retrieve it by getting any mode, e.g., the current), although this seems to be a somewhat roundabout way to deal with per device properties. On the other hand, this would be just a driver implementation detail, and would avoid any extra APIs, so perhaps it's not too bad. One (theoretical) problem would be how to deal with a device doesn't have any modes (e.g., not connected), but that can never happen in the Wayland driver, since only connected outputs are advertised by the compositor and exposed to Wine. Thoughts?
Note that per device private data will not be needed until a later MR, but I would like to ensure there is a reasonable/acceptable way to implement this, so that I don't paint myself into a (design) corner.
Concerning storing CURRENT_SETTINGS in the registry:
Of course that's not necessarily in sync with the host settings, and needs to be updated on external changes.
I have been experimenting with a way to set CURRENT_SETTINGS from within the driver for the initial display device configuration (and on host settings change).
Initially I tried to use a `NtUserChangeDisplaySettings()` call (like we do in `init_registry_display_settings`), combined with returning E_NOTIMPL from WAYLAND_ChangeDisplaySettings, but this has proved problematic since the initial device configuration may occur at (desktop) process startup. At that time it seems it's not possible to invoke `GetDesktopWindow()` and `send_message(WM_DISPLAYCHANGE)` which the `NtUserChangeDisplaySettings()` implementation in win32u tries to do.
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?
Thanks!