Bug 26265 - Framebuffer install loads wrong resolution
Framebuffer install loads wrong resolution
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
Brock Organ
Florence RC-2
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-05 19:31 EST by Andreas Thienemann
Modified: 2007-04-18 12:31 EDT (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Andreas Thienemann 2001-02-05 19:31:29 EST
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
800x600.
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-06 19:20:09 EST
We (Red Hat) should really try to fix this before next release.
Comment 2 Brent Fox 2001-02-08 17:03:15 EST
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 17:36:13 EST
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 04:06:18 EST
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 09:36:39 EST
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-09 19:00:06 EST
Can you try the IIyama monitor with the Cirrus Logic card?
Comment 7 Brent Fox 2001-02-14 04:06:54 EST
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 04:17:22 EST
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-14 19:51:52 EST
Can you attach you XF86Config file?  Also, the output of ddcprobe would be helpful.
Comment 10 Brent Fox 2001-02-16 14:15:03 EST
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.