Re: d3drm/tests: Skip following tests when device creation fails.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-10-15 um 21:54 schrieb Bernhard Übelacker:
hr = IDirect3DRM3_CreateDeviceFromClipper(d3drm, pClipper, &driver, rc.right, rc.bottom, &device); ok(hr == D3DRM_OK, "Cannot get IDirect3DRMDevice interface (hr = %x)\n", hr); + if (FAILED(hr)) + { + skip("Cannot get IDirect3DRMDevice interface (hr = %x), skipping tests\n", hr); + IDirectDrawClipper_Release(pClipper); + IDirect3DRM_Release(d3drm); + DestroyWindow(window); + return; + }
The test will fail regardless, so you don't gain too much. It would be nicer if the test skips without a failing ok() statement in this case. Do you have a Windows VM to test how native d3drm responds if d3d is not available? I.e., which error code is returned? It might be a bit tricky to test because we request a software device that Wine doesn't implement but should be available everywhere on Windows. If you need help finding that out I can play a bit with my Windows XP box. (Technically failing is correct because we should have a software device without host GL in theory, but I don't expect that we'll ever implement one, so I think not failing the test if GL isn't available is the best thing to do) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWINx5AAoJEN0/YqbEcdMwcDYP/1mLNoDkllStJ4gySEeUgfxK QUuTt7vIFiWGVl8/x9QUsO9dWakZ+2fPZJSl3cO8cUxuk/GbpwmKNYFG3IEcQUIo 1nTn5aM6kTxv4b+uVT2BnX/CwJLouQnjuFnsTxTORJad1WsPk/qTVcPAmknnTPlX uHs30ed8QBm7ZWwi+549rQfFeGjp41xf05BVqjtSILtIhPiRYfnfsXAV/zFmUPMB hCG3QtaSL4Ea4zS3aEr0II0aV6TcSSY1t+V0+SvCuZEgZDKbYF5qbEeKRiXubdga mQEtEWcun0NUwtRD7ftNA6Ad5WumHUv3hj3fwb0q4hA0AtjvsW1L4zuYQs/DVb2v T/vpyZLowUpUn4peTOwuNU5rBeUY9BRqeoqcE1ccyVUFQ2nt6Iq3XJGvzjRWf3RT e5j1F9OyM31j8eDTVRO3Vr5SXqH3yDiwzSoLPJzTrE9AV4r1hj30Vb7MWjlqmOlq 03P83KwPDyNg5JBtr7R6a9TxQn7zhfZNzHctuJWI2ZSvXhbPTHgh0GZd1ka9ITkT 273sIi/VKU8e1HoBz5zTnGHYgE3utdqBk6RHVzSk/L+fhsVxD8LccyytRs7de+ai 7ut0IFuLsM3jd22g9FF3PTmpgZx3nEDUn0WN628hQO4w+Lf7w+MUmGslHMSrqx1r yiscxon1fyODz+BewWKG =NOTo -----END PGP SIGNATURE-----
On 16 October 2015 at 13:16, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
(Technically failing is correct because we should have a software device without host GL in theory, but I don't expect that we'll ever implement one, so I think not failing the test if GL isn't available is the best thing to do) You could always use something like Mesa softpipe or llvmpipe for OpenGL. This is a configuration issue, IMO.
Am 16.10.2015 um 13:16 schrieb Stefan Dösinger:
The test will fail regardless, so you don't gain too much. It would be nicer if the test skips without a failing ok() statement in this case.
Do you have a Windows VM to test how native d3drm responds if d3d is not available? I.e., which error code is returned? It might be a bit tricky to test because we request a software device that Wine doesn't implement but should be available everywhere on Windows. If you need help finding that out I can play a bit with my Windows XP box.
(Technically failing is correct because we should have a software device without host GL in theory, but I don't expect that we'll ever implement one, so I think not failing the test if GL isn't available is the best thing to do)
Am 16.10.2015 um 13:33 schrieb Henri Verbeet:
On 16 October 2015 at 13:16, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
(Technically failing is correct because we should have a software device without host GL in theory, but I don't expect that we'll ever implement one, so I think not failing the test if GL isn't available is the best thing to do) You could always use something like Mesa softpipe or llvmpipe for OpenGL. This is a configuration issue, IMO.
Thanks for your answers. My intent was just to avoid the test crashing when it accesses the not created device. Therefore the skip is after the failing ok() statement. And having no GL in Xephyr seems to be caused by using the nvidia proprietary driver. Adjusting LD_LIBRARY_PATH to get Xephyr load the mesa supplied libGL makes GL(llvmpipe) available inside and the tests do not crash. Is there desire to get tests at least not crash in such rare conditions? Kind regards, Bernhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-10-16 um 15:03 schrieb Bernhard Übelacker:
Is there desire to get tests at least not crash in such rare conditions? In theory there's no difference between a crash and a failure. In both cases the run is considered a failure.
You get a crash dialog, but you can disable that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWIPdlAAoJEN0/YqbEcdMw6q4P/2pQTGJx5QBMb6XEJAPoV04q sj1QOwRmu7orsctIcRrvXeag99jTr482Kq2+c9pPutdjEUTYDGShrCYySxdfiFe8 UGJ3Ag/YKnL7ZmAyfcBRReOPdbh20FCGIXsf85qcbhVrE0x/Y2wXvBirXasnr5TB 0h2HE1J80eEZHX598Tu7HNwqCEumIdWUriYMXh/2XWSJ9os3FnPNhQ+lgsJfDGJw SQjuSjN/G7DnewXeyD6Onpqw8ppATr9/WzxmXaAwdNg3pD9TJHy5NXAuHVNkkgbx ie4ClKmZA+/6JZh1vy0YPb9f1fsfo//oD9coHDbvJbiHpImVjsBtxPJmdAW+x8sU xKbwaWaWA71shMYgZmFKdysUDmAHfFXh+TAFszEXBfgaQCLTfxf7H4KojZJmfpJS rBvvxMChtqxO0tccylY51MmfccC1eLJxPDehUZZFM1Tcj9kDeQeaehyzzbE2zO9B dYvzioqIovehSi04u06LkTv0XQKGoZOozfUQVlmmc4PHzn0MPofG8A19vmB6Di2z vKAqEZfazvKHTO98OzHW7itR/A87clcu2RSYuoV+j1vzr9la3xvu/F/IaL/Vxe+L f3Daz4uVtsnvUq7olCsmfGIX/ACnpMq5Pzy3s2TZe77V6hhcDp5eEJvY7GyX6iQt xNF/gRh2vNct5EmOqZlX =A+XA -----END PGP SIGNATURE-----
Am 16.10.2015 um 15:11 schrieb Stefan Dösinger:
Am 2015-10-16 um 15:03 schrieb Bernhard Übelacker:
Is there desire to get tests at least not crash in such rare conditions? In theory there's no difference between a crash and a failure. In both cases the run is considered a failure.
You get a crash dialog, but you can disable that.
Ok, you mean something like this (just for the record): wine reg add HKCU\\Software\\Wine\\WineDbg /v ShowCrashDialog /t REG_DWORD /d 0 Thanks for your time. Kind regards, Bernhard
participants (3)
-
Bernhard Übelacker -
Henri Verbeet -
Stefan Dösinger