AppleIntelFramebufferAzul.kext (part II)

A month or so ago I blogged about the framebuffer data in AppleIntelFramebufferAzul.kext and today I had another look at it. Let us start with the framebuffer data that I used before, as an example, to show you what we have learned so far. The green bytes are known, but the red bytes are not:

00 00 16 0A 00 03 03 03 00 00 00 04 00 00 00 01
00 00 F0 00 00 00 00 40 D9 0A 00 00 D9 0A 00 00
00 00 00 00 00 00 00 00 00 00 10 00 02 00 00 00
30 00 00 00 01 05 12 00 04 00 00 00 04 00 00 00
02 04 12 00 00 08 00 00 82 00 00 00 FF 00 01 00
01 00 00 00 40 00 00 00 04 00 00 00 00 00 07 00
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

That is not all of them, because I think to have figured out the purpose of a few more bytes. Ok. Here we have the same data, but this time it shows you the new findings:

00 00 16 0A 00 03 03 03 00 00 00 04 00 00 00 01
00 00 F0 00 00 00 00 40 D9 0A 00 00 D9 0A 00 00
00 00 00 00 00 00 00 00 00 00 10 00 02 00 00 00
30 00 00 00 01 05 12 00 04 00 00 00 04 00 00 00
02 04 12 00 00 08 00 00 82 00 00 00 FF 00 01 00
01 00 00 00 40 00 00 00 04 00 00 00 00 00 07 00
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

Let’s start with the green bytes. This represents the delay (4, 48 and 130) in milliseconds after which the framebuffer should be activated. Used to prioritise a certain framebuffer over another. That is when the orange bytes are the same, like in our example data where the framebuffer with fFrameBufferIndex 01 will be disabled – taken over by the one with 02 because it has a longer delay (higher preference). Meaning that when this framebuffer is used – by injecting AAPL,ig-platform-id: 0x0a160000 – that the DVI connector is switched off and the HDMI connector is switched on. Swapping the values will revert it and changing one of the orange values (12) to 14 will add support for a third display.

Oh and by the way. The byte next to the framebuffer index is NOT the port-number. The fact the port-number 0 and 5 are the same as the connection numbers doesn’t mean a thing. Just look at the next value (04) which should have been 06 when this was in fact representing the port-numbers. You can check the MacBook Air ioreg data and see that I am right (04 is either 06 or 07).

Let’s first have a look at a picture of the Processor Display Architecture. Here it is:
Processor Display Architecture
Visualising the number of pipes (03) framebuffers (03) and DDI ports (03) – this is what I found in the Intel datasheet:

The DDI (Digital Display Interface) ports B,C and D on the processor can be configured to support DP/eDP/HDMI and DVI. For desktop designs, DDI port D can be configured as eDPx4 (4 lanes) in addition to dedicated x2 (2 lanes) port for Intel FDI (Flexible Display Interface) for (analog) VGA.

The Intel Flexible Display Interface (Intel FDI) passes display data from the processor (source) to the PCH (sink) for display through a display interface on the PCH (Platform Controller Hub) and supports up to 2 lanes at 2.7 GT/s fixed frequency (can be configured to 1 or 2 lanes depending on the bandwidth requirements).”

And since VGA is analog, there is no support for HDCP either. Which is why you may see this warning message in: /var/log/system.log and after entering: sudo dmesg

iTunes/Apple Store Content Access Problem. Content playback may be disabled on this computer. You can continue to use the machine, but you should contact an Apple support representative. ErrorCode: 8877652

This warning has long been a mystery (see Google search results) but now we know what it means. Next. A motherboard with three display connectors might give you something like this (debug data):

IG:: start:3260 FB Index 0 is Pipe 65535 type 3 fBootPipe 255
IG:: start:3260 FB Index 1 is Pipe 65535 type 2 fBootPipe 255
IG:: start:3260 FB Index 2 is Pipe 65535 type 1 fBootPipe 255

IG:: MapFBToPort:1721 (FB0: 0xffffff819f133000)
IG:: MapFBToPort:1721 (FB1: 0xffffff819f15c000)
IG:: MapFBToPort:1721 (FB2: 0xffffff819f137000)

IG:: MapFBToPort:1756 Map fb0 -> Port A (fPortType=3)
IG:: MapFBToPort:1756 Map fb1 -> Port B (fPortType=2)
IG:: MapFBToPort:1756 Map fb2 -> Port C (fPortType=1)

