Bug#664700: libva1: please search dri module in /usr/lib/{<triplet>/, }dri

Andres Mejia amejia004 at gmail.com
Tue Mar 20 06:20:17 UTC 2012


On Mon, Mar 19, 2012 at 9:55 PM, Andres Mejia <amejia004 at gmail.com> wrote:
> On Mon, Mar 19, 2012 at 8:38 PM, Andreas Beckmann <debian at abeckmann.de> wrote:
>> Package: libva1
>> Version: 1.0.15-4
>> Severity: normal
>>
>> Hi,
>>
>> please use a search path for the DRI modules that contains both
>>  /usr/lib/<triplet>/dri
>>  /usr/lib/dri
>> While we can (hopefully) fix the Debian packages to ship the files in
>> the multiarch locations, the multiarch move "breaks" any third-party
>> (probably proprietary) software/installer/... that is not multiarch
>> aware. Therefore "plugins" should be searched in both locations.
>>
>> So far the following problems have been reported:
>>
>> xvba-va:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664487
>>
>> fglrx + vainfo:
>>
>> $ vainfo
>> libva: VA-API version 0.32.0
>> Xlib:  extension "XFree86-DRI" missing on display ":0".
>> libva: va_getDriverName() returns 0
>> libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so
>> libva: va_openDriver() returns -1
>> vaInitialize failed with error code -1 (unknown libva error),exit
>>
>> I'm not sure if I can move dri/fglrx_drv_video.so around - it is loaded
>> from the fglrx driver (a non-free blob) using the hardcoded path
>> /usr/lib/dri ... (and the last time I tried to use symlinks (although in
>> a different context) the fglrx blob used lstat() and complained about
>> world writable files ...)
>>
>>
>> Andreas
>>
>>
>>
>> _______________________________________________
>> pkg-multimedia-maintainers mailing list
>> pkg-multimedia-maintainers at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>
> I don't believe modules should be allowed to load from /usr/lib/dri in
> a multiarch library. Suppose the amd64 library package is loaded into
> an i386 machine, and the module is i386 and installed in /usr/lib/dri.
> This configuration may cause breakage. I'm afraid the module has to be
> fixed, even if it's a proprietary module.
>
> --
> ~ Andres

I looked into this some more. NVIDIA's vdpau driver doesn't show a
problem with the modules being installed in
/usr/lib/x86_64-linux-gnu/vdpau. vainfo is working fine for me (after
fixing some issues with the vdpau-va-driver which I just uploaded).

$ vainfo
libva: VA-API version 0.32.0
Xlib:  extension "XFree86-DRI" missing on display ":0".
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA-API version: 0.32 (libva 1.0.15)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for
VA-API - 0.7.3
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD

Also, I checked the code that sets the module directory for both
libvdpau and libva. Only one path is set for both libraries and it is
based off of $libdir variable from their build systems. With
multiarch, each library sets the module path to /usr/lib/<triplet>/*.

With this information, I believe the fglrx driver should be fixed.

-- 
~ Andres





More information about the pkg-multimedia-maintainers mailing list