Bug 82051

Summary: lower resolutions on laptop panel broken in XFree86 4.2.0
Product: [Retired] Red Hat Linux Reporter: Jason Merrill <jason>
Component: XFree86Assignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-24 19:13:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 82779    
Attachments:
Description Flags
X startup log. none

Description Jason Merrill 2003-01-16 20:43:47 UTC
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.

Comment 1 Jason Merrill 2003-01-16 22:03:07 UTC
Created attachment 89412 [details]
X startup log.

BTW, my laptop is a Dell Latitude C600.

Comment 2 Jason Merrill 2003-01-16 22:12:47 UTC
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.


Comment 3 Mike A. Harris 2003-01-16 22:56:32 UTC
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?

Comment 4 Jason Merrill 2003-01-17 22:26:12 UTC
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?

Comment 5 Mike A. Harris 2003-01-24 14:03:24 UTC
>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.

Comment 6 Mike A. Harris 2003-02-07 10:20:06 UTC
Is this problem still present in our current tree in the latest build
of XFree86-4.2.99.901-20030206?

Comment 7 Jason Merrill 2003-02-07 23:31:25 UTC
yep, still there.

Comment 8 Mike A. Harris 2004-09-24 18:59:15 UTC
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.