宋文武 <iyzsong@gmail.com> writes:

> Look good to me, but how does it work?
> According to archlinux, it will build 'gallium_drv_video.so',
> described as VA-API implementation for gallium.
> IIUC, libva may dlopen this gallium_drv_video.so?

I had to tinker and research for several hours to be able to answer your
question, but good thing you asked. :-)

Firstly:

I grepped the libva sources for 'dlopen' and found three places it's
used:

- to open libatiadlxx.so, which AFAIUI is a proprietary ATI driver which
  we wouldn't support anyway,

- to open libva-x11.so, which it installs in $prefix/lib; I patched the
  .c file to use the absolute path to this .so, and

- to open drivers found in $LIBVA_DRIVERS_PATH, falling back to the CPP
  macro VA_DRIVERS_PATH, which should both contain absolute directory
  names so it's fine.

Secondly:

The default value for VA_DRIVERS_PATH is $prefix/lib/dri (where $prefix
is that of libva), which contains only some dummy driver installed by
libva; most drivers are instead in $mesa_prefix/lib/dri.  So it's
probably best to set VA_DRIVERS_PATH to $mesa_prefix/lib/dri.  So I
added --with-drivers-path to libva's configure flags (plus added a make
flag to solve a certain problem; see patch).

By the way:

If a package wants to use libva with a driver that doesn't come with
mesa, then they will have to set LIBVA_DRIVERS_PATH.  A user may also
add ~/.guix-profile/lib/dri to LIBVA_DRIVERS_PATH, and install any
number of packages installing graphics drivers there.

Thirdly, and I can finally answer your question:

Comes out "gallium_drv_video.so", found in Arch's "libva-mesa" package,
is actually Mesa's Gallium-based implementation of VA API, alternative
to stock libva.  (Arch also has a regular libva package, containing the
real libva.)  The gallium_drv_video.so driver is installed in mesa's
$prefix/lib/dri when building it is enabled, so all is fine.

Also, Mesa needs libva's header files for building it, and this actually
seems to be the sole reason Mesa depends on libva.  I considered making
a "libva-headers" package (like the mesa-headers package), but Mesa uses
pkg-config to test libva's presence so I'm not sure if that would work,
and libva is small anyway so building it twice should be OK.

Based on all that, here's a patch that applies *before* the one adding
libva to mesa, and then a fixed version of the patch adding libva to
mesa; notably I put the libva-without-mesa package into video.scm
because I was getting circular import problems: