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.
Steps to Reproduce:
1. Login. See refresh is at 85HZ (-> causes screen distortion on my
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.
Refresh rate switches to 85Hz whenever X server is restarted.
X should remember my refresh rate of 60Hz and use that.
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
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
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.
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.
Closing this out; don't have the HW to reproduce/test/... this issue any more.