Description of problem: Since upgrading to Red Hat Linux 8.0, my laptop panel no longer displays resolutions lower than the native resolution (1024x768). It now disallows all of the default modelines for 640x480 and 800x600, saying "hsync out of range". But nothing has changed about my laptop or my X configuration, and it worked fine before. Version-Release number of selected component (if applicable): XFree86-4.2.0-72 How reproducible: always. Steps to Reproduce: 1. start X. 2. press C-A-Pad+ Actual results: Nothing happens. Expected results: Resolution change. Additional info: I tried playing around with the monitor timing information in XF86Config, and noticed something odd about the log output. An old log from XFree86 4.1.0 said (**) R128(0): Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz (II) R128(0): Modeline "1024x768" 65.00 1024 1048 1065 1344 768 770 776 806 -hsync -vsync (**) R128(0): Default mode "800x600": 65.0 MHz, 44.6 kHz, 70.0 Hz (II) R128(0): Modeline "800x600" 65.00 800 824 841 1120 600 602 608 638 +hsync +vsync (**) R128(0): Default mode "640x480": 65.0 MHz, 37.5 kHz, 72.4 Hz (II) R128(0): Modeline "640x480" 65.00 640 664 681 960 480 482 488 518 -hsync -vsync as I expect. With the normal settings, XFree86 4.2.0 says (II) R128(0): Not using mode "800x600" (no mode of this name) (II) R128(0): Not using mode "640x480" (no mode of this name) (**) R128(0): Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz (II) R128(0): Modeline "1024x768" 65.00 1024 1048 1065 1344 768 770 776 806 -hsync -vsync if I increase the HorizSync and VertRefresh maxima to 80 and 150, respectively, this becomes (**) R128(0): Default mode "1024x768": 65.0 MHz, 70.3 kHz, 87.2 Hz (II) R128(0): Modeline "1024x768" 65.00 1024 1048 1065 1344 768 770 776 806 +hsync +vsync (**) R128(0): Default mode "800x600": 65.0 MHz, 50.3 kHz, 78.8 Hz (II) R128(0): Modeline "800x600" 65.00 800 824 841 1120 600 602 608 638 +hsy nc +vsync (**) R128(0): Default mode "640x480": 65.0 MHz, 37.5 kHz, 72.4 Hz (II) R128(0): Modeline "640x480" 65.00 640 664 681 960 480 482 488 518 -hsyn c -vsync so the refresh rates for 1024x768 and 800x600 have shot up for the exact same modelines. Also note that the refresh rates for the 640x480 mode are within the normal limits for the monitor (48.5 and 75, respectively), so it's not clear why this mode was rejected before. If I copy these modelines into the XF86Config file, the rates go up even more. Hmm, well, actually this isn't happening now, but on a previous test I got: (**) R128(0): Default mode "1024x768": 65.0 MHz, 70.3 kHz, 87.2 Hz (II) R128(0): Modeline "1024x768" 65.00 1024 1048 1065 1344 768 770 776 806 +hsync +vsync (**) R128(0): Mode "800x600": 65.0 MHz, 58.0 kHz, 91.0 Hz (II) R128(0): Modeline "800x600" 65.00 800 824 841 1120 600 602 608 638 +hsy nc +vsync (**) R128(0): Mode "640x480": 65.0 MHz, 67.7 kHz, 130.7 Hz (II) R128(0): Modeline "640x480" 65.00 640 664 681 960 480 482 488 518 -hsyn c -vsync again, the Modelines haven't changed, but the reported timings have. I suspect that there's something screwy going on with the timing calculations in XFree86 4.2.0. Either that, or it's something subtle to do with how laptop panels are driven.
Created attachment 89412 [details] X startup log. BTW, my laptop is a Dell Latitude C600.
also, after I tweaked the monitor timing info, the 800x600 display looked fine, but there was pretty bad distortion in the middle of the screen at 640x480, so I quickly switched away.
Most likely this is indeed a timing related problem. I have no LCD panels, nor laptop hardware however, so I can only look through the source code and make guesses. Nothing stands out at me, however this has been reported quite a bit. Does the problem occur in our phoebe beta as well?
The problem still occurs in phoebe beta 2; in fact, since anaconda normally only tries 800x600 and 640x480, it fails to start X entirely and falls back to text mode. I need to specify "linux resolution=1024x768" to get the graphical installer. BTW, why does anaconda redirect the X log to /dev/null? I need to run X manually to get at the log. Would it be useful for me to set up an account for you on my laptop?
>BTW, why does anaconda redirect the X log to /dev/null? I need to run X >manually to get at the log. No idea... I don't maintain or work on anaconda... >Would it be useful for me to set up an account for you on my laptop? Not really... There are tonnes of mission critical bugs open that I have the hardware physically here for already. You might want to also report the problem to xfree86 though.
Is this problem still present in our current tree in the latest build of XFree86-4.2.99.901-20030206?
yep, still there.
Please upgrade to Fedora Core 2 or later, and if this issue turns out to still be reproduceable, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates.