Bug 473365

adding an additional section to xorg.conf:

Section "Monitor"
	Identifier "GenericMonitor"
	Option "DPMS"
	HorizSync 28-51
	VertRefresh 43-60
EndSection

and a corresponding: Monitor "GenericMonitor" in the Screen section has allowed the Preferences > Hardware > Screen Resolution to kick res to 1024x768, with the 
vesa driver.

How is the monitor autodetected ?

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 324997 [details]
xorg.conf for vesa, 1024x768

Created attachment 324998 [details]
log for vesa, 1024x768

Created attachment 325000 [details]
log for no xorg.conf

I confirm the same problem on the same hardware.  My panel is made by IBM instead of by Samsung, but the specs are the same.

Also, I notice symptoms of a general bug.  The Xorg.0.log contains (separate lines, but in chronological order):
-----
(--) R128(0): Chipset: "ATI Rage 128 Mobility M3 LF (AGP)" (ChipID = 0x4c46)
(**) R128(0): Using flat panel for display
(II) R128(0): Panel size: 1024x768
(II) R128(0): <default monitor>: Using default hsync range of 31.50-37.90 kHz
(II) R128(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan)
-----
So R128 knows that the panel is 1024x768, and knows that the chipset can drive such a panel, and knows that the display is the panel, but nevertheless chooses a hsync that prevents displaying the native resolution of the panel.  That's a bug.

I had a similar problem as the one described on this page and have now solved it. However I'm not sure that it will help you but with some luck it may work for you also.

What I discovered, after reading your posts above, is that the xorg engine doesn't seem to be able to activate the higher resolution if the HorizSync and VertRefresh rate isn't set. This is very common to occur since these are not so important values for a flat screen of lap top screen.

I entered the following in my xorg.conf and left anything else to default, i.e. not specifying any driver r128 or vesa. Just the monitor part below.

Section "Monitor"
    Identifier   "Generic Monitor"
    Option       "DPMS"
    HorizSync    31.5-55
    VertRefresh  40-70
EndSection

I hope this will help you as it did me.

Reporter, could you check the documentation of your display and card and try to replicate comment 7?

Does it help?

Created attachment 346500 [details]
with Section Screen

Created attachment 346501 [details]
without section screen

Without a Section "Screen" in xorg.conf, X comes up in 800x600. Current xorg.conf is:

Section "Monitor"
	Identifier "GenericMonitor"
	Option "DPMS"
	HorizSync 31.5-55
	VertRefresh 40-70
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Videocard0"
	Monitor    "GenericMonitor"
	DefaultDepth     24
	SubSection "Display"
		Viewport   0 0
		Depth     24
		Modes "1024x768" "800x600" "640x480"
	EndSubSection
EndSection

The attached xorg.0.log (with section screen) and xorg.0.log.old (without section screen) show X is using the r128 driver and mumbles about:

"(II) R128(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan)" 
about line 237 (with Section Screen) or 244 (without Section Screen)

and:

(II) R128(0): Modifying mode according to VBIOS: 1024x768 [pclk 65.0 MHz] for FP to: 1024x768 [pclk 65.0 MHz]
about line 293 (with Section Screen)

(II) R128(0): Modifying mode according to VBIOS: 800x600 [pclk 40.0 MHz] for FP to: 800x600 [pclk 65.0 MHz]
about line 300 (without Section Screen)

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

On my laptop F11 still does not work, but after upgrading to F12 it works without a xorg.conf.

Reporter, are you able to confirm comment 13 (i.e., that this has been fixed in F12)?

Thank you in advance

no, I cannot confirm it, I no longer have the hardware.

Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we cannot continue working on fixing this issue.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as INSUFFICIENT_DATA.