Created attachment 322690 [details] Xorg.0.log showing the problem Description of problem: When not capped by list of valid modes in xorg.conf, an impossibly high display mode is selected causing monitor to blank itself (thank goodness for the self-protecting monitors these days...). The display adapter is ATI RV350 AP [Radeon 9600] and monitor Hitachi CM721F. Version-Release number of selected component (if applicable): F10 preview, xorg-x11-drv-ati-6.9.0-38.fc10 assuming it's the ATI driver and not something else acting up. I don't know if this was present in F9 or whether it was just masked by xorg.conf being created by default, with something probing the supported modes correctly there. How reproducible: Every time. Steps to Reproduce: 1. On the hardware described above, start X with no xorg.conf Actual results: Monitor blanks out due to impossible mode. Expected results: Working mode selected from DDC results. Additional info: Looking at Xorg.0.log, DDC probing seems to give sane results for the monitor, eg 1600x1200 only interlaced, up to 1280x1024 reasonable refresh rates and: (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "1920x1440" (hsync out of range) (II) RADEON(0): Not using default mode "2048x1536" (hsync out of range) Yet it goes on to pick up 2048x1536 unless told otherwise in xorg.conf: (II) RADEON(0): Using fuzzy aspect match for initial modes (II) RADEON(0): Output VGA-0 using initial mode 2048x1536 To the unitiated, it seems like it just picks up the highest supported mode by the adapter, ignoring the DDC probe results. But I'm utterly clueless when it comes to X inner workings so I'll stop guessing now... Happens both in graphical installation and on installed system when X starts, the fancy new graphics from plymouth up to that point are shown just fine, and nomodeset to kernel didn't make any difference so it doesn't seem to be KMS issue.
Additional test results: downgrading to F9 version of the ATI driver (xorg-x11-drv-ati-6.8.0-19.fc9.x86_64.rpm) fixes this: a sane resolution is picked up even when xorg.conf doesn't exist. Can and will try bisecting it down but if you have suspects you'd like me to try first, that'd be helpful.
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.
Well... I already said this happens exactly when there is no xorg.conf, or when you have one without specifying list of valid modes for the monitor. This problem comes from the Fedora specific radeon-6.9.0-remove-limit-heuristics.patch patch. With that patch removed, X starts in a resolution supported by the monitor. Looking at the patch, it would appear to be about what the *controller*, not the monitor, can support. Maybe it's just plain luck that the monitor can go to 1600x1200 which is the resolution the heuristics picks - I dunno. In any case, the logs clearly show (will attach shortly) that with the remove-limit-heuristics patch, it thinks it's ok to use resolutions far beyond what DDC probing gives.
Created attachment 322963 [details] X startup log with stock xorg-x11-drv-ati-6.9.0-38.fc10 Here's the X startup log with stock xorg-x11-drv-ati-6.9.0-38.fc10 - ie the one that picks a way out of range mode for the monitor.
Created attachment 322964 [details] X startup log with radeon-6.9.0-remove-limit-heuristics.patch removed ..and here's the one with radeon-6.9.0-remove-limit-heuristics.patch not applied, ie the one where it picks up a resolution that's within DDC probe results.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The patch is still present in F10. If you can, please test it again.
The issue is still present in F10 (xorg-x11-drv-ati-6.9.0-63.fc10), starting X without xorg.conf to limit the resolution will still pick an invalid mode.
Current rawhide correctly capped the mode to 1600x1200 max, and in any case I wouldn't be able to further test this as I've switched to a new monitor recently -> closing.