I recently dumped my g550 for a fx5200, so now I am on binary-only drivers (sniff...) Today I encountered the nvidia-settings utility. I frowned very much when I tried 'nvidia-settings --load-config-only' to restore gamma-correction settings I had applied when running the utility with the gui. Instead of restoring my settings, it hung for a while, and then it said: ERROR: Cannot open display 'dice:0.0'. ERROR: Unable to assign attribute DigitalVibrance specified on line 17 of configuration file '/home/stsp/.nvidia-settings-rc.troublemaker' (no Display connection). ERROR: Unable to assign attribute DigitalVibrance specified on line 18 of configuration file '/home/stsp/.nvidia-settings-rc.troublemaker' (no Display connection). and spit out a lot more errors about being unable to assign any attributes in lack of a display connection. My settings were not restored :( But without --load-config-only, the gui starts as usual, and even restores my settings on startup... weird... Having time to spare, I dug out ddd and ran it on a freshly compiled nvidia-settings binary. I found out that when the nvidia-settings utility tries to connect to a display named "dice:0.0" (dice is my desktop), it fails with the above error. However, using display ":0.0" seems to work. The nvidia-settings code has about three sources for the display name to use. One is gtk, which uses display ":0.0", and that works fine. Before starting the gui, the code determines the display name using a function called NvCtrlGetDisplayName(), which I deem to be a hook into the nvidia driver. This function returnes the malicious "dice:0.0". (line 155 in query-asign.c). This display name is also used when wrinting the config file on exit. My config file (~/.nvidia-settings-rc) has lines such as: dice:0.0/DigitalVibrance[CRT-0]=0 and when I remove 'dice' changing them to :0.0/DigitalVibrance[CRT-0]=0 'nvidia-settings --load-config-only' works perfectly, as the display name is taken directly from the config file when loading the config. This is source number 3, for those who haven't been counting along ;-) So I have a workaround... But who's fault is this? I wrote a little test-app that tries to open a display. It fails to open display "dice:0.0" (hanging forever) but succeeds opening display ":0.0" With the test-app I can reproduce this problem on all of the three gentoo machines I have on my lan, with both xorg and xfree, with and without nvidia. But could this be a name resolution issue? dice is resolved to 192.168.0.1. Could X be configured to not accept connections from 192.168.0.1 (or anyone) to localhost? But 'xhost + dice' does not change anything... Or is nvidia doing something wrong here (read: non-standard)? Maybe the nvidia-settings utility should solely use the display name returned by gtk and not use NvCtrlGetDisplayName? How come these two return different values? Should NvCtrlGetDisplayName be fixed upstream? I hope someone can clarify this issue. thanks stefan
Created attachment 36719 [details] displaytest.c This is the test program I used, in case you want to try to reproduce this at home. To compile: gcc displaytest.c -o displaytest -L /usr/X11R6/lib/ -lX11
I just realised that the problem only occurs if you check the "Include X Display Names in the Config File" option on the nvidia-settings configuration page. The tooltip says: "It is normally recommended to leave this option unchecked." I had better read this before checking the option...
Hmm well if its the result of that checkbox as you say im not going to change anything. Afterall the host:display functionality is going to be useful for remote administration etc.. on remote Xterms.
