[PATCH v2 1/3] wined3d: Move the window resize during swapchain activation to a separate function.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- dlls/wined3d/swapchain.c | 49 ++++++++++++++++++++++------------ dlls/wined3d/wined3d_private.h | 1 + 2 files changed, 33 insertions(+), 17 deletions(-) diff --git a/dlls/wined3d/swapchain.c b/dlls/wined3d/swapchain.c index 6270c36..8741ed2 100644 --- a/dlls/wined3d/swapchain.c +++ b/dlls/wined3d/swapchain.c @@ -1763,7 +1763,6 @@ void wined3d_swapchain_activate(struct wined3d_swapchain *swapchain, BOOL activa { struct wined3d_device *device = swapchain->device; HWND window = swapchain->state.device_window; - struct wined3d_output_desc output_desc; unsigned int screensaver_active; struct wined3d_output *output; BOOL focus_messages, filter; @@ -1790,22 +1789,7 @@ void wined3d_swapchain_activate(struct wined3d_swapchain *swapchain, BOOL activa if ((device->restore_screensaver = !!screensaver_active)) SystemParametersInfoW(SPI_SETSCREENSAVEACTIVE, FALSE, NULL, 0); - if (!(device->create_parms.flags & WINED3DCREATE_NOWINDOWCHANGES)) - { - /* The d3d versions do not agree on the exact messages here. D3d8 restores - * the window but leaves the size untouched, d3d9 sets the size on an - * invisible window, generates messages but doesn't change the window - * properties. The implementation follows d3d9. - * - * Guild Wars 1 wants a WINDOWPOSCHANGED message on the device window to - * resume drawing after a focus loss. */ - if (SUCCEEDED(hr = wined3d_output_get_desc(output, &output_desc))) - SetWindowPos(window, NULL, output_desc.desktop_rect.left, - output_desc.desktop_rect.top, swapchain->state.desc.backbuffer_width, - swapchain->state.desc.backbuffer_height, SWP_NOACTIVATE | SWP_NOZORDER); - else - ERR("Failed to get output description, hr %#x.\n", hr); - } + wined3d_swapchain_update_window_size(swapchain); if (device->wined3d->flags & WINED3D_RESTORE_MODE_ON_ACTIVATE) { @@ -1849,6 +1833,37 @@ void wined3d_swapchain_activate(struct wined3d_swapchain *swapchain, BOOL activa wined3d_filter_messages(window, filter); } +void wined3d_swapchain_update_window_size(struct wined3d_swapchain *swapchain) +{ + struct wined3d_output_desc output_desc; + struct wined3d_output *output; + HRESULT hr; + + if (swapchain->device->create_parms.flags & WINED3DCREATE_NOWINDOWCHANGES) + return; + + output = wined3d_swapchain_get_output(swapchain); + if (!output) + { + ERR("Failed to get output from swapchain %p.\n", swapchain); + return; + } + + /* The d3d versions do not agree on the exact messages here. D3d8 restores + * the window but leaves the size untouched, d3d9 sets the size on an + * invisible window, generates messages but doesn't change the window + * properties. The implementation follows d3d9. + * + * Guild Wars 1 wants a WINDOWPOSCHANGED message on the device window to + * resume drawing after a focus loss. */ + if (SUCCEEDED(hr = wined3d_output_get_desc(output, &output_desc))) + SetWindowPos(swapchain->state.device_window, NULL, output_desc.desktop_rect.left, + output_desc.desktop_rect.top, swapchain->state.desc.backbuffer_width, + swapchain->state.desc.backbuffer_height, SWP_NOACTIVATE | SWP_NOZORDER); + else + ERR("Failed to get output description, hr %#x.\n", hr); +} + HRESULT CDECL wined3d_swapchain_resize_buffers(struct wined3d_swapchain *swapchain, unsigned int buffer_count, unsigned int width, unsigned int height, enum wined3d_format_id format_id, enum wined3d_multisample_type multisample_type, unsigned int multisample_quality) diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index abc6e0e..2cf4aa6 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -5104,6 +5104,7 @@ struct wined3d_swapchain void wined3d_swapchain_activate(struct wined3d_swapchain *swapchain, BOOL activate) DECLSPEC_HIDDEN; void wined3d_swapchain_cleanup(struct wined3d_swapchain *swapchain) DECLSPEC_HIDDEN; +void wined3d_swapchain_update_window_size(struct wined3d_swapchain *swapchain) DECLSPEC_HIDDEN; struct wined3d_output * wined3d_swapchain_get_output(const struct wined3d_swapchain *swapchain) DECLSPEC_HIDDEN; void swapchain_update_draw_bindings(struct wined3d_swapchain *swapchain) DECLSPEC_HIDDEN; void swapchain_set_max_frame_latency(struct wined3d_swapchain *swapchain, -- 2.21.0
Fixes a regression introduced by commit 82c6ec3a32f44e8b3e0cc88b7f10e0c0d7fa1b89, which caused the WM_ACTIVATEAPP to be sent while the window is minimized, if it has been clicked on in the taskbar to be restored. The behavior is correct wrt Windows, but some games expect the window pos change messages to be sent while they are unminimized, but we only sent it during the WM_ACTIVATEAPP hook. Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- I've added an interactive test in the next patch that the game depends on, and will fail without this patch. dlls/wined3d/device.c | 11 ++++++++--- dlls/wined3d/swapchain.c | 3 ++- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c index b077d53..343df46 100644 --- a/dlls/wined3d/device.c +++ b/dlls/wined3d/device.c @@ -5845,6 +5845,8 @@ void device_invalidate_state(const struct wined3d_device *device, unsigned int s LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL unicode, UINT message, WPARAM wparam, LPARAM lparam, WNDPROC proc) { + unsigned int i; + if (message == WM_DESTROY) { TRACE("unregister window %p.\n", window); @@ -5859,13 +5861,11 @@ LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL } else if (message == WM_ACTIVATEAPP) { - unsigned int i = device->swapchain_count; - /* Deactivating the implicit swapchain may cause the application * (e.g. Deus Ex: GOTY) to destroy the device, so take care to * deactivate the implicit swapchain last, and to avoid accessing the * "device" pointer afterwards. */ - while (i--) + for (i = device->swapchain_count; i--;) wined3d_swapchain_activate(device->swapchains[i], wparam); } else if (message == WM_SYSCOMMAND) @@ -5876,6 +5876,11 @@ LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL DefWindowProcW(window, message, wparam, lparam); else DefWindowProcA(window, message, wparam, lparam); + + /* Heroes of Might and Magic V depends on this being + done after the window has been unminimized. */ + for (i = device->swapchain_count; i--;) + wined3d_swapchain_update_window_size(device->swapchains[i]); } } diff --git a/dlls/wined3d/swapchain.c b/dlls/wined3d/swapchain.c index 8741ed2..32f52b1 100644 --- a/dlls/wined3d/swapchain.c +++ b/dlls/wined3d/swapchain.c @@ -1839,7 +1839,8 @@ void wined3d_swapchain_update_window_size(struct wined3d_swapchain *swapchain) struct wined3d_output *output; HRESULT hr; - if (swapchain->device->create_parms.flags & WINED3DCREATE_NOWINDOWCHANGES) + if (swapchain->device->create_parms.flags & WINED3DCREATE_NOWINDOWCHANGES || + IsIconic(swapchain->state.device_window)) return; output = wined3d_swapchain_get_output(swapchain); -- 2.21.0
Hi, Henri asked me to add my thoughts here because I once wrote most of the focus handling code but so far I am lost. This entire thing is fragile on both Windows and Wine. I'm just dumping some random thoughts here. Maybe it gives you some idea, or some of your answers help me remember some bits: *) I am wondering why the SetWindowPos in wined3d_swapchain_activate in the activate=true case doesn't use SWP_SHOWWINDOW or why there's no ShowWindow(SW_RESTORE) call. *) When testing messages on Windows, be aware that messages that d3d9 generates in response to WM_ACTIVATEAPP appear to be send *before* WM_ACTIVATEAPP because the calls that generate them happen before d3d9 forwards the WM_ACTIVATEAPP message to the original wndproc. *) The test shows that a WM_WINDOWPOSCHANGED message arrives after the window has been put out of iconic state, but the exact sequence isn't clear. Is this message produced by d3d9 or is it e.g. triggered by the taskbar. *) Something that may be tricky to answer: What happens if a non-taskbar event brings the window of HOMM 5 back into the foreground, e.g. a separate process calling SetForegroundWindow? I think alt-tab behaves very similarly to the taskbar. *) Is it possible that there is some WM_SYSCOMMAND specific behavior? d3d9 does hook this particular message. *) On which Linux environment does the regression happen? There may be window manager specific behavior... Stefan Am 30.09.20 um 18:40 schrieb Gabriel Ivăncescu:
Fixes a regression introduced by commit 82c6ec3a32f44e8b3e0cc88b7f10e0c0d7fa1b89, which caused the WM_ACTIVATEAPP to be sent while the window is minimized, if it has been clicked on in the taskbar to be restored. The behavior is correct wrt Windows, but some games expect the window pos change messages to be sent while they are unminimized, but we only sent it during the WM_ACTIVATEAPP hook.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> ---
I've added an interactive test in the next patch that the game depends on, and will fail without this patch.
dlls/wined3d/device.c | 11 ++++++++--- dlls/wined3d/swapchain.c | 3 ++- 2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c index b077d53..343df46 100644 --- a/dlls/wined3d/device.c +++ b/dlls/wined3d/device.c @@ -5845,6 +5845,8 @@ void device_invalidate_state(const struct wined3d_device *device, unsigned int s LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL unicode, UINT message, WPARAM wparam, LPARAM lparam, WNDPROC proc) { + unsigned int i; + if (message == WM_DESTROY) { TRACE("unregister window %p.\n", window); @@ -5859,13 +5861,11 @@ LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL } else if (message == WM_ACTIVATEAPP) { - unsigned int i = device->swapchain_count; - /* Deactivating the implicit swapchain may cause the application * (e.g. Deus Ex: GOTY) to destroy the device, so take care to * deactivate the implicit swapchain last, and to avoid accessing the * "device" pointer afterwards. */ - while (i--) + for (i = device->swapchain_count; i--;) wined3d_swapchain_activate(device->swapchains[i], wparam); } else if (message == WM_SYSCOMMAND) @@ -5876,6 +5876,11 @@ LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL DefWindowProcW(window, message, wparam, lparam); else DefWindowProcA(window, message, wparam, lparam); + + /* Heroes of Might and Magic V depends on this being + done after the window has been unminimized. */ + for (i = device->swapchain_count; i--;) + wined3d_swapchain_update_window_size(device->swapchains[i]); } }
diff --git a/dlls/wined3d/swapchain.c b/dlls/wined3d/swapchain.c index 8741ed2..32f52b1 100644 --- a/dlls/wined3d/swapchain.c +++ b/dlls/wined3d/swapchain.c @@ -1839,7 +1839,8 @@ void wined3d_swapchain_update_window_size(struct wined3d_swapchain *swapchain) struct wined3d_output *output; HRESULT hr;
- if (swapchain->device->create_parms.flags & WINED3DCREATE_NOWINDOWCHANGES) + if (swapchain->device->create_parms.flags & WINED3DCREATE_NOWINDOWCHANGES || + IsIconic(swapchain->state.device_window)) return;
output = wined3d_swapchain_get_output(swapchain);
Hi Stefan, I did more tests (and hacks) to see what Windows does. I'm not entirely sure how to fix it honestly—so I need some tips after I detail it. I'll first try to answer your random thoughts and then give more details/message sequences I observed on Windows. On 01/10/2020 23:35, Stefan Dösinger wrote:
Hi,
Henri asked me to add my thoughts here because I once wrote most of the focus handling code but so far I am lost. This entire thing is fragile on both Windows and Wine.
I'm just dumping some random thoughts here. Maybe it gives you some idea, or some of your answers help me remember some bits:
*) I am wondering why the SetWindowPos in wined3d_swapchain_activate in the activate=true case doesn't use SWP_SHOWWINDOW or why there's no ShowWindow(SW_RESTORE) call.
According to a hack test I did, Windows' d3d9 definitely doesn't restore the window here, so I guess it's correct as far as this is concerned.
*) When testing messages on Windows, be aware that messages that d3d9 generates in response to WM_ACTIVATEAPP appear to be send *before* WM_ACTIVATEAPP because the calls that generate them happen before d3d9 forwards the WM_ACTIVATEAPP message to the original wndproc.
Right, I noticed it now and that does seem to be the case. It doesn't help the game though, because all of this happens while it's minimized.
*) The test shows that a WM_WINDOWPOSCHANGED message arrives after the window has been put out of iconic state, but the exact sequence isn't clear. Is this message produced by d3d9 or is it e.g. triggered by the taskbar.
I think it's both. It's only one message, but it is the size of the fullscreen (swapchain's backbuffer), *not* the size of the restored window, and unfortunately this seems to be important…
*) Something that may be tricky to answer: What happens if a non-taskbar event brings the window of HOMM 5 back into the foreground, e.g. a separate process calling SetForegroundWindow? I think alt-tab behaves very similarly to the taskbar.
Ok so I tested both of these. Alt-tab has the same sequence as clicking on the taskbar (which I'll show below), while if I used a hack and SetForegroundWindow, it doesn't ever restore the window at all. It does receive the WM_ACTIVATEAPP of course, and the window pos messages before it. This happens even if I "unminimize" the window by clearing the WS_MINIMIZE style; it doesn't change anything.
*) Is it possible that there is some WM_SYSCOMMAND specific behavior? d3d9 does hook this particular message.
Yeah, and we already hook/handle it (and my patch does, but now I know it's wrong).
*) On which Linux environment does the regression happen? There may be window manager specific behavior...
I don't think that matters here, and I doubt it's a problem, but I tested it on Compiz with XFCE. Anyway, clearly our current behavior is wrong wrt to Windows, even if the patch that caused this regression is actually correct in that sense. It used to work by luck before. So let me provide some details. First, the requirements: HOMM V expects the window pos messages to arrive after it's been unminimized, and they need to set it to the fullscreen size. In sequences below, it's 1920x1080 (window non-fullscreen size is 640x480). WM_ACTIVATEAPP *does* send window pos messages; it worked before, because we unminimized the window first before activating it. But that's wrong (for other games, like Project CARS, which depend on it). For some reason it sends with SWP_NOMOVE and SWP_NOSIZE. Regardless, I want to touch the current code as little as possible outside of this scenario, since there's also wined3d flags so I assume the behavior is not the same across all versions, and I don't want to mess those up. So here's the sequences. First, I click on the taskbar: WM_WINDOWPOSCHANGING, hwndInsertAfter 00000000, x 0, y 0, cx 0, cy 0, flags SWP_NOSIZE | SWP_NOMOVE WM_WINDOWPOSCHANGED, hwndInsertAfter 00000000, x -32000, y -32000, cx 160, cy 24, flags 00001803 WM_ACTIVATEAPP, wParam 00000001, lParam 00000718 WM_NCACTIVATE, wParam 00200001, lParam 00000000 WM_GETTEXT, wParam 000001FE, lParam 0022F130 WM_ACTIVATE, wParam 00200001, lParam 00000000 WM_SYSCOMMAND, wParam SC_RESTORE, lParam 00000000 WM_QUERYOPEN, wParam 00000000, lParam 00000000 WM_WINDOWPOSCHANGING, hwndInsertAfter 00000000, x 0, y 0, cx 1920, cy 1080, flags SWP_STATECHANGED | SWP_NOCOPYBITS | SWP_FRAMECHANGED WM_GETMINMAXINFO, wParam 00000000, lParam 0022F624 WM_NCCALCSIZE, wParam 00000001, lParam 0022F97C WM_NCPAINT, wParam 00000001, lParam 00000000 WM_GETTEXT, wParam 000001FE, lParam 0022EE20 WM_ERASEBKGND, wParam 01010052, lParam 00000000 WM_WINDOWPOSCHANGED, hwndInsertAfter 00000000, x 0, y 0, cx 1920, cy 1080, flags 00008124 WM_MOVE, wParam 00000000, lParam 00170004 WM_SIZE, wParam 00000000, lParam 041D0778 WM_SETFOCUS, wParam 00000000, lParam 00000000 WM_ACTIVATE, wParam 00000001, lParam 00000000 Now I sent a WM_SYSCOMMAND SC_RESTORE directly and I got: WM_SYSCOMMAND, wParam SC_RESTORE, lParam 00000000 WM_QUERYOPEN, wParam 00000000, lParam 00000000 WM_WINDOWPOSCHANGING, hwndInsertAfter 00000000, x 0, y 0, cx 1920, cy 1080, flags SWP_STATECHANGED | SWP_NOCOPYBITS | SWP_FRAMECHANGED WM_GETMINMAXINFO, wParam 00000000, lParam 0022F5D4 WM_NCCALCSIZE, wParam 00000001, lParam 0022F92C WM_ACTIVATEAPP, wParam 00000001, lParam 00000000 WM_NCACTIVATE, wParam 00000001, lParam 00000000 WM_GETTEXT, wParam 000001FE, lParam 0022EDD0 WM_ACTIVATE, wParam 00000001, lParam 00000000 WM_SETFOCUS, wParam 00000000, lParam 00000000 WM_NCPAINT, wParam 00000001, lParam 00000000 WM_GETTEXT, wParam 000001FE, lParam 0022EDD0 WM_ERASEBKGND, wParam 01010054, lParam 00000000 WM_WINDOWPOSCHANGED, hwndInsertAfter 00000000, x 0, y 0, cx 1920, cy 1080, flags 00008120 WM_MOVE, wParam 00000000, lParam 00170004 WM_SIZE, wParam 00000000, lParam 041D0778 WM_ACTIVATE, wParam 00000001, lParam 00000000 Then I cleared the WS_MINIMIZE style and SetForegroundWindow: WM_WINDOWPOSCHANGING, hwndInsertAfter 00000000, x 0, y 0, cx 0, cy 0, flags SWP_NOSIZE | SWP_NOMOVE WM_WINDOWPOSCHANGED, hwndInsertAfter 00000000, x -32000, y -32000, cx 160, cy 24, flags 00001803 WM_ACTIVATEAPP, wParam 00000001, lParam 000005F4 WM_NCACTIVATE, wParam 00000001, lParam 00000000 WM_GETTEXT, wParam 000001FE, lParam 0022F130 WM_ACTIVATE, wParam 00000001, lParam 00000000 WM_SETFOCUS, wParam 00000000, lParam 00000000 It's interesting to note that not clearing the WS_MINIMIZE style changed nothing at all, except the wParam in WM_ACTIVATE which kept the "minimized" flag (note how this flag also happens in first test, when WM_ACTIVATE is received while it's still minimized). Also note that WM_ACTIVATEAPP in the second case (WM_SYSCOMMAND sent manually) doesn't generate any window pos messages at all. In fact, the behavior prior to the patch that caused this regression works by luck as you can see: we only sent WM_SYSCOMMAND without activating the window first, so WM_ACTIVATEAPP's window pos message worked correctly. ——————————————— My problem now is, I don't know how to fix this. Obviously I'll have to somehow handle this in our SC_RESTORE hook (which we already do, we just call DefWindowProc). However, that would restore the window to its normal restored size (640x480) and not fullscreen. My current patch changes its position again, but that's wrong, as on Windows it's only sent once. Should I hook WM_WINDOWPOSCHANGING and change the position and size to match under this scenario? (i.e. change them to 1920x1080 from 640x480 in that example above) And my other question is: how should I detect in WM_ACTIVATEAPP that we send it with SWP_NOMOVE | SWP_NOSIZE (so it doesn't ruin other versions). Furthermore: WM_ACTIVATEAPP doesn't SetWindowPos again if SYSCOMMAND is sent directly—how to best detect this? Do I use a wined3d flag? A new field, boolean? Or is that too ugly/too much of a hack? Checking for WS_MINIMIZE or IsIconic doesn't work properly, since Windows completely ignores that, so that's a no-go. Thanks, Gabriel
Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- dlls/d3d9/tests/device.c | 55 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c index 53a83ad..4501feb 100644 --- a/dlls/d3d9/tests/device.c +++ b/dlls/d3d9/tests/device.c @@ -11404,6 +11404,35 @@ static void test_writeonly_resource(void) DestroyWindow(window); } +static BOOL test_lost_device_focus_set, test_lost_device_pos_changed_ok; +static WNDPROC test_lost_device_orig_proc; + +static LRESULT CALLBACK test_lost_device_proc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) +{ + switch (msg) + { + case WM_SETFOCUS: + test_lost_device_focus_set = TRUE; + break; + case WM_WINDOWPOSCHANGED: + if (!IsIconic(hwnd)) + { + WINDOWPOS *p = (WINDOWPOS*)lParam; + MONITORINFO mi; + + mi.cbSize = sizeof(mi); + GetMonitorInfoA(MonitorFromWindow(hwnd, MONITOR_DEFAULTTONEAREST), &mi); + + if (p->x == mi.rcMonitor.left && p->y == mi.rcMonitor.top && + p->cx == registry_mode.dmPelsWidth && p->cy == registry_mode.dmPelsHeight && + !(p->flags & (SWP_NOMOVE | SWP_NOSIZE))) + test_lost_device_pos_changed_ok = TRUE; + } + break; + } + return CallWindowProcA(test_lost_device_orig_proc, hwnd, msg, wParam, lParam); +} + static void test_lost_device(void) { struct device_desc device_desc; @@ -11440,6 +11469,32 @@ static void test_lost_device(void) hr = IDirect3DDevice9_Present(device, NULL, NULL, NULL, NULL); ok(hr == D3DERR_DEVICELOST, "Got unexpected hr %#x.\n", hr); + if (winetest_interactive) + { + MSG msg; + + test_lost_device_focus_set = FALSE; + test_lost_device_orig_proc = (WNDPROC)SetWindowLongPtrA(window, GWLP_WNDPROC, (LONG_PTR)test_lost_device_proc); + + trace("Please restore the minimized d3d9_test by clicking on it.\n"); + while (GetMessageA(&msg, NULL, 0, 0) > 0 && !test_lost_device_focus_set) + { + TranslateMessage(&msg); + DispatchMessageA(&msg); + } + while (PeekMessageA(&msg, 0, 0, 0, PM_REMOVE)) + { + TranslateMessage(&msg); + DispatchMessageA(&msg); + } + SetWindowLongPtrA(window, GWLP_WNDPROC, (LONG_PTR)test_lost_device_orig_proc); + + ok(test_lost_device_pos_changed_ok, + "WM_WINDOWPOSCHANGED was never sent with swapchain fullscreen size while window was not minimized.\n"); + ret = SetForegroundWindow(GetDesktopWindow()); + ok(ret, "Failed to set foreground window.\n"); + } + ret = ShowWindow(window, SW_RESTORE); ok(ret, "Failed to restore window.\n"); ret = SetForegroundWindow(window); -- 2.21.0
Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=79582 Your paranoid android. === w1064v1809 (32 bit report) === d3d9: device.c:11466: Test failed: Failed to set foreground window. device.c:11468: Test failed: Got unexpected hr 0. device.c:11470: Test failed: Got unexpected hr 0. device.c:11501: Test failed: Failed to set foreground window. device.c:11503: Test failed: Got unexpected hr 0. device.c:11505: Test failed: Got unexpected hr 0. device.c:11523: Test failed: Failed to set foreground window. device.c:11532: Test failed: Failed to set foreground window. device.c:11547: Test failed: Failed to set foreground window. device.c:11549: Test failed: Got unexpected hr 0. device.c:11553: Test failed: Failed to set foreground window. device.c:14141: Test failed: Adapter 0: SetForegroundWindow failed, error 0. device.c:14147: Test failed: Adapter 0: SetForegroundWindow failed, error 0. === w10pro64_he (32 bit report) === d3d9: device.c:1835: Test failed: The cursor handle is 00010003 === debiant (32 bit report) === d3d9: device.c:4151: Test failed: Expected message 0x46 for window 0, but didn't receive it, i=0. === debiant (32 bit French report) === d3d9: device.c:4151: Test failed: Expected message 0x46 for window 0, but didn't receive it, i=0. === debiant (32 bit Japanese:Japan report) === d3d9: device.c:4151: Test failed: Expected message 0x46 for window 0, but didn't receive it, i=0. === debiant (32 bit Chinese:China report) === d3d9: device.c:4151: Test failed: Expected message 0x46 for window 0, but didn't receive it, i=0. === debiant (32 bit WoW report) === d3d9: device.c:4151: Test failed: Expected message 0x46 for window 0, but didn't receive it, i=0. === debiant (64 bit WoW report) === d3d9: device.c:4151: Test failed: Expected message 0x46 for window 0, but didn't receive it, i=0.
participants (3)
-
Gabriel Ivăncescu -
Marvin -
Stefan Dösinger