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@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