d3drm/tests: Skip following tests when device creation fails.
bernhardu at vr-web.de
Fri Oct 16 08:03:47 CDT 2015
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 at 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?
More information about the wine-devel