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:

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!