[Intel-gfx] Fwd: Re: Macbook Pro Retina display problems

Thu Aug 2 05:37:05 CEST 2012

Dave, Greg,

OK, the problem was indeed a connection issue. By using gfxcardstatus
within osx, I was able to force the HD4000 to connect to the display.
The xorg log now reports:

[     8.226] (--) PCI:*(0:0:2:0) 8086:0166:106b:00f7 rev 9, Mem @ 0xc1400000/4194304, 0xb0000000/268435456, I/O @ 0x00003000/64
[     8.226] (--) PCI: (0:1:0:0) 10de:0fd5:106b:00f2 rev 161, Mem @ 0xc0000000/16777216, 0x90000000/268435456, 0xa0000000/33554432, I/O @ 0x00002000/128, BIOS @ 0x????????/524288

instead of greg's (or mine, prior to forcing with gfxcardstatus):

[   224.406] (--) PCI: (0:0:2:0) 8086:0166:106b:00f7 rev 9, Mem @ 0xc1400000/4194304, 0xb0000000/268435456, I/O @ 0x00003000/64
[   224.406] (--) PCI:*(0:1:0:0) 10de:0fd5:106b:00f2 rev 161, Mem @ 0xc0000000/16777216, 0x90000000/268435456, 0xa0000000/33554432, I/O @ 0x00002000/128, BIOS @ 0x????????/524288

I assume the star indicates to which pci the display is connected.

The laptop now boots ok (with kms) and X starts without any error.
I can change modes and have checked that it effectively changes the
resolution. It is accelerated. Everything looks ok except that the
display is quite corrupted (at any resolution).

Some elements:

* The display is the new retina display, 2880x1800; quite a bit of
pixels to push (might be related to the problem, see below). I'm using
the 3.5.0 kernel with everything stock.

* I thought initially that i915 was not getting the correct EDID from
the display and tried forcing the EDID with drm_kms_helper (using
stock 1920x1080 and the edid.bin I extracted when using the laptop
with the discrete nvidia card + nvidia blob), but it didn't help at
all; same display corruption.

* I have a dump of dmesg (using drmd.debug=6) and xorg log at
http://maumae.net/retina/intel_corrupted_drm_debug/dmesg_intel_drm_debug
and
http://maumae.net/retina/intel_corrupted_drm_debug/xorg_log_intel_corrupted_drm_debug
The xorg log doesn't report any error. The modeline used looks
allright to me
[    9.856125] [drm:drm_mode_debug_printmodeline], Modeline 17:"2880x1800" 60 337750 2880 2928 2960 3040 1800 1803 1809 1852 0x48 0x9

* Ryan Bourgeois is working on a similar corruption issue for the
nouveau driver. He claims that this might actually be related to a
link bandwidth problem:
"This line right here out of your dmesg:
    DP link bw 0a lane count 4 clock 270000 bpp 24
That's part of the DP link training and it's configuring it the same
way as nouveau does, four lanes at 2.7Gbps. So if it is an issue with
the Retina exceeding that bandwidth it's consistent across both devices.
The link is configured based on the mode and panel capabilities, so
that makes sense.
I still need to try a couple of things to validate whether or not this
is the situation."
(last quotes from https://bbs.archlinux.org/viewtopic.php?id=144255&p=2).

* I can't show you what the corruption looks like, as when I take
screenshots (with xfce4-screenshooter), they do NOT show the
corruption (there are some in
http://maumae.net/retina/intel_corrupted_drm_debug/ ). I guess this
means the image is ok in video memory, the corruption occurs when it's
pushed to the display, kind of pointing to the link bandwidth again.

Thanks for any help,

Francois Rigaut

> On Tue, Jul 31, 2012 at 03:00:52PM +1000, Dave Airlie wrote:
> > On Tue, Jul 31, 2012 at 1:41 PM, Greg KH
<gre... at linuxfoundation.org> wrote:
> > > On Tue, Jul 31, 2012 at 12:06:28PM +1000, Dave Airlie wrote:
> > >> On Tue, Jul 31, 2012 at 8:33 AM, Greg KH
<gre... at linuxfoundation.org>
> > >> wrote:
> > >> > Hi all,
> > >> >
> > >> > I'm trying to the the $Subject laptop up and running using the built-in
> > >> > Intel graphics chip:
> > >> >
> > >> > 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
> > >> > processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
> > >> >         Subsystem: Apple Inc. Device 00f7
> > >> >         Flags: bus master, fast devsel, latency 0, IRQ 53
> > >> >         Memory at c1400000 (64-bit, non-prefetchable) [size=4M]
> > >> >         Memory at b0000000 (64-bit, prefetchable) [size=256M]
> > >> >         I/O ports at 3000 [size=64]
> > >> >         Expansion ROM at <unassigned> [disabled]
> > >> >         Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> > >> >         Capabilities: [d0] Power Management version 2
> > >> >         Capabilities: [a4] PCI Advanced Features
> > >> >         Kernel driver in use: i915
> > >> >
> > >> > And it seems that the xorg Intel driver just doesn't recognize it at
> > >> > all.
> > >> >
> > >> > Below is my Xorg.0.log file.  I'm using a 3.5.0 kernel (with a few minor
> > >> > hardware patches for other bits of this laptop that don't work with
> > >> > 3.5.0, but no changes to the graphics drivers.)
> > >> >
> > >> > Any ideas or patches I can try out?
> > >>
> > >> try writing an xorg.conf with a BusID in it and see if it works, most
> > >> likely the primary boot_vga detection is busted.
> > >
> > > Ah, I did that previously, it gave me a black screen and locked up.
> > > I'll get the log from that tomorrow and send it here.
> > >
> > > Note, we are switching from EFI framebuffer mode, so could that be an
> > > issue as well?
> > >
> > > And, just to make it fun, this laptop also has an nvidia chip in it, but
> > > someone else is working on getting the nouveau driver working on it, I
> > > was trying to stay away from that mess :)
> >
> > Yeah the problem is most likely that the nvidia is connected to the screen :-)
>
> I think so, the log below shows that the Intel driver can't find any
> displays, if I'm reading it right.
>
> > I think mjg59 has been working on some stuff in this area lately as well.
>
> I see his PCI patches on linux-pci for something that might look helpful
> here, although it's in relation to the radeon driver, so maybe not.
> I'll give it a try though, and I've asked him what he tested the patches
> on.
>
> Anything else I can try?
>
> greg k-h
>