Re: [PATCH 2/4] d3d9/tests: Avoid mode changes in d3d9ex' test_lost_device.

[Marvin]

Hi,

While running your changed tests on Windows, 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=9532

Your paranoid android.


=== w8 (32 bit d3d9ex) ===
d3d9ex.c:1276: Test failed: Got unexpected hr 0.
d3d9ex.c:1278: Test failed: Got unexpected hr 0.
d3d9ex.c:1280: Test failed: Got unexpected hr 0.
d3d9ex.c:1282: Test failed: Got unexpected hr 0.

[PATCH 2/4] d3d9/tests: Avoid mode changes in d3d9ex' test_lost_device.

[Henri Verbeet]

On 15 October 2014 00:26, Marvin <testbot(a)winehq.org> wrote:
> === w8 (32 bit d3d9ex) ===
> d3d9ex.c:1276: Test failed: Got unexpected hr 0.
> d3d9ex.c:1278: Test failed: Got unexpected hr 0.
> d3d9ex.c:1280: Test failed: Got unexpected hr 0.
> d3d9ex.c:1282: Test failed: Got unexpected hr 0.

If you really wanted to avoid mode changes in test_lost_device() you'd
have to change reset_device() as well, but the test actually tests for
return codes after a mode change. It doesn't work on the testbot
because IIRC it starts at 1024x768.

[PATCH 2/4] d3d9/tests: Avoid mode changes in d3d9ex' test_lost_device.

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2014-10-15 08:31, schrieb Henri Verbeet:
> If you really wanted to avoid mode changes in test_lost_device()
> you'd have to change reset_device() as well, but the test actually
> tests for return codes after a mode change. It doesn't work on the
> testbot because IIRC it starts at 1024x768.
> Right, the S_PRESENT_MODE_CHANGED should have alerted me. Do you have
> any idea why a successful reset brings the device into this state?

Does reset_device call IDirect3DDevice9_Reset (instead of ResetEx)
intentionally? The IDirect3DDevice9_ part suggests that it is
unintentional, but in the context of the patch that added it
(2f307a14) it makes some sense.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJUPi5dAAoJEN0/YqbEcdMw1ZsP/R1OAUNjZXaOIY8QaJAoIcX4
uJ49wcqwq3hmbkGIsienoGv2FJ6Bap6QHzbTCbu4O17eBwYrr2wWi8KV2yqwi8pE
HMzUpvbLDxVHlmsMkfLSFG/PBSXS1biLAd0pgYgwzS3JlKx+eTTdhyyx+UoneV4s
2aSzJXq2hsoz3FFGJAiJ6/0rl3c8aI/ZbNC4i96PoXAPiURanLtnX0TlhIc6ZZEt
JKxJbxbugOlULsnIVwGRFP2suqPkLl6w4n9x9GKQSa2mSqoO/JoIg94uAkQ5DcZb
PUCnz/6n/gW6SrGQqN+4oUR1gnZu/Gk3bdiyZWVYSh7tsTBJHEt1uzsGoAAa/6xp
MXVM8nJzEEK6aUoDOa6QIliwrZhCLD8RKZwbtnXytWPUzSK/307D24ryRTYPqNLO
QUy6l+3YXhaHYl9fHqjfl9d7K/zBfHiAtk6u9xPda6dTWoopzj3QNeifE4rmYmvc
4gSui3Hj/miCA9zcoifmK5LxgWqbcWgqTx4DT7Rxdic43MpBZMeXM5gVonPcvhOn
Nl4of5VE+W5j/hv+p81ATyUM9KP+ydNQws02lEcS+747Y09Z3ubWTk98f9oKBBQP
l6tuoKAWIS6skcZWc1PBX0wCcqIkaMuhe7qdoo/tJObvd11LbMwutnNg2ZANyAjD
HaIh1E96ApXoB9TjGhuw
=EzVW
-----END PGP SIGNATURE-----

[PATCH 2/4] d3d9/tests: Avoid mode changes in d3d9ex' test_lost_device.

[Henri Verbeet]

On 15 October 2014 10:20, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
> Am 2014-10-15 08:31, schrieb Henri Verbeet:
> > If you really wanted to avoid mode changes in test_lost_device()
> > you'd have to change reset_device() as well, but the test actually
> > tests for return codes after a mode change. It doesn't work on the
> > testbot because IIRC it starts at 1024x768.
> > Right, the S_PRESENT_MODE_CHANGED should have alerted me. Do you have
> > any idea why a successful reset brings the device into this state?

I'm not entirely sure, but my guess would be that it has something to
do with the order between resizing the swapchain buffers and the mode
change.
> Does reset_device call IDirect3DDevice9_Reset (instead of ResetEx)
> intentionally? The IDirect3DDevice9_ part suggests that it is
> unintentional, but in the context of the patch that added it
> (2f307a14) it makes some sense.

It was intentional, although it probably wouldn't hurt to have some
more tests for ResetEx() as well.