IG:: start:3121 [NFB] fPortToFBMap[0] 0xffffff819f133000
IG:: start:3121 [NFB] fPortToFBMap[1] 0xffffff819f15c000
IG:: start:3121 [NFB] fPortToFBMap[2] 0xffffff819f137000

IG:: start:3299 Starting FB 0
IG:: start:3299 Starting FB 1
IG:: start:3299 Starting FB 2

I also found the following errors, which don’t seem to have a negative impact:

IG:: hwGetMemoryLayoutEFI:5405 (fb0: 0xffffff819f133000)
IG:: hwGetMemoryLayoutEFI:5414 [NFB] This FB does not have FBMemoryIndex
IG:: hwGetMemoryLayoutEFI:5430 UpperFence 0 LowerFence 0 baseAddress 0 stride 0 valid 0
IG:: hwGetMemoryLayoutEFI:5433 return 0

IG:: hwGetMemoryLayoutEFI:5405 (fb1: 0xffffff819f15c000)
IG:: hwGetMemoryLayoutEFI:5414 [NFB] This FB does not have FBMemoryIndex
IG:: hwGetMemoryLayoutEFI:5430 UpperFence 0 LowerFence 0 baseAddress 0 stride 0 valid 0
IG:: hwGetMemoryLayoutEFI:5433 return 0

IG:: hwGetMemoryLayoutEFI:5405 (fb2: 0xffffff819f137000)
IG:: hwGetMemoryLayoutEFI:5414 [NFB] This FB does not have FBMemoryIndex
IG:: hwGetMemoryLayoutEFI:5430 UpperFence 0 LowerFence 0 baseAddress 0 stride 0 valid 0
IG:: hwGetMemoryLayoutEFI:5433 return 0

And with a HDMI monitor/TV plugged-in I also see this:

IG:: hwGetBootPanelFitter:1825 fb2 using Panel fitter 1

Port A (eDP) gives me this:

IG:: hwSetPanelPowerConfig:5199 using the default EDP panel timings

I also looked at the debug text strings in the binary and found a couple of interesting ones:

IG:: %s:%d Found boot pipe – fb%d using Port A (BootPipe=%u)\n
IG:: %s:%d Found boot pipe – fb%d using Port B (BootPipe=%u)\n
IG:: %s:%d Found boot pipe – fb%d using Port C (BootPipe=%u)\n
IG:: %s:%d Found boot pipe – fb%d using Port D (BootPipe=%u)\n

So Apple does seem to support four ports, but where the Intel datasheet mentioned Port D for eDP(x4) and VGA support, Apple is using Port A for eDP (x2) instead:

IG:: %s:%d The final Pipe is not A\n
IG:: %s:%d Pipe A is not eDP\n
IG:: %s:%d return (Pipe A is already taken)\n

I have no idea why so this is something we have to figure out.

Edit: Ok. That is because Port D can be configured for x4 mode (4 lanes) but Port A cannot, and Apple isn’t using 4 lanes (yet) so there is no need for using Port D for eDP (x4).

Note: LVDS is to be phased out/replaced by eDP in 2013.

Now have a look at the framebuffer data for the new 2013 Macmini:

03 00 22 0D 00 03 03 03 00 00 00 02 00 00 00 01
00 00 00 00 00 00 00 40 99 14 00 00 99 14 00 00
00 00 00 00 00 00 00 00 01 05 12 00 00 04 00 00
87 00 00 00 02 04 14 00 00 04 00 00 87 00 00 00
03 06 10 00 00 04 00 00 11 00 00 00 FF 00 01 00
01 00 00 00 40 00 00 00 02 00 00 00 01 01 00 00
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

It supports up to three active monitors (10, 12 and 14). The MacBook Air “only” supports 2. Also note the bytes in blue, representing the fFrameBufferIndex. Here starting at 1 instead of 0 (without eDP support) and the result is that the debug data looks different. Not to mention that fBootPipe will be 1 or 2 due to the greater delay (0x87/135ms) than the one with framebuffer index 3.

Well folks. This has to be it for today. Now it is time for a nice expresso made with a new Solis Barista (wedding gift) and then I will bolt-on a new set of (Spanish) number plates on my Range Rover. Yeah. It has taken me far too long to give Sam’s passing a place… and since my Ranger was a gift from Sam, we should start using it and have fun with it.

