nvidia-settings doesn't have permissions to write xorg.conf

[Greg Taylor]

Binary package hint: nvidia-settings

On the latest Hardy update, nvidia-settings doesn't seem to have permissions to write the xorg.conf when you click the 'Save to xorg.conf' button. You get an "Unable to create xorg.conf.backup" error message. If you close out of the app and launch it via gksu from a terminal, saving works fine.

[Kevin DuBois (kdub)]

xorg.conf is a critical system file for most users, IMO. An unprivileged user should not have write access. It may be wise to prompt for the root password, instead of simply exiting with an error.

[Greg Taylor (gtaylor)]

It seems like the issue here is that nvidia-settings isn't using the new Gnome privileges escalation system (I can't remember what it was called). It should at a minimal be called with gksu (which would prompt for a password), and at best use the privilege escalation system.

[era (era)]

Confirming since I got this too. This is on Hardy beta, installed from 2008-03-20 live CD.

This really really ought to be fixed before Hardy release.

[era (era)]

> nvidia-settings isn't using the new Gnome privileges escalation system
> (I can't remember what it was called).

You mean AppArmor?

[Greg Grossmeier (greg.grossmeier)]

Policy-Kit

[Michael Basil (michael-ashtonbrsc)]

It would be better for nvidia-settings not to be in the main menu than to fail to save its settings although it shouldn't be too easy to mess around with an important file like xorg.conf.

[Peter Nauta (pnauta)]

I can confirm it is still broken in Inteprid beta1.

[Alberto Milone (albertomilone)]

Rationale: nvidia-settings doesn't have to be launched as root as it saves the user's settings to ~/.nvidia-settings-rc (so as to have per user settings). What we could do is make it use PolicyKit to ask the password only when the xorg.conf must be modified.

I'm marking this as a wishlist report.

[Christian Funder Sommerlund (zero3)]

Alberto, if nvidia-settings throws an "Access denied" error message when changing any of the settings, surely this is more of a bug than a wishlist item?

[Alberto Milone (albertomilone)]

Christian:
if you launch it with "sudo" you will be able to save your settings.

I'm pretty sure that NVIDIA is aware of the problem,however I don't think that adopting a solution with PolicyKit upstream is an ideal solution for them as it would prevent nvidia-settings from working on systems that don't use PolicyKit.

[Christian Funder Sommerlund (zero3)]

Isn't that exactly the point? :)

If nvidia-settings requires superuser access, then the menu shortcut for Ubuntu should probably be prefixed with "gksu"?

There doesn't seem to be much point in having a graphical frontend in the menu if users are required to jump into a terminal and prefix "sudo" themselves anyway (that is - after they run into the bug after launching nvidia-settings the normal way).

[Alberto Milone (albertomilone)]

Christian, no, please read what I wrote in comment 8. Nvidia-settings shouldn't be launched with root privileges unless you need to modify your xorg.conf.

[Christian Funder Sommerlund (zero3)]

I fully agree! The problem is just that the user probably won't know which settings that require xorg.conf write-acess (and shouldn't need to!). Seeing that nvidia-settings doesn't use any kind of privilege escalation system, the user might get stuck with an error after changing settings. Assuming that there is consensus about such error being unacceptable, I only see 2 immediate solutions:

1) Patch nvidia-settings to use privilege escalation (Policy-Kit?)
2) Always run nvidia-settings with superuser access

Personally, I'd prefer solution 1), but if that is too much work then 2) seems acceptable to me as well. 2) isn't ideal, as you point out, but still better than throwing write-access errors in my opinion.

[Alberto Milone (albertomilone)]

I could work on solution 1) and forward the patch to NVIDIA and the Debian maintainer of nvidia-settings. It's too late to do it for Intrepid though.

[Christian Funder Sommerlund (zero3)]

1) would indeed be the best solution in my opinion, assuming xorg.conf is the only way to actually apply these settings, and xorg.conf must require superuser access to modify.

Can't we send it out as a patch for Intrepid after the release then?

[Alberto Milone (albertomilone)]

I can file an SRU when the patch is ready but then the MOTU-SRU team will decide what to do.

[Christian Funder Sommerlund (zero3)]

Okay :)

[lewmur (lew-lewmur)]

