-
Bug
-
Resolution: Fixed
-
Normal
-
None
-
None
-
None
All present solutions are half-@$$ed solutions whether for debian, ubuntu or others.
First things first, the context:
- xvba-video is the va-api backend for the fglrx drivers (ati-drivers)
- xvba-video depends on a one file SDK: amd xvba-sdk-0.74 which is open source and available at http://developer.amd.com/tools/open-source/, under "XvBA SDK and Tools", the first "learn more" link.
The ati-drivers (fglrx) need an additional use flag – "vaapi" – so it can pull in the xvba-video package.
The reason the configuration step fails is because in xvba-video, the configure.ac at line 277, it tries to locate the amdxvba.h file (from the xvba sdk)
For the xvba-sdk which is basically one header file, the documentation and readme (installation instructions), it needs to be installed properly, with correct packaging semantics.
Having followed the installation instructions approximately, solved my update problem, and the installation goes as expected.
Now back to packaging, it's been seven years since I had a look at how ebuilds are written. However I can think of two ways to remedy this problem:
1. Make ati-drivers pull in the sdk and install it when the vaapi use flag is set.
pro: avoids polluting the portage tree with ati specific packages.
con: ati-drivers would install packages both open source and proprietary.
2. Make a seperate package called xvba-sdk (original I know), that gets pulled in before xvba-video when the vaapi flag is set.
pro: both fglrx and the xvba-sdk have different licences.
con: even though the xvba-sdk is open source, it is useless without the proprietary drivers from ati.
In both cases, we should really add the vaapi flag to fglrx's drivers.
- relates to
-
FL-244 ati-drivers xvba support
- Closed