Red Hat Bugzilla – Bug 138714
Screen Resolution stuck on 640x480
Last modified: 2014-03-16 22:50:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020
Description of problem:
Screen resolution on the System Settings - Display is set to 1024X768,
but Gnome Preferences, Screen Resolution is stuck at 640x480. I was
able to get full 1024x768 resolution in the most recent FC2 release.
Monitor: Compaq 140
Video driver"S3 Unichrome"
Fully updated FC3 as of today.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Appears in lower res immediately at login prompt. Problem is in
Gnome and in KDE.
Attach your X server log file and config file to the report as
individual uncompressed file attachments using the link below.
Are you using the driver shipped with Fedora Core, or a 3rd party
Thanks in advance.
Created attachment 106441 [details]
X11 Config File
Created attachment 106442 [details]
Xorg Log File
Yes, I am using the driver that came with FC3. It was not available
in FC2, thereby requireing me to use the generic VESA driver.
Hope this helps.
Just upgraded to X11 126.96.36.199 as part of FC3 updates, but this did not
Correct, the new 6.8.1-12.FC3.1 release for FC3 is a security fix
to fix vulnerabilities in the libXpm library. It does not address
any issues with the via driver.
Please upgrade to the xorg-x11-188.8.131.523 in rawhide to see if that
addresses the issue you are experiencing. If the problem persists
in the rawhide release, please report it to X.Org via their bugzilla
located at http://bugs.freedesktop.org in the "xorg" component.
Once you have filed your bug report to X.Org, if you paste the URL
here, Red Hat will track the issue in the upstream tracker, and
review any fixes that become available for consideration in future
Setting status to "NEEDINFO", awaiting upstream bug URL and
feedback of testing of rawhide xorg-x11.
Just updated my xorg-x11 the the version in #7. The System Settings -
Display Settings are set at S3 Unichrome, and the display to
1024X768. Unfortunately, the resolution is still in 640X480. It
appears to be stuck in the GNOME Preferences - Screen Resolutions
Preferences, and not on the X11 settings. Therefore I wonder if the
problem is in GNOME, and not in X11.
The GNOME Screen Resolution Preferences does not give me a choice
other than 640X480, while the System Settings - Display Settings
gives me all the appropriate choices.
Hope this helps.
Ok, thanks for the info. Open up a terminal and run the
following command, and paste the output you get back into
the bug report:
This should provide a list of all resolutions/refresh rates
available via the RANDR extension, which is what the GNOME
control center applet uses to resize on the fly. Please also
attach the X server log from the same session you run 'xrandr'
under, so we can compare the current X server configuration to
what resolutions are available under RANDR.
This will help to narrow down the problem, but I suspect it is
a GNOME control-center glitch.
Thanks in advance.
Setting status to "NEEDINFO", awaiting 'xrandr' test results and
updated X server log file.
Created attachment 110930 [details]
X server log
February 10, 2005
Here is the output from xrandr:
SZ: Pixels Physical Refresh
*0 640 x 480 ( 250mm x 191mm ) *60
Current rotation - normal
Current reflection - none
Rotations possible - normal
Reflections possible - none
As well, the documentation on the Compaq 140 monitor that I am using
indicates that it can support a max resolution of 1024X768,
HFreq/VFreq of 31-48khz/50-100hz.
I am currently using the Generic VESA driver at the 1024X768 in the
mean time, but the VIA driver documentation recommends the S3
Unichrome driver for the KM400 chip set that I am using.
Hope this helps.
The X server log file shows all other resolutions being rejected
due to being out of range for the current configuration. The
RANDR extension is only making available the resolutions the
X server shows valid for this configuration.
The monitor's configuration is:
VendorName "Monitor Vendor"
ModelName "Compaq 140"
DisplaySize 250 190
HorizSync 31.0 - 49.0
VertRefresh 48.0 - 80.0
This is a very low generic configuration, which will definitely
restrict the resolutions that are available in the resizing
This is not a video driver or X server bug, but a configuration
issue. Re-run system-config-display --reconfig and it will
generate a new config file for you. If it does not detect your
monitor correctly, it is possible your monitor does not support
DDC. DDC can also be blocked if you are using a KVM or other
cables of any sort between the video adaptor and monitor cable.
You may have to manually select your monitor from the list of
monitors instead, however if your monitor is not listed in the
database, then you'll have to manually configure it in the
config file by hand.
If you would like any monitors added to the Red Hat monitor database
for future OS releases and updates, you can obtain the Windows
.INF file from the manufacturer's website or on CD or floppy disk
that came with the display, and attach the .INF file as a bugzilla
file attachment. Once you've attached the .INF file, we can
add it to the hwdata package, and it will automatically show up
in the list of available monitor choices in the future.
Once your monitor is configured correctly in xorg.conf, the
X server video modes available will be less restricted, and you
will have more choices available in the config tools.
Reassigning to hwdata component, and awaiting attachment of the
Windows .INF file for this monitor (assuming it isn't already
in our database.)
Fortunately, the monitor already appears in the database, and has been
detected correctly (even with my KVM). The settings are a little
different from what I was able to find on the Web, but it is so old
that Compaq no longer provides any specs or .INF file on it.
I tried the different settings, and the results are the same.
Therefore I agree that this is no more than a configuration issue, and
that the newer S3 UniChrome driver simply does not support this older
monitor. Instead, I should use the VESA (Generic) driver.
From my perspective, we can close this bug.
Thanks you so much for your help.