[PATCH 1/4] d3d9/tests: Try to make test_cursor_pos more reliable.

[Stefan Dösinger]

Signed-off-by: Stefan Dösinger

---

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);

[PATCH 2/4] d3d8/tests: Try to make test_cursor_pos more reliable.

[Stefan Dösinger]

Signed-off-by: Stefan Dösinger 
---
 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);

[PATCH 2/4] d3d8/tests: Try to make test_cursor_pos more reliable.

[Marvin]

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).

[PATCH 2/4] d3d8/tests: Try to make test_cursor_pos more reliable.

[Henri Verbeet]

Signed-off-by: Henri Verbeet

[PATCH 3/4] d3d9/tests: Skip test_cursor_pos if we can't move the cursor.

[Stefan Dösinger]

Signed-off-by: Stefan Dösinger

---

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");

[PATCH 3/4] d3d9/tests: Skip test_cursor_pos if we can't move the cursor.

[Marvin]

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).

[PATCH 3/4] d3d9/tests: Skip test_cursor_pos if we can't move the cursor.

[Henri Verbeet]

Signed-off-by: Henri Verbeet

[PATCH 4/4] d3d8/tests: Skip test_cursor_pos if we can't move the cursor.

[Stefan Dösinger]

---
 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");

[PATCH 4/4] d3d8/tests: Skip test_cursor_pos if we can't move the cursor.

[Stefan Dösinger]

Signed-off-by: Stefan Dösinger

[PATCH 4/4] d3d8/tests: Skip test_cursor_pos if we can't move the cursor.

[Marvin]

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).

[PATCH 4/4] d3d8/tests: Skip test_cursor_pos if we can't move the cursor.

[Henri Verbeet]

Signed-off-by: Henri Verbeet

[Marvin]

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).

[Stefan Dösinger]

> Am 31.01.2022 um 16:22 schrieb Marvin :
>
> === 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...

[Stefan Dösinger]

> Am 31.01.2022 um 16:40 schrieb Stefan Dösinger :
> > Am 31.01.2022 um 16:22 schrieb Marvin <[e-mail] >:
> >
> > === 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.

[Henri Verbeet]

Signed-off-by: Henri Verbeet