Later!

15 thoughts on “AppleIntelFramebufferAzul.kext (part II)

  1. Hi, this is great stuff, I’ve been trying to understand why the AppleIntelFrameBufferCapri.kext fails to allocate the correct displaypipe on my AIO computer, despite correctly detecting the display, which has a eDP and VGA layout. a great deal of what you are discovering about the Azul framebuffer looks like it may apply to the Capri one too. I also tried to see if I could force the Azul framebuffer in use, but I wasn’t able to get the display detected. none of the platform ID in use for it seem to have the ’04 06′ framebuffer configured. if you get a chance please take a read of my page that describes the issue, ( http://rr7blog.wordpress.com/2013/01/13/blank-display-when-hd-4000-loads/ ) i’d appreciate any thoughts you might have.

  2. also, where are these debug lines coming from? I’ve also found them in the capri binary, but I’ve never seen them output. is it just a boot flag to display them or is there more to it than that?

      • i can see the logs with this option, but it doesn’t seem to get stored anywhere that I can see to view it. I check the console, but none of the IG:: entries are there. i’m guessing this just logs to the screen and that’s it? is there any way to capture this, it scrolls past too fast and then the screen is blank anyway so I cant review it.

  3. ah, okay, that stings a bit, there is no serial ports. when you say capture screen output, if you mean the actual visible screen display, I’m not sure that’s going to work for graphics drivers. I need the output of the actual machine its on. I read somewhere about setting up a remote logging computer. maybe that’s the type of capture you mean. I have a couple of spare computers here so that should be doable!

    what I want to achieve is:

    1) document the AppleIntelFrameBufferCapri.kext just as you have done here, some of the stuff you’ve discovered looks applicable, but I think a couple of other parts are more unexplained.

    2) work out why my displaypipe is activated the wrong way around. the manufactured of my motherboard confirms that they only use Port D, and that it has 1 VGA and one eDP output enabled in hardware. i’m guessing that the FDI (VGA) uses ‘port A’ and the eDP port D, and that the apple driver is outputting the eDP detected display over Port A instead. i’m guessing I cant influence that behaviour in any way, but it may mean we can broadly say that any AIO with a VGA output simply cannot work with the internal display.

    meanwhile, i’ll grab my digital camera…..

  4. Great stuff.

    It was very helpful for my research to fix the problem of “AppleIntelFramebufferCapri.kext” when using it with an ultra big external monitor (3440×1440). Should also work for “AppleIntelFramebufferAzul.kext”

    It looks like the framebuffer size (for each buffer) is always set to 16MB which is a little bit to small for this huge screen. Thanks to your information I was able to increase the framebuffer size and everything is working fine 🙂

    Edit: Forgot to mention the posting about the fix:

    https://discussions.apple.com/message/25844313#

  5. Pingback: Yosemite DP6 with HD4600 | Pike's Universum

  6. I’m a little confused here : is there a way to bypass the FDI and get HDCP support by editing the frame buffer ?
    Thanks a lot for your work on this btw !

      • Thanks for your very quick answer !
        I’ve got an Intel NUC i5 with IntelHD5000 “0x0a260009” which works with “0x0a26000a” framebuffers (the NUC has 1 mini HDMI and 1 Mini DP port, but no VGA)
        I’m using (mini) HDMI and I don’t have HDCP support (I’ve got the “iTunes/Apple Store … ErrorCode: 8877652”), and “DVD player” tells me “HD Content not supported” in help/info.

        So I’m under the impression that my video on HDMI comes from the FDI and therefore loose HDCP … Is that even possible ? … If so can we prevent it ?

      • From Wikipedia (mini HDMI type c):

        All positive signals of the differential pairs are swapped with their corresponding shield, the DDC/CEC Ground is assigned to pin 13 instead of pin 17, the CEC is assigned to pin 14 instead of pin 13, and the reserved pin is 17 instead of pin 14

        Maybe the drivers fail to detect the monitor. I guess that it works with Windows and Linux?

  7. Pingback: OS X 10.11.4 wants IMEI, not HECI – Pike's Universum

  8. Pingback: AppleIntelSKLGraphicsFramebuffer.kext – Pike's Universum

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s