Red Hat Bugzilla – Bug 146576
X doesn't remember my refresh rate selection.
Last modified: 2007-11-30 17:10:59 EST
Description of problem: My monitor is failing. It's rated for 1280x1024@85Hz, but will only do 60Hz reliably. It's also rated for higher resolutions, but won't do them reliably. I've managed to get Fedora to always display 1280x1024 using the GUI tool "system settings/display". However, it always picks 85Hz every time I reboot or logout. Every time I login, I use the GUI tool "preferences/screen resolution" to select 60Hz, which correctly changes the refresh rate for that session, but the setting is never remembered - loggin out, or rebooting, will always switch back to 85Hz. This occurs I log in as root or my user, and whether I check the box to make the option "default for this host only" or not. I've tried editing xorg.conf and setting min/max vertical frequency to exactly 60Hz, but that didn't help. Version-Release number of selected component (if applicable): FC3 + all updates as of 1/29/2005. How reproducible: Always. Steps to Reproduce: 1. Login. See refresh is at 85HZ (-> causes screen distortion on my monitor) 2. Go to GUI tools "Applications/Preferences/Screen Resolution". Click OK, and then keep resolution. See that the display is now 60Hz as I asked. 3. Log out. 4. In the chooser display, refresh rate is back at 85Hz. It should be at 60Hz like I asked. 5. Log in. Note that refresh rate isn't restored to my preference of 60Hz here either. Actual results: Refresh rate switches to 85Hz whenever X server is restarted. Expected results: X should remember my refresh rate of 60Hz and use that. Additional info: N/A.
Oops. In step 2 in reproduction steps, insert the text "change refresh rate drop-down to 60Hz." before the "click OK" part...
Thanks for your report. There are 2 ways to set your resolution and refresh rate. 1) By direct configuration of the X server config file. 2) By using "xrandr" or some other utility that can change the resolution and/or refresh rate at runtime on the fly using the XRANDR extension. When the X server starts up, it probes the monitor when that is possible, and it uses the capabilities the monitor advertises to prune down the list of video modes and refresh rates, to that which the monitor can handle. It then uses the first video mode, at the highest refresh rate, that is within the probed limits of what the hardware can handle (unless the config file further overrides this and manually specifies the ranges directly). This is the resolution/refresh that the X server starts in. After that point, any other application can change the resolution and refresh rate by using the RANDR X extension, and both KDE and GNOME have utilities to do this, as well as the commandline "xrandr" utility that comes with X.Org X11. When you change the resolution or refresh rate in the X server config file, those changes will not occur until the next time you start the X server, and every subsequent invocation. However, if you use xrandr, or a GNOME or KDE utility to change the resolution/refresh, this is not a permanent change to the X server configuration. It is a one time change that only affects the current X session. Once you quit X, the change is gone, and the next time the X server starts up, it will again use the settings in the X server config file. The utility you refer to in "step 2" above, is using RANDR to change the resolution on the fly, and does not change the X server configuration. It was my understanding that the GNOME/KDE resolution switcher apps stored the user's preferences in gconf or kde configuration files, and automatically invoked them the next time the user logged in, so the settings stick over X server restarts, however if you are using these tools and the settings are not sticking around, then it would be a bug in the resolution changer utility not saving its settings and restoring them properly. Here are a few options for you: 1) Run system-config-display and change the resolution, etc. directly and save the new X config file, and restart X. This makes the change permanent at the X server level. You may also need to manually edit the X server config file to tweak it a bit, because it will default to working like your monitor is not broken (as it should). You'll probably need to force the maximum refresh rate to that which you want. or 2) Reassign the bug report to the component in GNOME (or KDE) that contains the on-the-fly resolution/refresh switcher utility, so that it can be investigated as a bug in that tool. Also note that the RANDR config utilities only change per user settings, they do not affect the X server globally, such as gdm login screens. To change the refresh rate of that, you must reconfigure the xorg.conf file. Setting status to "NEEDINFO", awaiting bug reassignment.
OK. I tried editing /etc/X11/xorg.conf. I had originally specified this: VertRefresh 50.0 - 60.0 However, I think this was ignored, perhaps because there weren't any modes within this range? I think my actual refresh is something like 60.2. Anyway, I updated it do this: VertRefresh 50.0 - 65.0 and now X does use the 60Hz rate when it restarts. So, I have a fix for the issue. However, I'm still going to go ahead and re-assign the bug, because the GUI tool should setup my session default when I log in.
I hope GConf is the correct component to assign this to? If not, re-assign as appropriate.
If the HorizSync and VertRefresh lines are present in the config file, in the section the X server is actively using, they will be honored, and syncs outside of the range will be disallowed, even if DDC probing the monitor yields wider ranges. They override any DDC probing. GConf is the GNOME config registry tool. Settings can be stored in the GNOME registry via gconf. gconf itself does not have anything to do with X configuration. Reassigning to gnome-applets as I don't know the specific component that the GNOME randr utility is in.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Closing this out; don't have the HW to reproduce/test/... this issue any more.