Solution: Edit the menu properties for Nvidia X Server Settings and change the "Type" from "Application" to "Application in Terminal." Then place "sudo" at the beginning of the "Command Line." Then when the Menu option is clicked, a terminal window is openned and you are asked for the sudo password. Enter it and the app runs with root privileges.

[Alberto Milone (albertomilone)]

lewmur: please read comment 8 and the next comments.

[lewmur (lew-lewmur)]

I did read them. And your point is?

[Fabian A. Scherschel (fabsh)]

His point is that you are not supposed to run nvidia-settings as a superuser and therefore shouldn't tell people to change their menus.

BTW, I am not affected by this bug in Intrepid. Apart from bug #286424, nvidia-settings started from the Administration menu (without gksu) works perfectly for me.

[lewmur (lew-lewmur)]

Oh?? There is a law saying "Don't run nvidia-settings" as a superuser? Nonsense. So long as it requires the sudo password, there is no reason not to do so except FUD. It is far better to have nvidia-settings write to xorg-conf than to have a novice doing so through a terminal editor.

BTW, if you haven't been affected by the bug, it is probably because you haven't changed anything that required saving xorg-conf. The app runs fine otherwise.

[lewmur (lew-lewmur)]

For those purist that think it is too dangerous to have nvidia-settings run as superuser by default, create a script that allows the user to choose whether run it directly or as superuser and have it warn them of the danger of possibly having to manually replace xorg-conf from the CLI. Then have the menu option run the script.

At least that way, you are not asking Nvidia to re-write nvidia-settings.

[Fabian A. Scherschel (fabsh)]

It is generally always a bad idea to have things run as superuser that don't absolutely need to. Since Alberto is the maintainer for the NVIDIA stuff, I trust his word when he says it doesn't have to. He's also working on this, so what's the fuss about?

BTW, had you read the bug I linked, you would have seen that it is also concerned with writing xorg.conf from nvidia-settings. For some reason it works for me from the Administration menu without sudo. I don't know why, but I can save to my xorg.conf.

[Alberto Milone (albertomilone)]

lewmur: had you read comment 8 you would have seen the reason why nvidia-settings shouldn't run as root. Anyway, here's my point:

"Rationale: nvidia-settings doesn't have to be launched as root as it saves the user's settings to ~/.nvidia-settings-rc (so as to have per user settings)."

[Savvas Radevic (medigeek)]

Has anyone filed this to nvidia?

[lewmur (lew-lewmur)]

"Rationale: nvidia-settings doesn't have to be launched as root as it saves the user's settings to ~/.nvidia-settings-rc (so as to have per user settings)."

It may save some of the settings there, but not all. Try setting up dual monitors without modifying xorg.conf.

And I still haven't seen any "rationale" that would make my last suggestion invalid. A script would not have to be written by Nvidia and it would give the user the option of running with or without superuser mode. Unless, of course, you think people shouldn't be given sudo privileges on their own computers.

[Alberto Milone (albertomilone)]

lewmur: I volunteered to add the support for PolicyKit to nvidia-settings but of course if you want to write a script yourself you're more than welcome to do so.

[lewmur (lew-lewmur)]

Alberto;
Using PolicyKit is obviously the best appraoch and your effort is apprieciated. All I intended the script alternative to be is something to use while that is being done. Take a look at these and see if they won't work.

nv1.sh
echo "It is not recommended that this application be run in SuperUser mode unless you"
echo "are experiencing proplems saving the xorg.conf file. Doing so can cause the"
echo "X server to fail to execute."
echo ""
echo "The first time you choose SuperUser, the /etc/X11/xorg.conf file will"
echo "be saved as /etc/X11/original-xorg.conf."
echo "Each time after that, it will save the current /etc/X11/xorg.conf as "
echo "/etc/X11/last-xorg.conf."
echo ""
echo "Do you wish to run in SuperUser Mode? y/n"
aa=""
read aa
if [ $aa = "y" ]
then
sudo sh /etc/X11/nv.sh
else
nvidia-settings
fi

nv.sh

cd /etc/X11
if [ -f "original-xorg.conf" ]
then
echo cp xorg.conf original-xorg.conf
else
cp xorg.conf last-xorg.conf
fi
nvidia-settings

[lewmur (lew-lewmur)]

Both nv.sh and nv1.sh should be placed in the /etc/X11 directory with the Menu pointing to nv1.sh.

