Created attachment 129350 [details] [review]
Patch which fixes the bug

The following patch solves the problem. Basically moving a "goto" solved the problem as the intended configuration file was never applied otherwise.

Well. I don't have a multi-mnitor setup so I can't test that but I do get my configuration applied on startup. Your patch also says "ignore all errors" which is a very bad thing to do and might easily lead to crashes with other setups/drivers.

If you could try to poke bit deeper at what causes your problem (e.g. what's in the GError when this happens) that might help pin it down.

My patch simply says:

If there's an error in the backup file, no matter what kind of error, simply apply settings in the intended file instead of just freeing memory.

Currently, if I don't have a backup file, my intended file is ignored. This condition should be caught by G_FILE_ERROR_NOENT though.

Yes, however, you only should have that file around if something went wrong the last time you tried to change the resolution. What's the case where you happen to run into this?

If I copy my monitors.xml to monitors.xml.backup, the settings in the backup are applied. If no backup file is available monitors.xml is ignored (as apply_intended_configuration is never called).

What error do you get back from gnome_rr_config_apply_from_filename, then. Apparently, it's not the expected G_FILE_ERROR_NOENT, then.

if I do this inside the if-block which is supposed to catch G_FILE_ERROR_NOENT:

if (!g_error_matches (my_error, G_FILE_ERROR, G_FILE_ERROR_NOENT)) {
               if (!my_error) {
                    g_debug("my_error is NULL\n");
               }

                unlink (backup_filename);
                goto out;
}


I get exactly "my_error is NULL". I guess the GError is NULL, which explains why my_error->code is not G_FILE_ERROR_NOENT.

Interesting. I suspect you have found a bug in gnome-desktop.

Could you use gdb to step through what happens here:

        success = gnome_rr_config_apply_from_filename (manager->priv->rw_screen, backup_filename, &my_error);

and find out what function ultimately returns FALSE but doesn't set the error? Looking at the code, I don't see anything obviously suspicious.

Yes, as Jens says, please step through gnome_rr_config_apply_from_filename() and see what makes it return FALSE without setting an error.

The only case I know in the GnomeRR API where that could happen (return FALSE without setting the error) is in gnome_rr_screen_refresh(), but gnome_rr_config_apply_from_filename() already handles that case --- it means "I didn't refresh the screen because nothing has changed".

*** Bug 578120 has been marked as a duplicate of this bug. ***

hey all.

I am still experiencing that problem in ubuntu jaunty.
how can i solve it?
how do i apply the patch that is attached here?

thanks

(In reply to comment #11)
> hey all.
> 
> I am still experiencing that problem in ubuntu jaunty.
> how can i solve it?
> how do i apply the patch that is attached here?
> 
> thanks

I can't personally confirm that this works yet, but you should probably just

cp ~/.config/monitors.xml ~/.config/monitors.xml.backup

for now.

(source: Alberto Milone, Comment 5)

There is a related issue (though a different bug) in that 'Detect Monitors', `xrandr`, or just opening 'Configure Display Settings...' causes an auto-config of any new monitor setup, instead of loading the save config.  I've filed that as bug #615804.

Alberto, any chance you could check what error comes out of the apply_configuration_from_filename() call?

I'll mark this bug as obsolete for the following reason.

Since this bug was opened, the GnomeRR code in gnome-desktop got changed to return very detailed errors when a RANDR configuration can't be applied.

If you still have the problem, please get one of those detailed errors and reopen the bug with the error log:

1. touch ~/gsd-debug-randr
2. Restart your session; reproduce the problem
3. Get ~/gsd-debug-randr.log and attach it here.

Bastien, Federico, sorry about my late reply. It's fine to close this bug report as I can't reproduce the problem any more.