Bug 140596 - dual-head startup shouldn't depend on BIOS "boot display" choice
dual-head startup shouldn't depend on BIOS "boot display" choice
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-23 14:29 EST by Andrew D. Stadler
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-15 08:20:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 3015 None None None Never

  None (edit)
Description Andrew D. Stadler 2004-11-23 14:29:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.5 
(KHTML, like Gecko) Safari/125.11

Description of problem:
In the thinkpad T30 laptop, the BIOS includes an option for selecting the boot display 
device.  This is supposed to affect booting time only, and it even says in the little BIOS 
help text, "...until the OS is loaded".  

In the "Brand W XP" OS, this is true;  No matter what this is set to, once the OS itself starts 
up, the screens are initialized properly.

In X under Linux, unfortunately, improper setting of this value messes up the display 
manager and can put it into an unuseable state.

This has been tested in FC2 with IBM BIOS 2.06, and FC3 with IBM BIOS 2.06 and 2.08, with 
same behavior seen in all combinations.

Again, the specific bug I'm filing is that X should be ignoring this setting and starting up 
correctly in all conditions.

I would call this a minor annoyance, except for two issues:
1.  The BIOS "helpfully" resets this value to "both" when you go back onto a dock.  So even 
if you configure it properly once, you have to go back and fix it.
2.  To a user who hasn't faced this issue, it is very easy to get the machine in a state where 
it appears to be broken - blank screens after boot, with no obvious error messages or UI 
for restarting.  This shouldn't happen, obviously....

Version-Release number of selected component (if applicable):
xorg-x11-6.8.1-12.FC3.1

How reproducible:
Always

Steps to Reproduce:
1.   Boot FC3, plug in 2nd monitor, and configure dual head mode.
2.   Reboot.  F1 to enter BIOS.  Confirm setting "LCD".  Finish boot.  
3.   Confirm proper dual-head operation.
4.   Reboot.  F1 to enter BIOS.  Change boot display device to "CRT" or "BOTH" (2.06) or 
"Analog VGA" or "VGA+LCD" (2.08 - new names for same settings)
5.   Finish booting into FC3
    

Actual Results:  Primary display:  backlight on, but no image (all black)
Secondary display:  plain blue background (it's the extended unused area of the graphical 
login page)

Expected Results:  Primary display:  graphical login page
Secondary display:  plain blue background

Additional info:
Comment 1 Mike A. Harris 2005-02-01 00:38:50 EST
Please upgrade to the xorg-x11-6.8.1.903 (or newer) rpm packages in
Fedora development (rawhide), which contain numerous bug fixes
since the 6.8.1 release.  This will be finalized as 6.8.2 very
soon and released as an update for Fedora Core 3.

If the problem still exists in the new version of xorg-x11 in
rawhide, please file a bug report in X.Org bugzilla located at
http://bugs.freedesktop.org in the "xorg" component, detailing
the problem with specific steps to reproduce, and attaching
the config/log files to the X.Org report as you've done above.

Once you've filed your report in the X.Org bugzilla, if you paste
the URL here, Red Hat will track the issue in X.org bugzilla and
will review any fixes that become available for consideration in
future Fedora Core updates.

Thanks in advance.
Comment 2 Mike A. Harris 2005-02-01 00:46:08 EST
Setting status to "NEEDINFO", awaiting information requested in
comment #1
Comment 3 Andrew D. Stadler 2005-02-27 19:27:13 EST
Sorry it has taken me so long to address this;  I have been on a development crunch and 
couldn't take any chances w/my compiling machine.

Do you mean that I should upgrade xorg-x11-6.8.1-12.FC3.21 only, or *every* package 
containing xorg-x11-6.8.1*

My machine seems to include (note, all are xorg-x11-*-6.8.1-12.FC3.21)

xorg-x11 itself
Mesa-libGL
Mesa-libGLU
deprecated-libs
font-utils
libs
tools
twm
xauth
xfs

I can upgrade xorg-x11 only, or all of the above files.  Just let me know and I will complete 
the NEEDINFO as requested.
Comment 4 Andrew D. Stadler 2005-04-13 15:59:42 EDT
The latest FC3 update took me to or beyond the requested files.  I am
now running "latest" (6.8.2, I believe) x and I have confirmed that
this problem still exists.

Now filed as X bug 3015
<https://bugs.freedesktop.org/show_bug.cgi?id=3015>


Comment 5 Mike A. Harris 2005-04-15 08:20:23 EDT
Thanks, setting status to UPSTREAM for tracking in Xorg bugzilla.

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