[Aaron Plattner (aplattner)]

I've been thinking about exactly this issue. As for supporting PolicyKit in the upstream release, we ought to be able to get away with dlopening libpolkit-dbus.so.2 at runtime and using the helpers from that if they exist. I've got a prototype that I threw together that I'll try to clean up and attach at some point. However, I'm no PolicyKit guru so I don't know if the approach I took is the right one.

Alberto, do you know if there's a standard PolicyKit action for writing the X config? If not, I could just add com.nvidia.settings.write-x-configuration and have the .policy file be part of the nvidia-settings package. There's a org.freedesktop.systemtoolsbackends.set ("Manage system configuration"), but that seems overly vague.

[Alberto Milone (albertomilone)]

As discussed in #xorg-devel, you might want to put a function (e.g. from the parser that you use in nvidia-settings) which can write the settings with root privileges in the dbus part. Nvidia-settings should then pass the configuration to that function through dbus.

[Aaron Plattner (aplattner)]

I threw together a prototype patch (attached) and uploaded a build to my PPA. Let me know if this is what you meant. I didn't quite understand what you meant by "put a function [...] in the dbus part." I wanted to keep the setuid part as simple as possible, so I left all of the parser stuff in the non-setuid part.

[Alberto Milone (albertomilone)]

By dbus part I really meant PolicyKit “mechanism". The mechanism is a separate program. Basically the mechanism is started with root privileges and acts as a dbus server to which you can connect from your client application (nvidia-settings) which is also called “agent”. When you request the authorisation from the agent (which runs unprivileged) you can call a function which is part of the mechanism. This function is the one which should write the settings to the xorg.conf.

Maybe you could make your xconfigWriteConfigFile() function create an array of strings which then you could pass to the mechanism's function “kit_file_set_contents ()” (see the link below) so that the contents of the xorg.conf are set to whatever nvidia-settings generated. In this way you can keep the parser in the agent and have just one function in the mechanism.

http://hal.freedesktop.org/docs/PolicyKit/polkit-kit-file.html

[Kyriacos (luckyzzkl)]

save the xorg.conf on the desktop
and
cp /etc/X11/xorg.conf /etc/X11/xorg.bak
sudo cp /home/you/Desktop/xorg.conf /etc/X11/xorg.conf

ctr+alt + backspace

Tada!!!

[mmomjian (matthew-momjian)]

Yeah, I think everyone knows how to work around this bug... its a
feature request.

---------------------------------------------------------------------------

Kyriacos wrote:
> save the xorg.conf on the desktop
> and
> cp /etc/X11/xorg.conf /etc/X11/xorg.bak
> sudo cp /home/you/Desktop/xorg.conf /etc/X11/xorg.conf
>
> ctr+alt + backspace
>
> Tada!!!
>
> --
> nvidia-settings doesn't have permissions to write xorg.conf
> https://bugs.launchpad.net/bugs/200868
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.

--
  Matthew Momjian <email address hidden>
  I am an actor at Hedgerow Theatre, I am a member of the ROBOWhizards.
  and have been in 20 plays there. I play piano, trumpet, and sing.

[Adam Calafrancesco (godnessgracious)]

As an intermediate user who has recently succeeded in setting up dual screens in intrepid, i'd like to offer my two cents here. Most novices are never going to find this menu because it doesnt come in with the drivers. I had to google deep to find the nvidia-settings package. I ran into this issue of not being able to save the xorg.conf. It was pretty simple to figure out how to run it with gksudo in the terminal. Since this is the workaround most people will find they are going to be running it as root anyway, why not just set it up that way. Its exactly as dangerous i think. Also if this package had just come in with the driver i wouldn't have been trying to manually edit xorg.conf earlier in the day. I appreciate the experience that it gave me working with more internals, as i'm actively trying to learn more about linux, but most users do not want to get that involved.

[Gary Cordery (tailzer42)]

Hi,
I just have to add that I have had this problem in the last couple Ubunutu releases too, only just getting to grips with what it means to be part of the community and report this sort of problem. If the app is put in the menu it should work?? If people think it is too dangerous to run as root then it shouldnt be their by default when the restricted drivers are used??
This is a very useful tool when run manually from terminal especially when configuring dual monitors.

[Aaron Plattner (aplattner)]

