Bug 26265 - Framebuffer install loads wrong resolution
Summary: Framebuffer install loads wrong resolution
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Brock Organ
Whiteboard: Florence RC-2
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-06 00:31 UTC by Andreas Thienemann
Modified: 2007-04-18 16:31 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-16 19:15:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Andreas Thienemann 2001-02-06 00:31:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16-22 i686; Nav)

XServer loads with 640x480 resolution, while anaconda seems to expect
Thus the buttons (ok, cancel, next, back) are missing and parts of the
screen are inaccessible...

Reproducible: Always
Steps to Reproduce:
1. Default boot on an IBM Personal Computer 340 (Cirrus Logic GD5436)


Actual Results:  Framebuffer XServer loads up with resolution 640x480

Expected Results:  Framebuffer XServer should boot up with 800x600

/tmp/XFree86.conf.test (or something like this) lists the HorizSync
frequency as 31.5 - 35.0.  This seems rather low, and thus the XServer
rejects most frequencies...

Comment 1 Glen Foster 2001-02-07 00:20:09 UTC
We (Red Hat) should really try to fix this before next release.

Comment 2 Brent Fox 2001-02-08 22:03:15 UTC
I'd like you to try two things.
1) type 'nofb' at the boot prompt.  Does the problem still occur?
2) type linux vga=788.  The problem is that the default framebuffer mode that we
pass in is vga=787, which is 15-bit color.  This was my fault...I meant to say
vga=788, which is 16 bit color.  Does this have any effect?

Comment 3 Andreas Thienemann 2001-02-08 22:36:13 UTC
No in both cases. Neither nofb, nor linux vga=788 does make a difference.
The screen is still in just 640x480 mode.

The file /tmp/X.Log still says all 800x600 modes are deleted due to hsync being out of range.
/tmp/XFree86.conf.test still lists the monitor as having a hsync of 31.5-35.0 (give or take 0.5).

Comment 4 Brent Fox 2001-02-09 09:06:18 UTC
Weird.  Can you tell me what kind of monitor and video card you have?  We try to
keep a tally on monitor/video card combinations that cause problems and then try
to isolate the problems.  That information would be helpful.

Comment 5 Andreas Thienemann 2001-02-09 14:36:39 UTC
Of course. The Monitor is an IBM P72 (Model/Type: "6556-03N") and the video card
is a Cirrus Logic GD543x (Chipset: "CL-GD5436-I-QC-B").
I hope this helps.
On the other hand, on a Matrox Millenium G400, in combination with a IIyama
monitor, everything works as it should...

Comment 6 Brent Fox 2001-02-10 00:00:06 UTC
Can you try the IIyama monitor with the Cirrus Logic card?

Comment 7 Brent Fox 2001-02-14 09:06:54 UTC
From looking at some other bugs, there seems to be a problem with Cirrus Logic
cards in general.  Perhaps we should raise the monitor sync rates.  However, the
IBM P72 monitor entry in the monitors database reads:
IBM; IBM 6556 P72; ibm199c; 30.0-85.0; 50.0-150.0; 1
So, our Hsync range (31.5-35.0) should be fine.  I think the problem is with the
card...not the monitor.

Comment 8 Brent Fox 2001-02-14 09:17:22 UTC
I need a Cirrus Logic card to reproduce this issue.  Putting in NEEDINFO state.
 Brock, do we have one of these in the test lab?

Comment 9 Brent Fox 2001-02-15 00:51:52 UTC
Can you attach you XF86Config file?  Also, the output of ddcprobe would be helpful.

Comment 10 Brent Fox 2001-02-16 19:15:03 UTC
Ok, I think this should be fixed now.  I upped the default sync rates.  They
used to be:
        self.monHoriz = "31.5-35.2"
        self.monVert = "50-61"

And now they are:

        self.monHoriz = "31.5-57.0"
        self.monVert = "50-70"

Brock, please verify that this works now.  Please reopen if the problem reappears.

Note You need to log in before you can comment on or make changes to this bug.