Bug 4147

Summary: radeonfb fails with external display
Product: Drivers Reporter: Jakob Schi (schiotz)
Component: Console/FramebuffersAssignee: Antonino Daplas (adaplas)
Status: DEFERRED WILL_FIX_LATER    
Severity: normal CC: protasnb
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.11-rc4 Subsystem:
Regression: --- Bisected commit-id:
Attachments: /usr/src/linux-2.6.11-rc2/.config
/usr/src/linux-2.6.11-rc4/.config
dmesg output.

Description Jakob Schi 2005-02-02 02:10:17 UTC
Distribution:  Gentoo
Hardware Environment:  IBM Thinkpad T30 model 2366 with Radeon Mobility 7500
Software Environment:
Problem Description:

I place my thinkpad in a port replicator with a digital video output to a flat
screen.  It works fine if I build the kernel without framebuffer, but if I build
with framebuffer (radeonfb) then the output goes to the internal screen instead.
 If I build radeonfb as a module, then output switches to the internal screen
when the module is loaded.

I see it in the following kernel versions:  2.6.10, 2.6.11-rc2, 2.6.11-rc2-mm2

Strangely, if I apply the "Another whitelist patch with command line option for
forcing" from bug 3022 to the 2.6.11-rc2-mm1 kernel, then the external screen
works fine - until X starts at which point I get a black screen and a locked-up
keyboard.


Steps to reproduce:
Comment 1 Jakob Schi 2005-02-02 02:11:01 UTC
Created attachment 4497 [details]
/usr/src/linux-2.6.11-rc2/.config
Comment 2 Jakob Schi 2005-02-02 02:30:30 UTC
I had forgotten to save the output of dmesg, so I booted back into the
2.6.11-rc2 kernel to produce it.  But this time everything worked.  I tried a
few times without problems, and considering that it had failed several times
earlier today, I am deeply mystified.  But since I cannot be 100% sure that I
did not do something wrong previously, I guess that I can only withdraw my bug
report.

I'll reopen it if I get any reproducible data.

Comment 3 Jakob Schi 2005-02-22 05:54:13 UTC
I reopen this bug because it looks like it is a real problem, it is just not
100% reproducible.  In most cases, when I boot a 2.6.11-rc4 kernel with radeonfb
frame buffer enabled, the output goes to the build-in screen instead of the
external screen attached to the docking station.  See the description above.

It looks like in a few cases (including the day I closed my bug as invalid) it
works, but it is not reproducible, and I cannot figure out why it in rare cases
work.

It unfortunately makes the framebuffer unusable,for me, since I use an external
display at work.

I'll attach dmesg output and .config, and will be happy to provide any other info.
Comment 4 Jakob Schi 2005-02-22 05:55:25 UTC
Created attachment 4589 [details]
/usr/src/linux-2.6.11-rc4/.config
Comment 5 Jakob Schi 2005-02-22 05:57:30 UTC
Created attachment 4590 [details]
dmesg output.

dmesg output from when I booted the 2.6.11-rc4 kernel with an external display
attached through the port replicator.  The output from the BIOS and grub went
to the external display, but once the kernel started booting output switched to
the internal display.
Comment 6 Jakob Schi 2005-03-02 03:41:09 UTC
It appears to be related to the resolution.  The built-in display is 1400x1050
and the external display is 1280x1024.  The framebuffer should choose the latter
resolution when the external display is attached, but apparently does not (at
least not consistently).  If I force the framebuffer to use 1024x768 then it
works fine on both screens, so that is a working workaround.

Given that there is a workaround, this no longer deserves to be a high-severity bug.

Comment 7 Antonino Daplas 2005-07-31 22:32:43 UTC
That's usually the problem with dual-displays, you have to know what is the
least common denominator which, in your case, is the display with the lower
maximum resolution.  We don't have any definite support yet for dual heads/dual
displays,  so I'll defer this bug. 
Comment 8 Natalie Protasevich 2008-03-05 17:25:52 UTC
Any new status on this problem? Has it been fixed?
Thanks.
Comment 9 Jakob Schi 2008-03-06 01:16:39 UTC
I unfortunately no longer have the affected laptop, so I am unable to test if it works in newer kernels.  Probably the bug should be closed.