[PATCH 1/4] d3d9/tests: Try to make test_cursor_pos more reliable.
Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com> --- The Win10 1709 behavior and apparent workaround of moving the pointer before the test don't quite make sense. In past testbot runs there have been cases where e.g. move 3 doesn't produce a message, or any other move. This patch has worked so far in all of my manual testbot submissions. The only way to know is to wait and see... I have sent this series on top of 225041 and 225042, but it should apply independently as well. --- dlls/d3d9/tests/device.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c index 7effd0f28b8..9c2e94cc694 100644 --- a/dlls/d3d9/tests/device.c +++ b/dlls/d3d9/tests/device.c @@ -5205,6 +5205,20 @@ static void test_cursor_pos(void) {0, 0}, }; + /* Windows 10 1709 is unreliable. One or more of the cursor movements we + * expect don't show up. Moving the mouse to a defined position beforehand + * seems to get it into better shape - only the final 150x150 move we do + * below is missing - it looks as if this Windows version filters redundant + * SetCursorPos calls on the user32 level, although I am not entirely sure. + * + * The weird thing is that the previous test leaves the cursor position + * reliably at 512x384 on the testbot. So the 50x50 mouse move shouldn't + * be stripped away anyway, but it might be a difference between moving the + * cursor through SetCursorPos vs moving it by changing the display mode. */ + ret = SetCursorPos(99, 99); + ok(ret, "Failed to set cursor position.\n"); + flush_events(); + wc.lpfnWndProc = test_cursor_proc; wc.lpszClassName = "d3d9_test_cursor_wc"; ok(RegisterClassA(&wc), "Failed to register window class.\n"); @@ -5239,7 +5253,8 @@ static void test_cursor_pos(void) IDirect3DDevice9_SetCursorPosition(device, 75, 75, 0); flush_events(); - /* SetCursorPosition() eats duplicates. */ + /* SetCursorPosition() eats duplicates. FIXME: Since we accept unexpected + * mouse moves the test doesn't actually demonstrate that. */ IDirect3DDevice9_SetCursorPosition(device, 75, 75, 0); flush_events(); @@ -5260,13 +5275,14 @@ static void test_cursor_pos(void) IDirect3DDevice9_SetCursorPosition(device, 150, 150, 0); flush_events(); - /* SetCursorPos() doesn't. */ + /* SetCursorPos() doesn't. Except for Win10 1709. */ ret = SetCursorPos(150, 150); ok(ret, "Failed to set cursor position.\n"); flush_events(); - ok(!expect_pos->x && !expect_pos->y, "Didn't receive MOUSEMOVE %u (%d, %d).\n", - (unsigned)(expect_pos - points), expect_pos->x, expect_pos->y); + ok((!expect_pos->x && !expect_pos->y) || broken(expect_pos - points == 7), + "Didn't receive MOUSEMOVE %u (%d, %d).\n", + (unsigned)(expect_pos - points), expect_pos->x, expect_pos->y); refcount = IDirect3DDevice9_Release(device); ok(!refcount, "Device has %u references left.\n", refcount); -- 2.34.1
Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com> --- dlls/d3d8/tests/device.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c index c288e1ef557..f30e0784e8b 100644 --- a/dlls/d3d8/tests/device.c +++ b/dlls/d3d8/tests/device.c @@ -1235,6 +1235,20 @@ static void test_cursor_pos(void) {0, 0}, }; + /* Windows 10 1709 is unreliable. One or more of the cursor movements we + * expect don't show up. Moving the mouse to a defined position beforehand + * seems to get it into better shape - only the final 150x150 move we do + * below is missing - it looks as if this Windows version filters redundant + * SetCursorPos calls on the user32 level, although I am not entirely sure. + * + * The weird thing is that the previous test leaves the cursor position + * reliably at 512x384 on the testbot. So the 50x50 mouse move shouldn't + * be stripped away anyway, but it might be a difference between moving the + * cursor through SetCursorPos vs moving it by changing the display mode. */ + ret = SetCursorPos(99, 99); + ok(ret, "Failed to set cursor position.\n"); + flush_events(); + wc.lpfnWndProc = test_cursor_proc; wc.lpszClassName = "d3d8_test_cursor_wc"; ok(RegisterClassA(&wc), "Failed to register window class.\n"); @@ -1267,7 +1281,8 @@ static void test_cursor_pos(void) IDirect3DDevice8_SetCursorPosition(device, 75, 75, 0); flush_events(); - /* SetCursorPosition() eats duplicates. */ + /* SetCursorPosition() eats duplicates. FIXME: Since we accept unexpected + * mouse moves the test doesn't actually demonstrate that. */ IDirect3DDevice8_SetCursorPosition(device, 75, 75, 0); flush_events(); @@ -1288,13 +1303,14 @@ static void test_cursor_pos(void) IDirect3DDevice8_SetCursorPosition(device, 150, 150, 0); flush_events(); - /* SetCursorPos() doesn't. */ + /* SetCursorPos() doesn't. Except for Win10 1709. */ ret = SetCursorPos(150, 150); ok(ret, "Failed to set cursor position.\n"); flush_events(); - ok(!expect_pos->x && !expect_pos->y, "Didn't receive MOUSEMOVE %u (%d, %d).\n", - (unsigned)(expect_pos - points), expect_pos->x, expect_pos->y); + ok((!expect_pos->x && !expect_pos->y) || broken(expect_pos - points == 7), + "Didn't receive MOUSEMOVE %u (%d, %d).\n", + (unsigned)(expect_pos - points), expect_pos->x, expect_pos->y); refcount = IDirect3DDevice8_Release(device); ok(!refcount, "Device has %u references left.\n", refcount); -- 2.34.1
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=106590 Your paranoid android. === debian11 (32 bit Hebrew:Israel report) === d3d8: device.c:3176: Test failed: Got unexpected screen size 640x480. device.c:3200: Test failed: Got unexpected screen size 640x480. device.c:3225: Test failed: Got unexpected width 640. device.c:3226: Test failed: Got unexpected height 480. device.c:10724: Test failed: Adapter 0: Expect window rect (0,0)-(640,480), got (0,0)-(1024,768). device.c:10724: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (640,0)-(1280,480). === debian11 (32 bit Hindi:India report) === d3d8: device.c:3191: Test failed: Expected message 0x1c for window 0x1, but didn't receive it, i=2. device.c:3353: Test failed: Expected message 0x1c for window 0x1, but didn't receive it === debian11 (32 bit Japanese:Japan report) === d3d8: device.c:3191: Test failed: Expected message 0x1c for window 0x1, but didn't receive it, i=2. device.c:10724: Test failed: Adapter 0: Expect window rect (0,0)-(640,480), got (4,14)-(644,494). === debian11 (32 bit Chinese:China report) === d3d8: device.c:3191: Test failed: Expected message 0x3 for window 0, but didn't receive it, i=2. device.c:10754: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (0,0)-(1024,737).
Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>
Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com> --- There is another failure more of this test inside a virtual desktop that happens in situations where we can move the mouse around. I am still investigating this. --- dlls/d3d9/tests/device.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c index 9c2e94cc694..7abf9ea3df2 100644 --- a/dlls/d3d9/tests/device.c +++ b/dlls/d3d9/tests/device.c @@ -5188,6 +5188,7 @@ static void test_cursor_pos(void) HWND window; HRESULT hr; BOOL ret; + POINT pt; /* Note that we don't check for movement we're not supposed to receive. * That's because it's hard to distinguish from the user accidentally @@ -5219,6 +5220,18 @@ static void test_cursor_pos(void) ok(ret, "Failed to set cursor position.\n"); flush_events(); + /* Check if we can move the cursor. If we're running in a virtual desktop + * that does not have focus or the mouse is outside the desktop window, some + * window managers (e.g. kwin) will refuse to let us steal the pointer. That + * is reasonable, but breaks the test. */ + ret = GetCursorPos(&pt); + ok(ret, "Failed to get cursor position.\n"); + if (pt.x != 99 || pt.y != 99) + { + skip("Could not warp the cursor (cur pos %ux%u), skipping test.\n", pt.x, pt.y); + return; + } + wc.lpfnWndProc = test_cursor_proc; wc.lpszClassName = "d3d9_test_cursor_wc"; ok(RegisterClassA(&wc), "Failed to register window class.\n"); -- 2.34.1
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=106591 Your paranoid android. === debian11 (32 bit French report) === d3d9: device.c:5445: Test failed: Expected resolution 640x480, got 800x600. device.c:5475: Test failed: Expected resolution 640x480, got 800x600. device.c:14640: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (640,0)-(1280,480). === debian11 (32 bit Hebrew:Israel report) === d3d9: device.c:5445: Test failed: Expected resolution 640x480, got 720x480. device.c:5475: Test failed: Expected resolution 640x480, got 720x480. device.c:14640: Test failed: Adapter 0: Expect window rect (0,0)-(720,480), got (4,14)-(644,494). === debian11 (32 bit Hindi:India report) === d3d9: device.c:14640: Test failed: Adapter 1: Expect window rect (720,0)-(1744,737), got (4,14)-(644,494). device.c:14706: Test failed: Adapter 1: Expect window rect (720,0)-(1744,737), got (0,0)-(1024,737). === debian11 (32 bit Chinese:China report) === d3d9: device.c:14640: Test failed: Adapter 0: Expect window rect (0,0)-(720,480), got (4,15)-(644,495). device.c:14640: Test failed: Adapter 1: Expect window rect (720,0)-(1744,737), got (720,0)-(1360,480). === debian11 (32 bit WoW report) === d3d9: device.c:5475: Test failed: Expected resolution 1024x768, got 720x480. === debian11 (64 bit WoW report) === d3d9: device.c:14640: Test failed: Adapter 0: Expect window rect (0,0)-(1024,768), got (0,0)-(640,480).
Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>
--- dlls/d3d8/tests/device.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c index f30e0784e8b..cb1e83b64b3 100644 --- a/dlls/d3d8/tests/device.c +++ b/dlls/d3d8/tests/device.c @@ -1218,6 +1218,7 @@ static void test_cursor_pos(void) HWND window; HRESULT hr; BOOL ret; + POINT pt; /* Note that we don't check for movement we're not supposed to receive. * That's because it's hard to distinguish from the user accidentally @@ -1249,6 +1250,18 @@ static void test_cursor_pos(void) ok(ret, "Failed to set cursor position.\n"); flush_events(); + /* Check if we can move the cursor. If we're running in a virtual desktop + * that does not have focus or the mouse is outside the desktop window, some + * window managers (e.g. kwin) will refuse to let us steal the pointer. That + * is reasonable, but breaks the test. */ + ret = GetCursorPos(&pt); + ok(ret, "Failed to get cursor position.\n"); + if (pt.x != 99 || pt.y != 99) + { + skip("Could not warp the cursor (cur pos %ux%u), skipping test.\n", pt.x, pt.y); + return; + } + wc.lpfnWndProc = test_cursor_proc; wc.lpszClassName = "d3d8_test_cursor_wc"; ok(RegisterClassA(&wc), "Failed to register window class.\n"); -- 2.34.1
Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com>
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=106592 Your paranoid android. === debian11 (32 bit Hindi:India report) === d3d8: device.c:3189: Test failed: Got unexpected screen size 640x480. device.c:3204: Test failed: Expected message 0x1c for window 0x1, but didn't receive it, i=1. device.c:3213: Test failed: Got unexpected screen size 640x480. device.c:3238: Test failed: Got unexpected width 640. device.c:3239: Test failed: Got unexpected height 480. device.c:3366: Test failed: Expected message 0x1c for window 0x1, but didn't receive it device.c:4358: Test failed: Expected resolution 1024x768, got 640x480. device.c:4388: Test failed: Expected resolution 1024x768, got 640x480. device.c:10737: Test failed: Adapter 0: Expect window rect (0,0)-(640,480), got (4,14)-(644,494). === debian11 (32 bit Japanese:Japan report) === d3d8: device.c:3204: Test failed: Expected message 0x1c for window 0x1, but didn't receive it, i=2. === debian11 (32 bit Chinese:China report) === d3d8: device.c:3204: Test failed: Expected message 0x3 for window 0, but didn't receive it, i=2. device.c:3366: Test failed: Expected message 0x1c for window 0x1, but didn't receive it device.c:10737: Test failed: Adapter 0: Expect window rect (0,0)-(640,480), got (0,0)-(1024,768). device.c:10767: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (0,0)-(1024,737).
Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>
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=106589 Your paranoid android. === w864 (64 bit report) === d3d9: device.c:4343: Test failed: Received WM_WINDOWPOSCHANGED but did not expect it, i=0. === w1064_2qxl (64 bit report) === d3d9: device.c:5275: Test failed: Didn't receive MOUSEMOVE 0 (50, 50). === debian11 (32 bit Hebrew:Israel report) === d3d9: device.c:2175: Test failed: Screen width is 640 === debian11 (32 bit Hindi:India report) === d3d9: device.c:14627: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (640,0)-(1280,480). === debian11 (32 bit Chinese:China report) === d3d9: device.c:14627: Test failed: Adapter 0: Expect window rect (0,0)-(640,480), got (4,15)-(644,495). device.c:14627: Test failed: Adapter 1: Expect window rect (640,0)-(1664,737), got (640,0)-(1280,480).
Am 31.01.2022 um 16:40 schrieb Stefan Dösinger <stefan(a)codeweavers.com>:
Am 31.01.2022 um 16:22 schrieb Marvin <testbot(a)winehq.org <mailto:testbot(a)winehq.org>>:
=== w1064_2qxl (64 bit report) ===
d3d9: device.c:5275: Test failed: Didn't receive MOUSEMOVE 0 (50, 50).
*sigh*
Apparently there is a failure mode of this test that I missed...
That said, it failed once on one testbot VM for the 4 patches I submitted. It is a noticeable improvement over the previous situation.
participants (4)
-
Henri Verbeet -
Marvin -
Stefan Dösinger -
Stefan Dösinger