Somebody from Ubuntu needs to decide whether the setuid PolicyKit helper is acceptable, or if something more complicated involving a daemon that connects to dbus needs to be written. If running a daemon is required, then we probably won't be able to support it in the upstream code.

Assigning to Alberto to reassign to whoever makes those decisions. Feel free to reassign back to me if something different needs to be implemented.

[Nietzsche Keen (keen-nietzsche)]

The simple solution is that there are two places in which settings must be changed.
The first is in Nvidia settings as root user - run: sudo nvidia-settings from terminal.
Second, change the resolution settings under System-Preferences-Screen Resolution
You may need to reboot between steps.

That second step is so basic it is often overlooked.
No cutting and pasting xorg.conf, no dangerous dabbling in forbidden zones.

Also, if Nvidia isn't activated, do that under System-Administration-Hardware Drivers

[Nietzsche Keen (keen-nietzsche)]

I should elaborate on how to save root Nvidia settings;
After choosing the proper resolution, choose "Apply" "OK", "Save to X Configuration File"

This should set the proper settings for the root. (Even though you are probably the primary user and operating under the first username you set up, you are not 'root' which is accessed through terminal using 'sudo' for Ubuntu though it is different for other distributions. Check their forums for details).

[John B. (jbuncher)]

@Nietzsche Keen: The first solution is not really a solution, as a user should be able to use all parts of the nvidia-settings gui when launched from the menu (rather than from the command-line with sudo), and currently that doesn't work with changing the resolution and refresh rates. Running sudo nvidia-settings from the terminal is certainly a workaround, but not a solution.

Second, changing the resolution settings under System-Preferences-Screen Resolution is also not a solution, as due to the way the nvidia driver handles things and interacts with X the refresh rates don't show up correctly to GNOME, so it is not clear to someone with the nvidia driver using that gui what the refresh rate of their card/screen really is, nor can they change it easily. The nvidia-settings app shows the correct values.

At any rate, as -Zeus- noted above, most everyone knows how to work around the bug, it's a question of getting the app fixed so that it behaves correctly.

[scotta3234 (scott-anderson)]

This issue appears to still be complicated/unresolved to many end-users, as I have twice now explained to them on how to properly do this. Please continue to find the best possible solution.

[Vadim Peretokin (vperetokin)]

Definitely a good papercut. Easily solvable and very much affecting (without
this, your settings changes just silently fail for the most part)

[Travis Watkins (amaranth)]

This is actually not a good paper cut because "it requires writing more than a few lines of code". If there was an accepted patch and the only thing left was to apply it to the package then it would probably qualify but the sudo tricks and menu editing are hacks and the PolicyKit solution was never accepted and would most likely need to be updated at this point.

[bajabaq (tsw)]

I disagree that this is not a good papercut - if all that is required is to append gksudo to the front of the launcher for the nvidia-settings - then this should be done.

And, yes I have read the above comments (8 etc) about superuser access - however, I fully agree with what Christian Funder Sommerlund wrote on 2008-10-10 - it would be better not to have it present than present and broken. Or at least have it throw a warning when it needs to write to xorg.conf and fails.

This is specifically a problem for dual screens, which as they become more prevalent this will become a bigger issue.

Not to mention that several other programs under the System->Administration menu require 'sudo' access, why not have one more?

[Travis Watkins (amaranth)]

Hacks are not fixes. Also, is this program even installed by default? Paper cuts are only for things installed by default.

[lewmur (lew-lewmur)]

Calling something that works perfectly well a hack is nonsense. The perfectionists that keep claiming this have had plenty of time to fix this in the so called "right way" and it still hasn't been done. It is totally asinine to let this situation continue for two years when there is a perfectly simple solution. There is no legitimate reason at all for not using gksudo. To claim there is a "right way" to do this when it has been over a year and the so called "right way" is still waiting implementation, is laughable.

[lewmur (lew-lewmur)]

I'd really like for someone to explain in REAL terms, not some theoretical BS, just what makes gksudo a hack, and Policy-Kit, which no one seems to be capable of implementing, not a hack. If gksudo is a hack, I'll still take a working hack over a non-working Policy-Kit everyday of the week.

[Travis Watkins (amaranth)]

If you run with gksudo you're running a full GUI app as root for no reason _and_ causing a bug because the .nvidia-settings-rc file will be saved for the root user instead of for the user running the app so setting changes they make that _don't_ write to xorg.conf will not be saved in the correct location.

