[VDPAU] [PATCH] Add VDPAU_DRIVER_PATH support

[Emil Velikov]

On 20/02/14 20:26, Aaron Plattner wrote:
> On 02/20/2014 12:17 PM, Aaron Plattner wrote:
>> On 02/06/2014 05:57 PM, Emil Velikov wrote:
>>> Allow the user to specify the location of the backend driver,
>>> via the VDPAU_DRIVER_PATH environment variable. This allows
>>> easier testing of VDPAU backends without the need to rebuild
>>> libvdpau.
>>>
>>> Inspired by LIBGL_DRIVERS_PATH from mesa.
>>>
>>> v2:
>>>    - Fix compilation issues.
>>>
>>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>>> ---
>>>
>>> Hi Aaron,
>>>
>>> I've spent a bit of time pondering on your suggestion to control
>>> the trace library using the same env variable.
>>>
>>> IMHO this will cause unnecessary complexity considering the
>>> permutations between driver/tracer locations.
>>>
>>> My initial goal was to ease the use and testing of vdpau backends,
>>> in order to avoid rebuilding libvdpau. As the trace library is part
>>> of libvdpau (thus defeating the purpose of the whole exercise) I'm
>>> planning to stick with my original goal.
>>
>> Thanks, that sounds good.
>>
>>> Cheers,
>>> -Emil
>>>
>>>    include/vdpau/vdpau_x11.h |  2 ++
>>>    src/vdpau_wrapper.c       | 14 ++++++++++++--
>>>    2 files changed, 14 insertions(+), 2 deletions(-)
> 
> [...]
> 
>>> -#define DRIVER_LIB_FORMAT "%slibvdpau_%s.so%s"
>>> +#define DRIVER_LIB_FORMAT "%s/libvdpau_%s.so%s"
>>
>> Unfortunately, this breaks the fallback driver loading because it now
>> searches for /libvdpau_nvidia.so instead of just /libvdpau_nvidia.so.
> 
> Er, that should read "just libvdpau_nvidia.so" without the slash,
> obviously.
> 
ack.

IMHO it's preferable to update the patch to "ignore" garbage being fed
to VDPAU_DRIVER_PATH.

Simply construct the new vdpau_driver_lib, whenever the env is set and
try to dlopen it. If snprintf truncates or dlopen fails, just continue
as nothing happened. Meaning - try VDPAU_MODULEDIR and then fallback if
applicable.

The resulting patch is slightly larger (27 (+), 6 (-)), but we'll retain
the original behaviour.

Thanks,
Emil

P.S. AFAICS snprintf can return negative values in case of an error.
This is not handled in existing code nor in my upcoming patch.