this bug contains an ebuild for the new 195.30 driver from nvidia. As one can see in the description, this driver adds various fixes and improvements with compiz, RENDER and KDE4: http://www.nvnews.net/vbulletin/showthread.php?p=2149232 The ebuild is adapted from the one found here: http://www.nvnews.net/vbulletin/showthread.php?t=141873 Reproducible: Always
Created attachment 213974 [details] nvidia-drivers-195.30.ebuild
Created attachment 213976 [details, diff] arch detection patch, to be included in the "files" directory of nvidia-drivers-195.30.ebuild arch detection patch, to be included in the "files" directory of the ebuild
Created attachment 213978 [details] nvidia-settings-195.30 ebuild nvidia-settings 195.30 ebuild
Created attachment 213979 [details, diff] nvidia-settings patch to be included in the files directory of nvidia-settings-195.30 nvidia-settings patch to be included in the files directory of the ebuild nvidia-settings-195.30
Created attachment 214003 [details] new version of nvidia-drivers-195.30.ebuild fixes vdpau installation new version of nvidia-drivers-195.30. fixes vdpau installation
(In reply to comment #5) > Created an attachment (id=214003) [details] > new version of nvidia-drivers-195.30. fixes vdpau installation > > new version of nvidia-drivers-195.30. fixes vdpau installation > This installs the VDPAU library to the wrong location (see bug 297239, comment 10). Additionally, it is installing a bad symlink to the vdpau library.
to comment #6: You wrote in Bug 297239: "Rather than incorrectly changing the paths back, please say which apps you are having a problem with so they may be fixed." Well, one "application" which does not work with the vdpau ebuild in the main portage three is mplayer....
All what I can say is, that mplayer does not work with the ebuild in the three. However, mplayer works with the ebuild in this bug. in comment #6 of bug 297239 you wrote: "Rather than incorrectly changing the paths back, please say which apps you are having a problem with so they may be fixed." Well, you can tell this problem to the people at mplayer upstream. Furthermore, one then would have to tell this probably all other applications that use vdpau. That will certainly take some time. We cannot realistically afford that our videos won't be playable until the developers of most vdpau apps are informed of a recent path change by nvidia. Furthermore, if you rename the highest version ebuild of nvidia-drivers in the portage three to 195.30, it won't compile because it does not find the kernel correctly.
(In reply to comment #8) > All what I can say is, that mplayer does not work with the ebuild in the three. > > However, mplayer works with the ebuild in this bug. > > in comment #6 of bug 297239 you wrote: "Rather than incorrectly changing the > paths back, please say which apps you are having a problem with so they may be > fixed." > > Well, you can tell this problem to the people at mplayer upstream. Furthermore, > one then would have to tell this probably all other applications that use > vdpau. That will certainly take some time. > > We cannot realistically afford that our videos won't be playable until the > developers of most vdpau apps are informed of a recent path change by nvidia. > It's not a path change by NVIDIA. They have a public library that everyone should use called libvdpau.so, they have expressed that no one should use libvdpau_nvidia.so directly. However using it directly has not caused harm, it has however with the latest driver release started to cause harm. To make it even more apparent that you shouldn't use libvdpau_nvidia.so directly they moved it to a location that only libvdpau.so would be able to access it. mplayer has been in the wrong from day one.
@ comment #9: Doug Goldstein wrote: "However using it directly has not caused harm, it has however with the latest driver release started to cause harm." Really? I have not seen a bug report on this at http://www.nvnews.net/vbulletin/forumdisplay.php?s&forumid=14 Can you point me to a bug where it is found that mplayer's linking to libvdpau_nvidia.so is the reason for "screen corruption"? Thanks
Here is a comment from Nvidia, of the developers of the nvidia linux driver: http://www.nvnews.net/vbulletin/showthread.php?p=2156911#post2156911 Correct, applications should not be linking directly against libvdpau_nvidia. However, doing so shouldn't be able to cause any corruption problems, it should be harmless. As for finding the correct library, there have been problems in the past on some distributions where a stale copy of libvdpau 0.2 is left lying around and getting picked up by applications, which doesn't look in /usr/lib/vdpau for libvdpau_nvidia. Are you sure the correct version of libvdpau is being used by your applications? If so, please try running mplayer or mythtv with "strace -eopen" to see where it's looking. Even if the old version were being used, it should look at /usr/lib/libvdpau_nvidia.so which the .run installer creates as a symlink to /usr/lib/vdpau/libvdpau_nvidia.so.<version>. AaronP is offline Reply With Quote
The above comments from nvidia developers imply that my ebuild should not cause any harm. And it should not, as Doug Goldstein writes, lead to "screen corruption". In fact, mplayer just works with my ebuild for the 195.30 nvidia driver, whereas the ebuild in the main portage three does not.
Created attachment 218855 [details] Log of error An ebuild for the drivers made it to Portage today. It fails to build. I uploaded the log of my problems. I tried to recompile my kernel, to no avail.
Created attachment 218861 [details] ebuild environment I can confirm that the build fails with the same error here aswell. Maybe the environment output is of help, since it can't find the kernel version.
Unified arch patch should be in. spock is handling this ebuild so assigning to him so he can fix it.
Closing the bug as the ebuild and the unified ARCH patch are now in. mplayer with -vo vdpau also seems to work.