Arch Linux User Repository

@kajlao This package follows the way in which the official repositories names the libva drivers.

Could someone finally rename this package to nvidia-vaapi-driver?

Update regarding the 525 series regression: direct backend is now merged into master so you should be able to access it on the nvidia-vaapi-driver-git package. So far we've confirmed pascal (10XX) and turing mobile (20XX/16XX) work with the direct backend so it's likely 30 series work too. Let us know if you have success on 30XX!

QUICK HEADS UP: Series 525 of the Nvidia driver introduced a regression, breaking VA-API. You may downgrade the drivers to version 520 or use the highly experimental direct-backend branch in the meantime.

Leaving this here so others don't spend hours trying to figure out why the VA-API isn't working. Also added a temporary note on the ArchWiki until it's fixed.

error: could not set install reason for package libva-nvidia-driver (could not find or read package) getting this error on recent drivers

I cannot tell you how happy I am now that I can actually use my GPU to watch Youtube >:(

@Nocifer In short: package 'foo-git' must add conflicts with package 'foo', but package 'foo' should not add conflicts with package 'foo-git'. This is a well established thing. The base package that I said does not refer to split packages, but to the concept of derived packages (even if a derived is a VCS one). In this case, this one is the base package. Now, imagine if people start to create many derived packages (regardless of the base package in question). The maintainer of the base package does not have the duty to track all those newly created derived packages at every second just to add a new entry to conflicts. Instead, it's responsibility of the derived package maintainer to add the proper conflicts on it. Regarding adding 'nvidia-vaapi-driver' to provides here, maybe this can be a good thing.

@dbermond I believe it's an established practice that all packages which conflict with each other should declare so in their PKGBUILDs, be they stable or VCS packages. It's not a matter of rank. Also, not to be pedantic but a "base package" is a term usually used in the context of split PKGBUILDs and means a completely different thing, it has nothing to do with whether a package builds off upstream's stable releases or not.

Anyway, what's more important is that I was just about to create a new AUR package for the stable version of nvidia-vaapi-driver because I searched for it and all I could find was the VCS package, nvidia-vaapi-driver-git, until at the last minute I noticed that nvidia-vaapi-driver-git also states that it also provides and conflicts with libva-nvidia-driver, and searching for that I was finally able to arrive here.

Since the upstream's original name for the project is nvidia-vaapi-driver and most people will use that name to search for it in the AUR (especially now that the project is still new and relatively unknown) you should probably add it to the 'provides' array.

@afader No, because this is a base package (if you take in consideration the other one as being the VCS package). Development (VCS) packages should conflict with the base package, and not the contrary.

@dbermond shouldn't the packages conflict then at least?