On Fri, Mar 23, 2012 at 03:42:44PM -0400, Alex Deucher wrote:
Since Linux 3.0, a system with a Radeon HD 5450 (1002:68f9) connected to a 27" Apple LED cinema display via an Atlona AT-DP400 Dual Link DVI to Mini DisplayPort converter has started to stop giving screen output on switching from text mode to graphical framebuffer during system startup.
I finally had some time to look at this, and it seems to have stopped working after this commit:
commit df271bec805b42527d864777ed035fcbb42e76c0 Author: Alex Deucher alexdeucher@gmail.com Date: Fri May 20 04:34:15 2011 -0400
drm/radeon/kms: properly handle bpc >8 in atom command tables
Signed-off-by: Alex Deucher alexdeucher@gmail.com Signed-off-by: Dave Airlie airlied@redhat.com
...and with the patch below (i.e. reverting part of the commit above) applied to 3.3 I get screen output again.
Even though the monitor seems to have an 8 bit panel, it reports 10 bits per channel in its EDID:
[...] Manufacturer: APP Model 9226 Serial Number 41959462 Made week 38 of 2010 EDID version: 1.4 Digital display 10 bits per primary color channel DisplayPort interface Maximum image size: 60 cm x 34 cm [...]
The (active, dual link) DVI->mDP converter spec sheet says it supports 24 bit color, and I'm guessing that it can't deal with 30. Is the converter at fault here for passing through the EDID unchanged?
Also, what would be the right way to handle this, a kernel command line or module option to limit color depth or something like that? ("Buy a video card with DP output." is a valid answer, I suppose.)
I have no clue at all about graphics, and I have no idea whatsoever what I'm doing here, but I just wanted to post this somewhere for Google to find in case someone else runs into this!
I've inquired with out display team on how to best handle this. In the meantime, it's probably best to just default to 8 bpc. Does the attached patch fix your issue?
I've been using the patch below in a custom Fedora 17 kernel RPM, and that seems to fix the issue. Your patch seems to be a superset of this patch, so logically, your patch should do the trick as well. :)
Can you try the attached patch on top of my previous one?
Scratch that. Try this one instead.
The 3.3 + 0001-drm-radeon-kms-atom-force-bpc-to-8-for-now.patch + 0001-drm-radeon-kms-improve-bpc-handling-v2.patch combo seems to work fine -- I get display output as expected.
Tested-by: Lennert Buytenhek buytenh@wantstofly.org
thanks, Lennert