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@xxxxxxxxx>
> >>> > 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@xxxxxxxxx>
> >>> > Signed-off-by: Dave Airlie <airlied@xxxxxxxxxx>
> >>> >
> >>> > ...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@xxxxxxxxxxxxxx>
thanks,
Lennert
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
