GNOME Bugzilla – Bug 667672
Fn+F4 could not switch display mode with some special monitor mode
Last modified: 2013-04-24 13:09:39 UTC
this issue can be reproduced with a laptop with LVDS(1920x1080) and external DP(2560x1600). and issue could not be reproduced with a small external monitor or small LVDS. System info: OS: RHEL6.2 driver： ATI Catalyst step to reproduce: 1,startx 2,plug the external monitor 3,LVDS and external DP work in clone mode 4, Fn+F4, Expected: Display mode switch successfully。 Actual: Fn+F4 cannot switch display mode。 and I found the following changes can fix this issue: 1, make_xinerama_setup() (gsd-xrandr-managers.c) add result->clone=false; to the end of this function. without this change, code will treat the xinerama_setup as clone mode if the current mode is clone. 2, with the first change the issue can be fixed. but when I use a small external monitor to do the test with the first change, the issue happened. and I found it is because : in crtc_assignment_new() (gnome-rr-config.c), code check the area of required_pixels with max_pixels. but in most graphic drivers(intel ,ati), they check the with>max_width and height>max_height. so in this case, an unsupported xinerama mode(Virtual size don't fit) can pass the sanitize , but could not apply, and issue happened . so add code if (required_pixels < min_pixels || required_pixels > max_pixels || with>max_width || height>max_height) to the crtc_assignment_new(). with the above changes, Fn+F4 can work.
Thanks for taking the time to report this bug. However, you are using version 2.28 which is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME (3.2 or 3.0).
On the other hand, if the current codebase still has this problem, could you attach a patch here? See http://git.gnome.org/browse/gnome-settings-daemon/tree/ for the web view, or http://live.gnome.org/Git/Developers for how to check out from the repository.
I found on opensuse12.1(GNOME 3.2.1) have the same issue.
I found on opensuse12.1(GNOME 3.2.1) have the same issue. (In reply to comment #2) > On the other hand, if the current codebase still has this problem, could you > attach a patch here? See > http://git.gnome.org/browse/gnome-settings-daemon/tree/ for the web view, or > http://live.gnome.org/Git/Developers for how to check out from the repository.
Please gather some debug output using 'touch ~/gsd-debug-randr', then sending us the ~/gsd-debug-randr.log file once you've reproduced the bug. And specify the exact versions of gnome-settings-daemon and gnome-desktop used
johnnylm, can you please provide requested information as per comment#5 ?
Hi Laddha Nocera, I also checked the issue, and I think it should be a gnome issue. from the gsd-debug-randr.log, we can see sometimes the xinerama configuration will be ignored if the clone not be set as false in the make_xinerama_setup(). Also, the issue can be duplicated in the latest gnome, e.x in gnome-settings-daemon 3.2, there still missed operation about setting clone as false, we could add a line : gnome_rr_config_set_clone(result ,0); in the make_xinerama_setup() to fix the issue Hope you guys can fix the issue ASAP, thanks :)
MaricoXu: We need log files, as described in comment 5. Otherwise we can NOT fix the issue. As you mention "latest GNOME": You could reproduce this in 3.4, or do you talk about 3.2?
Created attachment 214845 [details] log for gnome-settings-daemon
I have updated the log file. and the issue can be reproduced on Ubuntu11.10, which the version is 3.2
That's been fixed in GNOME 3.4 with this commit: commit 5f7643800a8bc26bd2835dc9a3df085bf0fab422 Author: Ray Strode <rstrode@redhat.com> Date: Tue Jun 5 10:30:06 2012 -0400 xrandr: explicitly set clone state variable when generating monitor configs Each potential monitor configuration that can be cycled through with fn-f7 on laptops is generated by copying and tweaking the current monitor configuration. One necessary, but neglected tweak, was the current "clone" state. This means the clone state of the current configuration leaks into every other config. Users who start in a cloned mode can never leave a clone with the hotkey. This commit explicitly sets the clone state appropriately. Patch based on valuable, and detailed feedback provided by Marico Xu. https://bugzilla.gnome.org/show_bug.cgi?id=677472 Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 677472 ***