Re: radeon + DVI->mDP converter + mDP display blank screen issue since 3.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux