A downstream reporter wrote on https://bugzilla.redhat.com/show_bug.cgi?id=824757 that display hotkey switching wasn't reliable for him.

Relevant comments:

MaricoXu 2012-05-24 03:54:58 EDT

Description of problem:
when the user try to use the hot key (depend on the system , some is Fn+F8,and some is Fn+F4), the xinerama configuration will not show, and sometimes other display wrong issue will happen.

Actual results:
the xinerama configuration will not show or the switch operation cannot work. and sometimes

Expected result:
the four switch operations(clone,xinerama,laptop,extern) should work succcessfully

The Code Change can fix the issue:
       (1) libxrandr.so :
           code change:  in the function make_xinerama_setup()  (gsd-xrandr-managers.c)
          gnome version>3.0
            add gnome_rr_config_set_clone(result ,0); to the end of this function.
         gnome version<3.0
           add result->clone=false; to the end of this function. 

           When the user is doing the hotkey switch operation first time, gnome will call make_**_setup() function to setup the configurations for the future use.
However the original logic in gnome-settings-daemon didn’t deal with the clone flag well.  The clone flag should be set as false in the xinerama case.



Ray Strode [halfline] 2012-06-04 16:03:10 EDT

So to clarify comment 0, gnome-settings-daemon does something like the following pseudocode when constructing the list of of possible output configurations to cycle through when the user presses fn-f7:

generate_fn_f7_configs (...) {
   configs = new array;

   configs += current_setup();
   configs += make_clone_setup();
   configs += make_xinerama_setup();
   configs += make_laptop_setup();
   configs += make_other_setup();
   configs += previously_saved_to_disk_setup();

   remove_duplicate_configs (configs);

   fn_f7_configs = configs;
}

each of these make_..._setup() functions starts with a copy of the current setup, that they tweak until it fits the characteristics of the desired config. So, for example, make_xinerama_setup will start with a current config, and then position the configuration offsets of the outputs so they are side-by-side. 

If the current configuration is cloned at the time generate_fn_f7_configs is called, the config->clone will be set to TRUE, and every generated config will have config->clone=TRUE since those config generation functions don't explicitly set it to a value that makes sense for their particular configs.

Later, when the user presses, fn-f7, gnome-settings-daemon cycles through and applies the next config in the array using the gnome-rr apis.  the gnome-rr code then does this, as part of applying the configuration, then looks at the clone property:

make_outputs(config) {
    for (each output in config.outputs) {
        if (config->clone) {
          /* ignore output width/height and just use geometry of first output for all outputs*/
          output.width = config.outputs[0].width
          output.height = config.outputs[0].height
          output.rotation = config.outputs[0].rotation
          output.x = config.outputs[0].x;
          output.y = config.outputs[0].y;
        }
    } 
}

So these make_..._setup functions carefully placed the monitors to fit their desired layout, but neglected to change clone appropriately, then the presence of clone causes those carefullly placed monitors to get overridden with a clone setup.

Note, setting config->clone is an accepted part of the gnome-rr api.  control-center does it when the user toggles "mirror screens", and the reporter is correct, gnome-settings-daemon should set it as well in its make_..._setup functions.