On Wed Apr 19 13:43:11 2023 +0000, Alexandros Frantzis wrote:
changed this line in [version 8 of the diff](/wine/wine/-/merge_requests/2476/diffs?diff_id=43110&start_sha=b50eaef887cd7ca42a510a6975155648ee7aef5e#6cb3a7ca18cce41a1d9a2aba323acf8efde1a178_49_48)
@fox2code @rbernon The intention of constraining the interaction with the host settings to only one process (we choose the desktop process, since that's the one guaranteed to be around), is so that the win32u current display settings are updated from a single, consistent source. This is because Wayland doesn't provide a mechanism to synchronously query the current display state, but rather each process synthesizes the state from wl_output events it receives. These events may come in different order or at different times for different processes, and, lead, at least transiently, to inconsistent display states between processes.
@rbernon I have updated the MR, as you suggested (I think), to request an update of the display devices after process initialization in all processes without internally forcing the UpdateDisplayDevices call. This has the desired effect, and is also in line with how winex11 works.
Note that in upcoming MRs, in which I will add dynamic (i.e., non-initial) Wayland event handling, I will need to reintroduce some of the mechanisms to constrain display device updates to the desktop process. However, checks for this will happen from a context in which we can safely interact with the desktop window (I think it will be possible to just use `NtUserGetDesktopWindow()`, but will need to verify).