http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #16 from Rémi Bernon rbernon@codeweavers.com --- Regarding the logs with openbox and jwm, it looks like some window manager bug. The trace:
0134:0138:trace:x11drv:window_set_wm_state window 0x20060/1a00001, requesting WM_STATE 0 -> 0x1 serial 115, foreground 0x10020, activate 1
Indicates that we request a WM_STATE property change from Withdrawn to Normal to it, to show the game window, but it never replies with the expected WM_STATE property change and we're unable to assume that the window has been shown and continue requests.
This is basic ICCCM protocol, and we can only work with mostly compliant window managers (or you need to uncheck "Allow the window manager to control the windows" in winecfg.
I'm actually surprised if openbox doesn't work, because I've even been testing our code with it and it should be behaving correctly, at least for this step.
In the log with fluxbox this works as expected:
0138:013c:trace:x11drv:window_set_wm_state window 0x20060/5200001, requesting WM_STATE 0 -> 0x1 serial 115, foreground 0x10020, activate 1 ... 0138:013c:trace:x11drv:handle_state_change window 0x20060/5200001 WM_STATE 0x1/138, expected 0x1/115
but then it looks like there's some shenanigans happening with active window:
0138:013c:trace:x11drv:set_net_active_window requesting _NET_ACTIVE_WINDOW 0x20060/5200001 serial 161 ... 0138:013c:warn:x11drv:handle_state_change Ignoring old _NET_ACTIVE_WINDOW 0x20060/5200001 serial 139 time 5971560, expected 0x20060/5200001 serial 161 ... 0138:013c:warn:x11drv:handle_state_change mismatch _NET_ACTIVE_WINDOW 0x10020/4000009 serial 221 time 5980319, expected 0x20060/5200001 serial 161
We requested activation of the game window, (in addition and after it being shown, which triggers the first _NET_ACTIVE_WINDOW we ignore), but the window manager decides to give focus to another window instead, and we translate this to a focus change to the desktop (0x10020/4000009) window as we always do when Wine lose focus.
On the Win32 side, games often handle focus loss by minimizing themselves, which is what the game is doing there:
0138:013c:trace:x11drv:X11DRV_GetWindowStateUpdates hwnd 0x20060, returning state_cmd 0, swp_flags 0, rect (0,0)-(2560,1440), foreground 0x10020 ... 0138:013c:trace:x11drv:window_set_wm_state window 0x20060/5200001, requesting WM_STATE 0x1 -> 0x3 serial 228, foreground (nil), activate 0 ... 0138:013c:trace:x11drv:handle_state_change window 0x20060/5200001 WM_STATE 0x3/232, expected 0x3/228
Then I'm not sure what happens next, but it looks like we fall into a focus restoration / loss loop, causing endless window minimization / restoration. I'm suspecting maybe some requests we do to focus the desktop/root window should be avoided, I'll try making a patch for this.