Created attachment 359884 [details]
Description of problem:
A week or two ago a rawhide update resulted in my display being limited to 800x600 instead of 1280x1024. I am not sure what package update broke things.
Version-Release number of selected component (if applicable):
I tried custom xorg.conf but the problem persists.
Steps to Reproduce:
Can you post your /var/log/messages too please?
Created attachment 359932 [details]
This is still happening with:
I'll probably go fill out a nouveau test day entry for this machine. I just haven't made time to do it yet.
Created attachment 361777 [details]
More recent Xorg.0.log
Created attachment 361778 [details]
More recent /var/log/messages
I played with this some more today (as trying to actually use a 800x600 display is annoying).
I switched the port used by the monitor from dvi 1 to dvi 0. This did not appear to have any affect on how things were displayed.
I tried configuring the monitor in system-config-display and that still wouldn't use any mode lines other than what were probed when X started.
I was able to issue a series of xrandr commands to create a new modeline, add it to dvi 0 and then switch to it. This allowed me to get 1280x1024 at 70 Hz. (See xrandr output below.) I don't know how to get this override to apply when X starts up using xrandr. I'll eventually try xorg.conf again, but at least the way I did overrides with it in the past isn't working any more. But maybe I missed something.
[bruno@games1 ~]$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096
DVI-I-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
800x600 85.1 72.2 75.0 60.3 56.2
640x480 85.0 75.0 72.8 59.9
DVI-I-1 disconnected (normal left inverted right x axis y axis)
Created attachment 362773 [details]
xorg.conf that works for me
I found out what was different. In the past when the display use an undesired resolution there was an available modeline to use. In this case there wasn't one, so I needed to add an appropriate modeline to use.
I have attached a working xorg.conf file, that makes the machine a lot more pleasant to use.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).
Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.
If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
Bruno, in Comment #8 you seem to indicate that this bug is no longer an issue, would you please verify?
Fedora Bugzappers volunteer triage team
It looks like the difference is the video driver being more cautious than in the past and mode lines that used to be generated aren't any more. The monitor doesn't do EDID properly (apparently, as I am not an expert in that) and the video driver doesn't know that 1280x1024 modes are safe. In the past the default was tp start X using a lower resolution, but still create some standard mode lines for higher resolutions. So I was able to just specify a resolution I believed to be safe in my xorg.conf file. Now I also have to define the mode line I want to use as well. I was able to do this with cvt. The resulting xorg.conf that is suitable for me was attached above. However, other people with monitors that don't do EDID properly should not blindly copy it. You need to look at the limits of the monitor (and video card) so as not to try to drive it out of spec.
It'd be nice if there was a more user friendly way to handle this, but if you are asking if the bug can be closed, from my point of view it can be. (In that case it would probably be closed NOTABUG as I was just caught be surprise in the change in behavior.)
Bruno, thank you for your (speedy) response. While I am minor-ly conflicted about making this into a 'futurefeature' marked bug to see if this could be handled better, for now I think we'll close it as you say. Ben's got other issues to handle. If we get more occurrences, however, we'll do that. If you decide it is important, enough to warrant further review, please reopen accordingly.
Again, thank you very much for your time and efforts in finding, reporting, and assisting in resolving this (non?) issue. :)
Fedora Bugzappers volunteer triage team