I would say just making a full GUI app run as root is enough of a bug to not implement this 'fix'. We're trying to reduce the number of apps that do such a thing, not increase them.

[lewmur (lew-lewmur)]

And I say there is a very good reason for doing so. It is the only way to get dual monitors to work for the average user. The only other way is to change the ownership of xorg.conf which belongs to root to begin with. There is NOT a good reason for not allowing nvidia-settings to run with root privileges

You claim the saving .nvidia-settings-rc with root ownership is a bug. I say BS. Just what problem does that cause other than raise the blood pressure of paranoids? I've had dual monitors running this way for close to two years and have had no problems at all.

Again, if you have a BETTER solution, then implement it. Don't just talk about it. Otherwise I'll keep advising people to do what works.

[Travis Watkins (amaranth)]

You are certainly welcome to advise them of your workaround for this bug. I just don't believe such a thing should be added to the package.

[Savvas Radevic (medigeek)]

> Again, if you have a BETTER solution, then implement it.  Don't just
> talk about it.  Otherwise I'll keep advising people to do what works

I'd have to agree with this comment, Ubuntu is (or should be) all
about the human needs, not the "proper" thing to do (which seems to
take enough time to be implemented).

> Hacks are not fixes. Also, is this program even installed by default?
> Paper cuts are only for things installed by default.

I don't know about that, but the papercut specifications include
these: https://launchpad.net/hundredpapercuts
a) - bugs that impact standard workflows (like connecting to the
network, copying files, browsing folders, etc.), rather than
specialised or corner case workflows

It is a standard workflow, people install the nvidia driver all the
time. Even though nvidia-settings is in universe, nvidia-settings _is
suggested_ by System > Preferences > Display: "It appears that your
graphics driver does not support the necessary extensions to use this
tool. Do you want to use your graphics driver vendor's tool instead?"
(which opens up nvidia-settings)

b) - bugs that are easy to address, rather that ones that require
significant design or development efforts

I don't know and probably will not be the judge of this one, but if
the PolicyKit seems hard, there is the alternative issue of applying a
mere workaround for the time being, using gksu in the menu item.

c) - bugs that relate to usability and design (like size of the
notification bubbles), rather than broken software (e.g. notifications
flickering in fullscreen)

It is highly related to usability.

> I would say just making a full GUI app run as root is enough of a bug to
> not implement this 'fix'.

That's a bug *everyone* could live with, until the proper fix comes out.

> You are certainly welcome to advise them of your workaround for this
> bug. I just don't believe such a thing should be added to the package.

I have posted this as a papercut because it just is and there is an
easy solution (at least one of the available ones).

If we implement the gksu usage as an easy temporary solution, people
will have less to think about while fixing up their resolution issues.
This way, the developer would not be rushed into making a fix and
would make a properly defined fix with the PolicyKit patch.

Right now, I see an easy workaround, which you don't want to implement
just because it's not "proper", and a hard one, which will probably
take time to be implemented. It is a papercut issue to me and probably
(IMHO) some other people trying to help out their fellow humans how to
install their driver properly.

[Travis Watkins (amaranth)]

Actually, once a quick 'fix' like this gets implemented there is zero motivation to work on the proper fix and it'll probably never happen.

Either way, it isn't up to me since I don't handle this package.

[Christian Funder Sommerlund (zero3)]

While lewmur IMHO is a big aggressive in his opinion, I have to agree with him. This is a big usability issue for nvidia users (~25%). I completely agree with Savvas Radevic as well. While a gksudo fix might not be the most ideal way to solve this problem, it is the only thing we have right now - and IMHO we shouldn't trash it simply because it doesn't live 100% up to the standards.

It's been over a year since this bug was submitted, which means that nvidia users have been bugged by this for *at least* 3 releases. I honestly don't think it is fair to keep nvidia users trapped in this any more.

At the very least, you could change this bug away from the bogus "Wishlist" status and grant it the status of the bug it is, with a priority according to the severity of this bug.

[Michael Kofler (michael-kofler)]

Ubuntu makes the installation of Nvidia drivers easy as in no other major distribution. Nobody forced the Ubuntu developers to so -- but they did, and personally I consider this a wise decision and one reason for the success of Ubuntu. I guess that most Ubuntu users with Nvidia graphic card do install the Nvidia driver.

