Re: [PATCH v10 0/6] MR6569: winex11: Refactor window state/config tracker to fix race conditions.

[Rémi Bernon (＠rbernon)]

On Sun Dec  1 21:39:49 2024 +0000, Robbert van der Helm wrote:
> Thanks for the detailed write up! I only ran into this commit after
> bisecting the changes between Wine 9.21 and 9.22, so I'm almost
> certainly missing some context!
> The problem I'm facing seems to be that as soon as `SWP_STATECHANGED` is
> set and `window_set_wm_state()` gets called, `data->wm_state_serial`
> gets stuck on a nonzero value since it's set to the X11 connection's
> next sequence number and is then never cleared again. That causes
> `window_update_client_config()` to always bail before it does anything,
> which in turn causes the `NtUserPostMessage( hwnd,
> WM_WINE_WINDOW_STATE_CHANGED, 0, 0 )` called from
> `X11DRV_ConfigureNotify()` to not do anything anymore.
> This doesn't seem to cause any problems under normal use cases, since
> normally once a window is mapped, its coordinates relative to the root
> window will never suddenly change (not sure if there's a spicy
> interaction with multiple monitors though). But in yabridge I have to
> reparent a Wine window to another window, and to make that work I've
> always had to send these `ConfigureNotify` events to inform Wine about
> the window's actual position on screen. Otherwise it thinks it's located
> in the top left corner of the screen, and all mouse events will be at an offset.
> I can open a regression bug report on bugs.winehq.org, but since what
> yabridge is doing is almost certainly not the ended way to interact with
> Wine, I thought I'd check here first.

`wm_state_serial` should be cleared when the window state actually changes and the `WM_STATE` PropertyNotify event is received, calling `window_wm_state_notify` which clears it.