GNOME Bugzilla – Bug 677474
display switch hotkey doesn't work when monitor starts in clone mode
Last modified: 2012-06-05 17:39:01 UTC
+++ This bug was initially created as a clone of Bug #677472 +++ 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 bigdesktop mode set logic of Most graphic drivers(intel,ati) is try to set two buffers in one screen, and we need the width and height of screen to fit the two buffers. Otherwise gnome-settings-daemon think the configuration can pass ,and actually the driver can not apply the configuration. ( the issue only can reproduce in some special cases) Ray Strode [halfline] 2012-06-04 16:37:21 EDT 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'm tempted to revert that change. The function already takes rotated outputs into account when figuring out the width and height variables, and I don't think the maximum size of the entire screen (in the X since, not a single monitor) changes when the user does randr rotation. Maybe there was a flaw in the initial calculation of width and height before and this fix made that flaw disappear?
See also bug #640237.
Indeed, basically a dupe. *** This bug has been marked as a duplicate of bug 640237 ***