But saying A means you also have to say B: You can't first invite the user to install the Nvidia driver and then present him/her with an obviously broken configuration tool. That's absurd! Fix it (papercut or not)!

From my experience, it is not sufficient to start nvidia-settings with gksudo. You first must prepare xorg.conf to contain (at least) these lines:

Section "Device"
      Identifier "Configured Video Device"
      Driver "nvidia"
EndSection

This is no major effort and should qualify as a papercut.

[lewmur (lew-lewmur)]

To those who feel I've been overly aggressive in my comments, I'll just say that after dealing with this situation through three releases, my patience has worn thin. Over a year ago, I went so far as to write a script that would warn the user about the dangers of running the applet as root, check to see if the original xorg.conf file was saved and if not, save it. Then backup the current xorg.conf file and finally invoke nvidia-settings via gksudo.

Even this was not enough for the proponents of "doing it the proper way." They warned, as someone just did, that a "work around" would prevent a "true fix" from being implemented. Well, I shut up for over a year and waited for the "true fix." It still hasn't arrived. So, yes, I've decided to take a more aggressive stand. It is obviously necessary to do so.

As to the Section "Device" code someone says needs to be added to xorg.conf, implementing the nvidia drivers put that in my xorg.conf. It wasn't necessary for me to do it manually.

[Savvas Radevic (medigeek)]

I have just noticed that this was assigned to Alberto Milone 6 months back, but it was assigned to him by someone else. That was a wrong move probably, because it's like saying "I got this, I'll do this ASAP".
After 6 months of no progress, I'll set it to "Nobody" in case someone wishes to take care of this.

Aaron Plattner has attached a patch that I think was not reviewed:
https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/200868/comments/31
https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/200868/comments/33
https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/200868/comments/39

[lewmur (lew-lewmur)]

https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/200868/comments/39

This pretty much says it all. Alberto was going to write the patch but asked the higher ups how they wanted it done and never got a response.

"If you run with gksudo you're running a full GUI app as root for no reason _and_ causing a bug because the .nvidia-settings-rc file will be saved for the root user instead of for the user running the app so setting changes they make that _don't_ write to xorg.conf will not be saved in the correct location.

I would say just making a full GUI app run as root is enough of a bug to not implement this 'fix'. We're trying to reduce the number of apps that do such a thing, not increase them."

Anybody else spot the prejudice involved in the preceding statement? What makes a GUI app anymore dangerous to run as root than a non-GUI app? Sounds to me like the old bugaboo about "real Linux users don't use GUI." Pure BS. Particularly when Ubuntu's stated aim is to make things as seamless as possible for Windoze converts.

As to the ".nvidia-setting-rc" claim, that file doesn't even exist on my machine. But in general, all executable files should be in root folders, not in the /home/"user"

[Aaron Plattner (aplattner)]

lewmur, .nvidia-settings-rc is not an executable, it's a configuration file that nvidia-settings uses to save user preferences for the server configuration. Wearing my "Ubuntu user" hat, I would personally prefer not having it save things like my brightness and contrast settings in root's home directory by default. If the gksudo change is applied and then the bug is later fixed some other way, users will be confused when the settings they had previously saved into ~root/.nvidia-settings-rc are no longer applied because the program is now reading ~/.nvidia-settings-rc instead.

Wearing my "upstream maintainer" hat, I don't really have a say in what Ubuntu does here. If there's a way of changing xorg.conf from a non-root program in a reasonably standard and reasonably distro-agnostic way, I'll be sure to include it upstream.

[lewmur (lew-lewmur)]

As I said, there is no .nividia-settings-rc file on my machine so I don't much care where it is saved. And at the rate its taking I'm not really concerned about what happens after "the bug is later fixed." It will undoubtedly occur after I've installed another release anyway. I'm not going to do without dual monitors because they've failed to fix this bug.

[Fabian A. Scherschel (fabsh)]

I for one must agree with lewmur. I think it is an absolute joke that this hasn't been fixed by now. Users do not care how you fix it as long as you do. In the moment, an application that everyone that I've ever talked to uses who runs Ubuntu and has an nvidia card, is fundamentally broken as far as the user is concerned.

