Apparently the package is missing a file "amdxvba.h" for fglrx compatibility preventing it form a proper configure, or at least that's the fix I've seen for this issue.
The ubuntu guys imported into the package themselves.
1) Please post your `emerge --info' output in a comment.
2) Please attach the entire build log to this bug report.
Created attachment 330460 [details]
Created attachment 330504 [details]
Same problem here. It seems as if the missing header in question isnt contained in any ati-drivers package.
xvba-video-0.8.0 installes fine, though.
Yea , I put 0.8.0 by accident in the log name lol, if you look at the log it's clearly 0.8.0-r1 though.
I think from what I gathered from the links I posted, the Ubuntu guys imported "amdxvba.h" into the package making it available at configure/compile.
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.
I agree with you on all points Joe. Just throwing it out there though, there is an ebuild that someone has created at:
It needs to be tweaked since the location of the tar.gz file is in a different place now, but otherwise it builds (as well as xvba-video) correctly.
(In reply to comment #7)
> I agree with you on all points Joe. Just throwing it out there though,
> there is an ebuild that someone has created at:
> It needs to be tweaked since the location of the tar.gz file is in a
> different place now, but otherwise it builds (as well as xvba-video)
That ebuild is outdated, mainly the links. Even after you fix the ebuild it still doesn't solve the problem. I think the -vaapi use flag is the best way to go this way everything get's pulled in at once.
This way the ati-drivers pull in xvba-video and in return the newest version x11-libs/xvba-video-0.8.0-r1 pulls in xvba-sdk.
So you need a updated version for ebuild x11-libs/xvba-video-0.8.0-r1 to pull in the SDK and they need to create a -vaapi use flag for ati-drivers to pull in xvba-video. That would fix it the issue properly.
Just as a note the older version(x11-libs/xvba-video-0.8.0) I don't think it compiled it basically just extracted the binaries to it's proper locations and created the symbolic links as needed.
This discussion seems to be going in the direction of my second solution, however in the funtoo irc channel, it seemed that people were more going in the direction of the first solution I proposed (after all the SDK is only one header file right now).
It would be great if a common solution can be found for gentoo and funtoo.
I also opened a 2 bugs on the funtoo bug tracker for those interested:
- http://bugs.funtoo.org/browse/FL-244 for adding the -vaapi flag on ati-drivers
- http://bugs.funtoo.org/browse/FL-245 for solving the problem with the missing SDK.
As for the xvba-sdk ebuild, it's encouraging to see that some have been there already once, but don't understand why it didn't land in portage already. Outdated links should be fairly easy to fix, as the installation instructions are still the same.
Chiming in from the Funtoo side, I think the following approach makes sense, which I documented in FL-244:
1) add xvba header to ati-drivers
2) add vaapi? RDEPEND on xvba-video to ati-drivers
3) remove ati-drivers RDEPEND from xvba-video (if possible), otherwise move to PDEPEND?
I think this provides the best user experience, allowing "vaapi" in USE to serve as a single point of control for enabling video acceleration for users of AMD proprietary drivers. *Technically*, it isn't correct, as ati-drivers doesn't really *need* xvba-video to run at all, but from a user experience/intention perspective, I think it is a legitimate and beneficial use of USE variables with no downsides. Set "vaapi", emerge -auDN, and if you have ati-drivers installed, now vaapi is working. That is a great user experience. It does mean that ati-drivers is now being used more as a meta-package for proprietary AMD video support (in a general sense, rather than just the bare X11 drivers,) but I think it works well for this purpose.
Created attachment 332894 [details, diff]
ati-drivers-12.11_beta11-r1.ebuild diff from Funtoo Linux.
Here we go.
This patch contains multiple bugs and improvements and is made against ati-drivers-12.11_beta11.ebuild from x11-overlay, and implements "easy to use" vaapi support for ATI/AMD Radeon users:
x11-libs/xvba-video can now build properly against the installed ati-drivers, due to an included xvba sdk header as well as a soname fix for a required shared library. USE="vaapi" emerge ati-drivers (enabled by default) will cause xvba-video to be merged via PDEPEND, allowing for xvba-based VAAPI to be easily enabled by end-users.
FL-135: ati-drivers requires unzip
FL-244: ati-drivers xvba support
FL-245: xvba-video-0.8.0-r1: missing xvba-sdk-0.74-404001
FL-284: ati-drivers-12.11* -> libXvBAW.so missing, causing x11-libs/xvba-video merge to fail
Bug details browseable at http://bugs.funtoo.org/browse/FL-135, etc.
Tree browseable at https://github.com/funtoo/funtoo-overlay/blob/master/x11-drivers/ati-drivers/ati-drivers-12.11_beta11-r1.ebuild
Perhaps the sdk should be included in xvba-video, I strongly doubt anyone else is going to be using that interface and as such maintaining the header in context of xvba-video might be easier.
ati-drivers-12.11_beta11 now does all the library symlinks required for the compile. Thanks for the patches.
(In reply to comment #12)
> Perhaps the sdk should be included in xvba-video, I strongly doubt anyone
> else is going to be using that interface and as such maintaining the header
> in context of xvba-video might be easier.
> ati-drivers-12.11_beta11 now does all the library symlinks required for the
> compile. Thanks for the patches.
No that would be technically even more wrong, symlinks that need to be created are part of ati-drivers, not xvba-video, the header file allows using functionality in ati-drivers, not in xvba-video. The sdk if it is to be included in another package, it should be ati-drivers. However, as noted this is not after reading what drobbins had to say, we would all be better if we made an ati meta package because: we have the xvba-sdk, the drivers and ati's opencl drivers, which all need to be installed depending on your hardware support (on recent hardware, all of that can be installed).
I believe this has been fixed for now in funtoo, but on the long run, a metapackage with the right USE vars. to pull-in the required ati-package would be nice (app-sdk if opencl is set, xvba-sdk and xvba-video if vaapi is set).
In order to avoid incorrect merge order, we had to modify xvba-video RDEPEND to x11-drivers/ati-drivers[vaapi].
See http://bugs.funtoo.org/browse/FL-244 for more info.
(In reply to comment #13)
> (In reply to comment #12)
> > Perhaps the sdk should be included in xvba-video, I strongly doubt anyone
> > else is going to be using that interface and as such maintaining the header
> > in context of xvba-video might be easier.
> > ati-drivers-12.11_beta11 now does all the library symlinks required for the
> > compile. Thanks for the patches.
> No that would be technically even more wrong, symlinks that need to be
> created are part of ati-drivers, not xvba-video, the header file allows
> using functionality in ati-drivers, not in xvba-video. The sdk if it is to
> be included in another package, it should be ati-drivers. However, as noted
> this is not after reading what drobbins had to say, we would all be better
> if we made an ati meta package because: we have the xvba-sdk, the drivers
> and ati's opencl drivers, which all need to be installed depending on your
> hardware support (on recent hardware, all of that can be installed).
> I believe this has been fixed for now in funtoo, but on the long run, a
> metapackage with the right USE vars. to pull-in the required ati-package
> would be nice (app-sdk if opencl is set, xvba-sdk and xvba-video if vaapi is
By sdk I mean amdxvba.h, everything else is in place. My rational for this is that
1) The header file is separately packaged from ati-drivers signaling that this is meant to be a independent interface like OpenCL, whose headers are not packaged with ati-drivers either.
2) xvba-video is the only package that is ever likely to use the header so it would be easier to maintain in this context.
If this is not ok, I will include the header into ati-drivers and this bug should be resolved.
The dependency scheme (similar to the one used by intel-drivers, all should be in place):
libva depends on xvba-video
xorg-drivers depends on ati-drivers
several packages depend on libva and indirectly on xvba-video
xvba-video already rdepends on ati-drivers, which will not have vaapi use flag, unless there is a specific reason for it.
Should be fixed in x11-overlay for both current and legacy branches.
13.1 was added to portage