319.12 driver

I just installed the new 319.12 driver and so far it is working great! I especially like the ability to restore efifb consoles.

I do have a couple of very minor nitpicks however:

  1. efifb console restoration does not work after a suspend/resume cycle. It just displays a blank screen with the backlight off instead.
  2. The readme says that a new VDPAU page has been introduced in nvidia-settings, but I do not see any such page.

Thanks for making such an awesome driver!

nvidia-bug-report.log.gz (52.1 KB)

No VDPAU page here too, tested on two different setups…

[url]http://wstaw.org/m/2013/04/10/plasma-desktopC21742.png[/url]

It might be a problem with the xorg edgers version. nvidia-settings tries to load libvdpau.so, the deb package installs libvdpau_nvidia.so. See here :

nraecher@Gaming:~$ strace nvidia-settings 2>&1  | grep vdpau
open("/lib/x86_64-linux-gnu/tls/x86_64/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/tls/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/x86_64/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/x86_64/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/x86_64/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/tls/x86_64/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/tls/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/x86_64/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/x86_64/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libvdpau.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
nraecher@Gaming:~$ find /usr/ -name "libvdpau*"
/usr/share/doc/libvdpau1
/usr/lib32/vdpau/libvdpau_nvidia.so.1
/usr/lib32/nvidia-319/vdpau/libvdpau_nvidia.so.319.12
/usr/lib32/nvidia-319/vdpau/libvdpau.so.319.12
/usr/lib32/nvidia-319/vdpau/libvdpau_trace.so.319.12
/usr/lib32/nvidia-319/vdpau/libvdpau_nvidia.so.1
/usr/lib32/nvidia-319/vdpau/libvdpau_nvidia.so
/usr/lib32/libvdpau_nvidia.so
/usr/lib/vdpau/libvdpau_nvidia.so.1
/usr/lib/nvidia-319/vdpau/libvdpau_nvidia.so.319.12
/usr/lib/nvidia-319/vdpau/libvdpau_nvidia.so.1
/usr/lib/nvidia-319/vdpau/libvdpau_nvidia.so
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_trace.so.1.0.0
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_trace.so.1
/usr/lib/x86_64-linux-gnu/libvdpau.so.1
/usr/lib/x86_64-linux-gnu/libvdpau.so.1.0.0
/usr/lib/libvdpau_nvidia.so

I tried symlinking /usr/lib/libvdpau_nvidia.so to /usr/lib/libvdpau.so and it still didn’t work.

strace nvidia-settings 2>&1  | grep vdpau
open("/usr/lib/libvdpau.so", O_RDONLY|O_CLOEXEC) = 13
open("/etc/vdpau_wrapper.cfg", O_RDONLY) = 13
open("/usr/lib/vdpau/libvdpau_nvidia.so.1", O_RDONLY|O_CLOEXEC) = 14

for me

Archlinux with uses own pkgbuild

thefirstM, do you have libvdpau installed? Your Linux distribution should have a package for it.

libvdpau_nvidia.so is the driver back-end library. It’s not the same as libvdpau.so, which is the driver loader wrapper that applications are supposed to link against.

nraecher@Gaming:~$ apt-show-versions | grep vdpau
libvdpau1/quantal uptodate 0.4.1-6ubuntu1
vdpauinfo/quantal uptodate 0.0.6-1
nraecher@Gaming:~$ apt-file list libvdpau1
libvdpau1: /etc/vdpau_wrapper.cfg
libvdpau1: /usr/lib/x86_64-linux-gnu/libvdpau.so.1
libvdpau1: /usr/lib/x86_64-linux-gnu/libvdpau.so.1.0.0
libvdpau1: /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_trace.so.1
libvdpau1: /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_trace.so.1.0.0
libvdpau1: /usr/share/doc/libvdpau1/changelog.Debian.gz
libvdpau1: /usr/share/doc/libvdpau1/copyright

So, installing the libvdpau-dev package fixes the bug in nvidia-settings…

nraecher@Gaming:~$ apt-file list libvdpau-dev
libvdpau-dev: /usr/include/vdpau/vdpau.h
libvdpau-dev: /usr/include/vdpau/vdpau_x11.h
libvdpau-dev: /usr/lib/x86_64-linux-gnu/libvdpau.so
libvdpau-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/vdpau.pc
libvdpau-dev: /usr/share/doc/libvdpau-dev/changelog.Debian.gz
libvdpau-dev: /usr/share/doc/libvdpau-dev/copyright

…because it installs the shared object without version number…

Sidenote : God, this forum software has so much bugs. Why can’t we have two code blocks in one post ?

driver runs gnome-3.8 fine but I am getting repeated kernel bug reports:

Apr 10 23:22:34 harrisl-desktop kernel: BUG: using smp_processor_id() in preemptible [00000000] code: gnome-shell/4166
Apr 10 23:22:34 harrisl-desktop kernel: caller is os_get_cpu_number+0x9/0x10 [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: Pid: 4166, comm: gnome-shell Tainted: P O 3.8.6-gentoo #1
Apr 10 23:22:34 harrisl-desktop kernel: Call Trace:
Apr 10 23:22:34 harrisl-desktop kernel: [] debug_smp_processor_id+0xd1/0xf0
Apr 10 23:22:34 harrisl-desktop kernel: [] os_get_cpu_number+0x9/0x10 [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] _nv012291rm+0x9/0xe [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] ? _nv015426rm+0x34/0x17a [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] ? _nv015427rm+0x3f/0x78 [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] ? _nv015434rm+0x26/0x55 [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] ? _nv013764rm+0xf6/0x100 [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] ? _nv013870rm+0x1f/0x49 [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] ? _nv000790rm+0x837/0x9ee [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] ? rm_ioctl+0x76/0x100 [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] ? nv_kern_ioctl+0x156/0x480 [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] ? _raw_spin_unlock_irq+0x12/0x40
Apr 10 23:22:34 harrisl-desktop kernel: [] ? nv_kern_unlocked_ioctl+0x1c/0x20 [nvidia]
Apr 10 23:22:34 harrisl-desktop kernel: [] ? do_vfs_ioctl+0x8f/0x530
Apr 10 23:22:34 harrisl-desktop kernel: [] ? ktime_get_ts+0x47/0xe0
Apr 10 23:22:34 harrisl-desktop kernel: [] ? fget_light+0x97/0x100
Apr 10 23:22:34 harrisl-desktop kernel: [] ? sys_ioctl+0x91/0xb0
Apr 10 23:22:34 harrisl-desktop kernel: [] ? system_call_fastpath+0x16/0x1b

These happen over and over every second.

This is my kernel and cpu. I am using GeForce GTX 680

3.8.6-gentoo #1 SMP PREEMPT Fri Apr 5 19:32:39 EDT 2013 x86_64 Intel(R) Core™ i7 CPU 970 @ 3.20GHz GenuineIntel GNU/Linux

Thanks!

I discovered that I had a libvdpau.so.1.0.0 in /usr/lib/x86_64-linux-gnu/, and symlinking that to /usr/lib/x86_64-linux-gnu/libvdpau.so caused the VDPAU page to appear. I didn’t want to install libvdpau-dev because that would pull in all sorts of other -dev dependencies that I didn’t want on my laptop.

Any news about the efifb console restore after suspend/resume?

Thanks for reporting this. I think the problem is that nvidia-settings is trying to load libvdpau.so rather than libvdpau.so.1. I filed bug 1271137 to get that fixed.

Index: nvidia-settings/src/gtk+-2.x/ctkvdpau.c
===================================================================
--- nvidia-settings.orig/src/gtk+-2.x/ctkvdpau.c	2013-04-12 19:22:24.005071805 +0200
+++ nvidia-settings/src/gtk+-2.x/ctkvdpau.c	2013-04-12 19:24:29.749067332 +0200
@@ -1431,7 +1431,10 @@
     /* open VDPAU library */
     vdpau_handle = dlopen("libvdpau.so", RTLD_NOW);
     if (!vdpau_handle) {
-        goto fail;
+	    vdpau_handle = dlopen("libvdpau.so.1", RTLD_NOW);
+	    if (!vdpau_handle) {
+        	goto fail;
+	}
     }

Here’s the fix…

any patch to REALLY use system palette colors in nvidia-settings? see my capture in #3

I use a dark theme on my system and noticed this after installing the 319 beta drivers instead of the Debian packaged ones.
Debian’s nvidia-settings has this patch here applied but it doesn’t work on the 319 version. I went through the nvidia-settings source and commented out all the gtk_widget_modify_[bf]g calls in src/gtk±2.x/ctkglx.c and src/gtk±2.x/ctkvdpau.c and recompiled it, which fixed the problem for me.

Try the attached patch.
nvsettings-dark-bg.patch.txt (21.3 KB)

i’m not sure (i’m not coder), but:

_out/Linux_x86_64/ctkvdpau.o: In function `ctk_vdpau_new':
ctkvdpau.c:(.text+0x1937): undefined reference to `gtk_event_box_ngtew'
collect2: error: ld returned 1 exit status
make[1]: *** [_out/Linux_x86_64/nvidia-settings] Error 1

in the patch , lines 328 and 329

-    event = gtk_event_box_new();
+    event = gtk_event_box_ngtew();

change to

-    event = gtk_event_box_new();
+    event = gtk_event_box_new();

(for void this change)
build OK

and finaly…

http://wstaw.org/m/2013/04/18/plasma-desktopz20262.png

i’m so much happy ;_;

finaly can read GLX info!!!

thanks @ahktenzero!!!

@aaron

its possible apply this patch in the official drivers??

That shouldn’t have been in there. I’ve replaced the patch in my previous post with a fixed one.

I’m not sure this patch should be merged into the official nvidia-settings, it’s a bit of a hack. For one thing I have no idea if it messes up the display for users with light themes (though as Debian have a simlar patch on the nvidia-settings they distribute it’s probably OK). I did some more checking and found that patch was originally from Ubuntu, added on their 173.14.09-1ubuntu3 version of nvidia-settings so this problem has been around for a while. I couldn’t find a relevant bug in their bugtracker though.

I don’t know GTK particularly well but after skimming the section of the docs about themes I think the problem might be that it’s not setting the colors for the right widget state(s). I’ll experiment with it a bit and see if I can find a working combination.

i have always this “bug” in fedora (up to core4), in ubuntu (up to 8.04) and now in Archlinux (today)

thanks for the new patch

edit: bleh~ english :S

I’ve experimented with this some more. Commenting out the code to change the widget colours does affect the display on light themes, it doesn’t make the affected widgets unreadable but they are coloured as standard UI elements instead of black on white.

There are two problems the current code has with dark themes. The first is it’s only overriding the foreground and background colours on some of the widgets in the panels, so the rest are being drawn with their default colours. This isn’t a problem if you’re using a theme where the text colour is the same for both UI elements and text areas but can make text unreadable if they aren’t. I’ve gone through and added code to change the colours on all the labels and other widgets which are supposed to be coloured that way and it produces a readable display for both light and dark themes.

The other problem is for some reason the style data attached to the widgets (which it’s using to set the colours) doesn’t reflect what’s in the theme. I added some debugging code to print out the colours in the styles for various widgets, and they seem to be the same whatever theme I have selected. This is why it’s always setting the background to white even if the theme has a different colour set for the text background. I’ve got no idea why this is happening, I haven’t noticed any wrongly coloured widgets in any other programs.

Our local nvidia-settings expert came up with a change that styles the text boxes using the appropriate text colors and restyles them on the fly when the theme is changed. The update should be in a future release of nvidia-settings.