On Mon Apr 13 08:10:07 2026 +0000, Rémi Bernon wrote:
Hmm... in theory this might happen even if monitor indices have changed, for instance if somehow monitor location are swapped and window end up at the exact same location, but maybe we can be optimistic? We could decide to stop serializing when the _NET_WM_FULLSCREEN_MONITORS property update is received [^1], but there might still already be some ConfigureNotify event in flight that we will receive shortly after and that might confuse us, though hopefully it'll match our expected window position and should then be ignored. We could also check whether the monitor indices have changed or not, and only expect a reconfigure when they did, but then it also raises the question to why we need to update the monitor indices in that case. It seems to me that this is something the WM should implement: if the monitor indices are the same there should be no need for applications to update the property again. The XRandR monitors mapped to these indices might change when displays are rearranged, but the WM should keep the window mapped to the monitor matching the indices set by the window at all time, and eventually move it around on its own if necessary. In general I feel that this can only work when XRandR monitors don't actually change (ie: with modesetting emulation), as handling actual monitor rearrangement reliably would require many more race conditions that aren't mitigated right now. For instance we would need to make sure we wait for actual monitor placement update before moving our windows, as we might otherwise not have the Win32 monitor correctly positioned and might expect incorrect window configs. [^1]: I decided to reuse the window config serialization in order to avoid introducing a fourth dimension to the already complicated ConfigureNotify serialization logic (in addition to window configure requests, _NET_WM_STATE induced configs and _MOTIF_WM_HINTS induced configs). Is serializing \_NET_WM_FULLSCREEN_MONITORS necessary for fixing some application bugs? If not, it might be better not to have it now. I worry that the third patch might block things like window_update_client_config() and window_update_client_state().
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10620#note_136704