Bug 138714 - Screen Resolution stuck on 640x480
Summary: Screen Resolution stuck on 640x480
Alias: None
Product: Fedora
Classification: Fedora
Component: hwdata   
(Show other bugs)
Version: 3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-10 20:19 UTC by Greg Douglas
Modified: 2014-03-17 02:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-17 16:01:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
X11 Config File (2.67 KB, text/plain)
2004-11-10 20:56 UTC, Greg Douglas
no flags Details
Xorg Log File (30.31 KB, text/plain)
2004-11-10 20:57 UTC, Greg Douglas
no flags Details
X server log (29.17 KB, text/plain)
2005-02-10 18:54 UTC, Greg Douglas
no flags Details

Description Greg Douglas 2004-11-10 20:19:49 UTC
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):

How reproducible:

Steps to Reproduce:
1.Appears in lower res immediately at login prompt.  Problem is in
Gnome and in KDE.

Additional info:

Comment 1 Mike A. Harris 2004-11-10 20:22:10 UTC
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.

Comment 2 Greg Douglas 2004-11-10 20:56:40 UTC
Created attachment 106441 [details]
X11 Config File

Comment 3 Greg Douglas 2004-11-10 20:57:39 UTC
Created attachment 106442 [details]
Xorg Log File

Comment 4 Greg Douglas 2004-11-10 20:59:38 UTC
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.

Comment 5 Greg Douglas 2004-11-18 20:35:38 UTC
Just upgraded to X11 as part of FC3 updates, but this did not

Comment 6 Mike A. Harris 2004-11-18 23:50:21 UTC
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.

Comment 7 Mike A. Harris 2005-02-01 10:41:16 UTC
Please upgrade to the xorg-x11- 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.

Comment 8 Greg Douglas 2005-02-02 15:56:13 UTC
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.

Comment 9 Mike A. Harris 2005-02-08 02:04:04 UTC
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.

Comment 10 Greg Douglas 2005-02-10 18:54:06 UTC
Created attachment 110930 [details]
X server log

February 10, 2005

Comment 11 Greg Douglas 2005-02-10 19:00:04 UTC
Thanks Mike.

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


Comment 12 Greg Douglas 2005-02-10 19:05:24 UTC
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.


Comment 13 Mike A. Harris 2005-02-11 16:14:46 UTC
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:

Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Compaq 140"
	DisplaySize  250	190
	HorizSync    31.0 - 49.0
	VertRefresh  48.0 - 80.0
	Option	    "dpms"

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.)

Comment 14 Greg Douglas 2005-02-17 16:00:16 UTC
Thanks Mike.

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.



Note You need to log in before you can comment on or make changes to this bug.