Bug 138714

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
driver?

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 6.8.1.12 as part of FC3 updates, but this did not
help. 

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-6.8.1.903 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
updates.

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:

"xrandr"

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

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

Greg

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.

Greg

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"
EndSection

This is a very low generic configuration, which will definitely
restrict the resolutions that are available in the resizing
utilities.

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

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.

Greg