Bug 824757

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Dell would like to request this fix for RHEL6.3 updates.

Business Case:

   All new Generation Dell Precision Portables with AMD Gfx currently show this issue with Display Switching. This is a high priority for Dell, since these platforms will launch in the next couple of months and this issue severely affects the use of external displays with those laptops.

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.

Regarding part (2) of comment 0 , at some point this change was made (http://git.gnome.org/browse/gnome-desktop/commit/?id=8ba5e616ceb10ae8f1138eaa550ec65742195b78)

Allow rotation if the virtual size has the correct number of pixels

We checked for the rotated size actually fitting in the virtual size; now we just check for the virtual size having the required number of pixels.

--- a/libgnome-desktop/gnome-rr-config.c
+++ b/libgnome-desktop/gnome-rr-config.c
@@ -1666,14 +1666,18 @@ crtc_assignment_new (GnomeRRScreen *screen, 

+ required_pixels = width * height;
+ min_pixels = min_width * min_height;
+ max_pixels = max_width * max_height;

- if (width < min_width || width > max_width ||
- height < min_height || height > max_height)
+ if (required_pixels < min_pixels || required_pixels > max_pixels)
{

So, at some point the check was made more lax to allow rotated configs to work.  I guess.

I've pushed both changes upstream:

http://bugzilla.gnome.org/show_bug.cgi?id=677472
and
http://bugzilla.gnome.org/show_bug.cgi?id=640237

i've filed bug 829891 to cover the gnome-desktop part of these changes

Done in gnome-settings-daemon-2.28.2-22.el6
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=4817289

The patch "0001-xrandr-explicitly-set-clone-state-variable-when-gene.patch" added here breaks XRandR plugin in gnome-settings-daemon as it uses gnome_rr_config_set_clone() which is not available in gnome-desktop-2.0 API on el6.

** (gnome-settings-daemon:14261): WARNING **: /usr/lib64/gnome-settings-daemon-2.0/libxrandr.so: undefined symbol: gnome_rr_config_set_clone

** (gnome-settings-daemon:14261): WARNING **: Cannot load plugin 'XRandR' since file '/usr/lib64/gnome-settings-daemon-2.0/libxrandr.so' cannot be read.

** (gnome-settings-daemon:14261): WARNING **: Error activating plugin 'XRandR'

Created attachment 609902 [details]
Updated patch

gnome-desktop-2.0 API has no gnome_rr_config_get_clone() / gnome_rr_config_set_clone(), so using it in el6 would prevent the XRandR plugin from loading as the symbols remain unresolved.

This patch changes structure data directly instead.

With the updated patch in gnome-settings-daemon-2.28.2-25.el6
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=4840704

Dell would like to test these fixes and provide feedback. It seems we would need both gonome-settings-daemon and gnome-desktop package to verify the fix. Can we get links to these packages to test?

Thanks..
   --rez

I am having some trouble with this fix. I am using a Wacom Cintiq 24HD as a monitor and a Dell M6300 laptop with an Nvidia Quadro FX 1600 G84.

Fresh installation of 6.4 with gnome-settings-daemon-2.28.2-30.el6.

I start the session with a cloned (mirrored) setup. Next, I use the hot key (fn + f8) to switch the screen setup. It goes from cloned to extended with one hit, then just the laptop screen with a second hit. On the third hit it should just put the 24HD on, but it leaves both screens blank.

Technically, it can leave the cloned state by using the hot key making this bug "verifiable." I was wondering if this is a known or related issue.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0312.html