On 15/05/18 03:16, Michael Niedermayer wrote:
> On Mon, May 14, 2018 at 10:58:58PM +0100, Mark Thompson wrote:
>> This uses any devices it can find on the host system - on a system with no
>> hardware device support or in builds with no support included it will do
>> nothing and pass.
>> ---
>>  libavutil/Makefile         |   1 +
>>  libavutil/tests/hwdevice.c | 234 
>> +++++++++++++++++++++++++++++++++++++++++++++
>>  tests/fate/libavutil.mak   |   4 +
>>  tests/ref/fate/hwdevice    |   1 +
>>  4 files changed, 240 insertions(+)
>>  create mode 100644 libavutil/tests/hwdevice.c
>>  create mode 100644 tests/ref/fate/hwdevice
> 
> does not work here (over ssh if that matters)
> --- ./tests/ref/fate/hwdevice 2018-05-15 04:12:44.462164238 +0200
> +++ tests/data/fate/hwdevice  2018-05-15 04:13:04.606164152 +0200
> @@ -1 +0,0 @@
> -Passed.
> Test hwdevice failed. Look at tests/data/fate/hwdevice.err for details.
> X Error of failed request:  BadRequest (invalid request code or no such 
> operation)
>   Major opcode of failed request:  154 (DRI2)
>   Minor opcode of failed request:  1 (DRI2Connect)
>   Serial number of failed request:  11
>   Current serial number in output stream:  11
> make: *** [fate-hwdevice] Error 1

In some sense this is success - the test found that some hardware device 
doesn't work in your setup.

This is presumably either libva or some OpenCL ICD running with X forwarding 
enabled?  I'm aware that they can blindly make Xlib calls which end up in the 
default error handling (call abort()) when they fail - I run "DISPLAY= 
./ffmpeg..." when in an X forwarded session to avoid this.

I think that means there should be something gating this test (and any other 
hardware tests) - how about a configure option --(en|dis)able-hw-tests, with 
default value the same as autodetect?  (I think that has the right properties?  
Or it could just be disabled by default, but that would probably mean it would 
never get run even in places where it should be.)

- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to