GitLab

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.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

VdpPictureInfo should not be a pointer, otherwise the
VdpDecoderRender function signature asks for a pointer to a pointer.
But it really does expect a pointer directly to e.g. VdpPictureInfoH264.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Tested-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Nothing actually uses VdpPoint, so this tracing function was never called.  I
left the VdpPoint type in vdpau.h for now, just in case anyone actually uses it
themselves.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Fixes -Wmissing-prototypes warnings.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

This just ports the code from the mesa glx setup into vdpau,
this just picks the correct driver to load on the client side,

at least for gallium/vl code we need another similiar change
inside the driver code to pick the correct drm device.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Martin Peres <martin.peres@ensi-bourges.fr>
Tested-by: Hohahiu <rakothedin@gmail.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=67283

init_config opens vdpau_wrapper.cfg and reads its contents, but never closes it.
This causes a file descriptor leak if libvdpau is unloaded and reloaded.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Reviewed-by: Josep Torra <josep@fluendo.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Closing an X display that had a VDPAU device created on it causes a crash.

Work around an identical libXext dlclose bug with the "Generic Event Extension"
by dlopening libXext.so.6 and leaving it open.

Original bug discovered and fixed by Robert Morell <rmorell@nvidia.com> in
commit 3b43955c

.

v2: Don't SKIP if creating the device fails.  Just attempting to create the
device installs the DRI2 extension that causes the problem.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

In this sequence:
dlopen(libvdpau.so)
vdp_device_create_x11(dpy, ...)
dlclose(libvdpau.so)
XCloseDisplay(dpy)

the process will attempt to call the address at which DRI2CloseDisplay
was previously mapped, possibly resulting in a SEGV.

Instead of tracking displays to which we've added hooks and cleaning up
the extension on library unload or display close, simply clean up after
ourselves once we have the data we need.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Users should address questions there instead of to xorg@lists.freedesktop.org.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Robert Morell <rmorell@nvidia.com>

Signed-off-by: James Le Cuirot <chewi@aura-online.co.uk>
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Also add authors to the AUTHORS file.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Implement two workarounds:

1) Swap U and V planes to VdpVideoSurfacePutBitsYCbCr to fix blue-tinged
   videos.

2) Disable VdpPresentationQueueSetBackgroundColor, so that Flash doesn't
   set the background to pure black or pure white, which would cause the
   VDPAU image to bleed through to other parts of the desktop with those
   very common colors.

These workarounds are only enabled when running under Flash player, and
may be individually controlled via /etc/vdpau_wrapper.cfg, should they
ever need to be disabled.

Note that this code stores the VDPAU backend function pointers as global
variables, which is technically incorrect. However, the likelihood of
any known VDPAU implementation ever returning different values for these
pointers within a single process is zero. If this becomes a problem, a
hash table of VdpDevice to the stored pointers should be implemented.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
[aplattner@nvidia.com: fixed distcheck by changing it to dist_libvdpausysconf_DATA]

vdpau_wrapper.c: Track dynamic library handles and free them on exit using __attribute__((destructor))
Signed-off-by: Kiran Pawar <kpawar@nvidia.com>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

  * Fix Doxygen warning; it gets confused by quotes.
  * Add subsection names, so part of the title doesn't get swallowed as the
    subsection name.
  * Document data required from MPEG-4 Part 2 & DivX bitstream.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

If the VDPAU_DRIVER environment variable is not set, use DRI2Connect to query
the VDPAU driver name from the X server.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

* Add a --with-module-dir configure parameter.

* Pass the moduledir into the wrapper.  Use it to construct the path to search
  for drivers.  Require drivers to end in a ".1" version, in case we ever want
  to rev. the interface between the wrapper and the drivers.

* If no driver is found in the new module dir, look for one in the default
  search paths.  This is intended to find libvdpau_nvidia.so for drivers that
  predate the change to move it, and can be removed in the future.

* Stash the moduledir into vdpau.pc.  Drivers can find this with
  `pkg-config --variable=moduledir vdpau`.

* Add a version to libvdpau_trace.so in case the interface between it and
  libvdpau.so ever changes.

* Install libvdpau_trace.so.1 to moduledir instead of libdir.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>

* Uninstall the docs if they were installed.
* Remember to distribute Doxyfile and vdpau_data_flow.png in the
  tarball.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>

Detect when doxygen, dot, and pdflatex are installed.  When they are, enable
documentation.  Add --enable-documentation and --disable-documentation to
override the autodetection.  Install the docs to the configured docdir (usually
$prefix/share/doc/libvdpau).

Steal the XORG_CHANGELOG macro from X.Org and stash it in acinclude.m4.

Add profiles for MPEG-4 part 2, DivX 4, and DivX 5.  Also add new high quality
scaling options.

Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>