[Bug 774811] vaapi: cannot open driver in a headless environment

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=774811

--- Comment #2 from Reza Razavi <reza at userful.com> ---
(In reply to Víctor Manuel Jáquez Leal from comment #1)
Hi I'm working with Stirling Westrup, in latest releases of VAAPI, in
gst/vaapi/gstvaapi.c before loading the plugin some routings are checking for
GPU capabilities and supported decoding and encoding formats, in a headless
system it fails right away there and plugin gets blacklisted. I'll attach a
compress file to this bug first file in it contains what you asked for when we
run it for the first time and second one is when it's blacklisted.

I should mention that when I modify code in gstvaapi.c and remove those queries
and force it to just register plugins also in
gst-libs/gst/vaapi/gstvaapidisplay_drm.c : gst_vaapi_display_drm_new function
replace path with my desired path /dev/dri/card0 vaapi will work

> Thanks for reporting this.
> 
> My guts tell me that this might a configuration problem.
> 
> When libva reports that "va_getDriverName() returns -1" it is because it
> could not find the drivers name. Normally, libva uses some hints to find
> this driver name. In the case of drm, it uses a try-and-error list[1].
> 
> 1. https://cgit.freedesktop.org/libva/tree/va/drm/va_drm_utils.c#n39
> 
> Now, GstVaapiDisplayDRM only tries to open render nodes, not the render
> device itself. The render nodes are those called /dev/dri/renderD* [2]
> 
> 2.
> https://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/
> 
> 
> The question is why libva is not finding the driver name. A workaround would
> be exporting the environment variable LIBVA_DRIVER_NAME set to "i915"
> 
> Could you upload the output of 
> 
> $ strace gst-inspect-1.0 /path/to/libgstvaapi.so  
> 
> ??

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.