I know that Launchpad isn't really meant to discuss these kinds of things, but for goodness sakes, it's obvious that this is not intended behaviour, right?

[Morten Justesen (morten-justesen)]

I have made my own fix that uses PolicyKit and a dbus service, I have made this to learn the build and PPA process and how to use PolicyKit and dbus.
https://launchpad.net/~morten-justesen/+archive/ppa/+sourcepub/682796/+listing-archive-extra
But I thought I would share it, it works but I must warn I'm a complete newbie with this stuff.

[Savvas Radevic (medigeek)]

Thank you!! We'll need someone to review the patch ( Albero Milone? ).

Are all those direct changes to files (except in ./debian/ folder) for policy kit and dbus?

To speed things up, I'm including a debdiff patch. I compared it to current jaunty.

In case you're wondering how I did the debdiff:
$ apt-get source nvidia-settings
$ dget -u https://edge.launchpad.net/~morten-justesen/+archive/ppa/+files/nvidia-settings_180.25-0ubuntu2~ppa3.dsc
$ debdiff nvidia-settings_180.25-0ubuntu1.dsc nvidia-settings_180.25-0ubuntu2~ppa3.dsc > ~/Desktop/patch.debdiff
More info and example: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff

> But I thought I would share it, it works but I must warn I'm a complete newbie with this stuff.
Any help is *very* appreciated! :)

[laulau (olaulau)]

a good solution si to change the shortcut to
gksu "nvidia-settings"
in order to run as root, and so you can save xorg.conf in /etc/X11 .
this is normal, as the shortcut is in the "system" > "administration" menu.

[lewmur (lew-lewmur)]

That is the solution I offered about four releases ago. Check reply #18 in this thread. Then read all the guff I received for daring to suggest you run a GUI app as superuser.

[Artur Rona (ari-tczew)]

I guess that Albertio is going to fix this bug by the new upstream of nvidia-settings ;) good luck!

[Launchpad Janitor (janitor)]

This bug was fixed in the package nvidia-settings - 190.53-0ubuntu1

---------------
nvidia-settings (190.53-0ubuntu1) lucid; urgency=low

  * New upstream release (LP: #417410).
  * debian/control:
    - Add build dependency on cdbs.
    - Remove build dependency on dpatch.
    - Add lpia architecture.
    - Depend on screen-resolution-extra >= 0.12.
  * debian/patches/02_nvidia-settings-format-string.patch:
    - Patch from Mandriva to pass formatted strings to gtk dialogs (thus
      reducing gtk warnings).
  * debian/patches/03_xf86vidmode-rampsize-check.patch:
    - Fix FTBFS with recent versions of XF86VidMode.
  * debian/patches/04_include_xf86vmproto.patch:
   - Include xf86vmproto.h so as to get back XF86VidModeGetGammaRampSize().
  * debian/patches/05_polkit.patch:
    - Add support for PolicyKit so that nvidia-settings doesn't require
      that users call it with sudo to edit xorg.conf (LP: #200868)
      (requires screen-resolution-extra >= 0.12).
  * debian/rules:
    - Switch to CDBS.
    - Do not provide a desktop file. The different nvidia packages will
      deal with it.
 -- Alberto Milone <email address hidden> Sun, 10 Jan 2010 12:12:42 +0100

[Fabian A. Scherschel (fabsh)]

That was fast. Thanks, Alberto! :)

[Artur Rona (ari-tczew)]

Not fixed. Got:
1) Failed to parse existing X config file '/etc/X11/xorg.conf'!
2) Unable to open X config file '/etc/X11/xorg.conf' for writing.

Zainstalowana: 190.53-0ubuntu1

[Alberto Milone (albertomilone)]

@Artur
That's because your settings won't be written if your xorg.conf is not valid.

Please attach your xorg.conf

[Alberto Milone (albertomilone)]

@Arthur
I had to update screen-resolution-extra because of a change in the new PolicyKit. Otherwise when I launched nvidia-settings from the command line I got this error:
dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Error parsing subject struct

It works well now.

Please install version 0.13 of screen-resolution-extra and try again:
https://launchpad.net/ubuntu/+source/screen-resolution-extra

[anatoly techtonik (techtonik)]

Is it going to be released for Karmic?

[cappelikan (cappelikan)]

sudo chmod +x /usr/share/screen-resolution-extra/nvidia-polkit fix write problem