On Fri Mar 24 18:20:18 2023 +0000, Alexandros Frantzis wrote:
I will need to think about (and experiment with) this a bit more, but
at the very least I think I would need to be able to attach (and be able to retrieve from any process) some driver-specific display device properties (the Wayland output name it corresponds to, the compositor scale and native mode etc). Any suggestions about how to achieve the above, without manually digging into the registry from the driver? Would some kind of small API exported from win32u.so for driver use be an acceptable option, so I can reuse some of the registry code from there? For example, something along the lines of {set|get}_display_device_private_data(device) to store/retrieve some blob of data from the proper registry key?
I don't really know what you need to keep with each mode, I think `winex11` currently simply looks the mode again in its host mode list, caching it to avoid unnecessary enumeration. A simple solution would be to do the same.
Otherwise, each `DEVMODEW` can also carry private driver data after it, and there's a `dmDriverExtra` field that indicates its size.
Assuming the driver data is portable (which isn't the case with every `winex11` modes currently) across architectures and processes, the private data could be saved into the registry when enumerating and caching available modes, and passed back to the driver when applying display settings on display settings change.
Note that this is not currently implemented and driver extra data isn't saved, but I think it should be easy to add.