display goes off when AppleIntelFramebufferCapri is loaded

[rr7]

random sub-question, when searching for info, i found a few posts stating graphics mode should be 1920x1080x64 (as opposed to x32)

 

i wasnt aware such a thing exists, and it looks like it may only be mentioned on the tonymac forum, so is this just another case of more dismissable random clueless statements that end up on there or is this some bootloader setting thing?

[pcmantinker]

K, so the 1080 display is the internal, no other monitors hooked up and thats the correct resolution? If so, at least it's detecting it correctly. anything in console logs when booting, switching displays, unplugging, plugging in monitors, etc.?

How would I monitor these logs? I'm not too familiar with OS X logs. Also, I extracted my DSDT and compiled it, but I don't see an MEI device in the DSL DSDT extraction. I don't think that device exists on a laptop.

 

@rr7, I believe I tried 1920x1080x64 with no luck. Maybe if you apply a refresh rate as well it will help? I've seen some people say that 1920x1080x64@85 works (the 85Hz refresh rate is only for VESA 3.0 though).

[rr7]

How would I monitor these logs? I'm not too familiar with OS X logs. Also, I extracted my DSDT and compiled it, but I don't see an MEI device in the DSL DSDT extraction. I don't think that device exists on a laptop.

 

@rr7, I believe I tried 1920x1080x64 with no luck. Maybe if you apply a refresh rate as well it will help? I've seen some people say that 1920x1080x64@85 works (the 85Hz refresh rate is only for VESA 3.0 though).

 

i added the MEI device manually to override the device id,so that OSX didnt load the sandy bridge kext at the same time as the ivy bridge one. it wouldnt appear otherwise.

 

in the recent version i posted, i removed the entry and edited the kexts,mostly just for clarification that it doesnt matter which way round, same thing happens. which os the case.

 

personally i'd do everything like that in DSDT so i only have to do it once and not worry when updates are released.

 

i'll give the res thing a go, just to say i've done it, but i've tried various other onesw to no avail.

 

current gut feeling, is hack the port tables, at least just to debug it. i'll have a look at the kext in a hex editor, but i'm doubtful i can work it out simply by doing that.

[eep357]

Changing the port tables is what I had in mind as well, and have looked into a little bit. but not sure what the correct layout would need to be for your board. Also could you both upload a clean unedited/unpatched DSDT?

[rr7]

Changing the port tables is what I had in mind as well, and have looked into a little bit. but not sure what the correct layout would need to be for your board. Also could you both upload a clean unedited/unpatched DSDT?

 

what i was thinking initially, is use the id4 tables, which is a single output, and change the connector type to 00 40 00 00 (display port) and see what happens. working out what to change means i/we can experiment though....

 

i just happed to be booted up with a clean DSDT at the moment, here it is.....

rr7-unpatched.dsl.zip

[eep357]

Here's patched DSDT, of course I have no idea if patches I did will work, but also included just a ig-platform-id patch file where you would just change the letter/number that is red to match whatever platform id you want to try and apply with DSDT editor. will try to look into framebeffer some more later tonight

DSDTand patch.zip

[pcmantinker]

Here's my clean DSDT dump. Thanks much eep357.

pcmantinker-unpatched-dsdt.dsl.zip

[eep357]

Looked through the binary for CapriFB and found what I think are the connectors, all 3 of them being 4's for DP and not 8's for HDMI, so changed them all to 8's. By no means do I think I did this right, the point more so being to see if there is any noticeable change in behavior or IOreg to see if even in the right ball park.

AppleIntelFramebufferCapri.kext.zip

[rr7]

i'm assuming you want me to try id A for the edited kext?

 

i can confirm that with the patched DSDT, the same thing happens (i'd tried all the changes you made i think)

 

and that the connector types are @0 = 00 04 00 00, @1 = 00 04 00 00, @2 00 08 00 00 with the vanilla kext,

and there is no change with the patched kext. (i confirmed i'm using the patched one as i gave it a label colour so i could pick it out.)

 

oh, and thanks for the time you're putting into this!

[eep357]

Try using method indicated here http://olarila.com/forum/viewtopic.php?f=3&t=1583 the first post is Portugues but google translate does good enough. A download is included at the bottom of the firs post. Also see the 3rd post by Cassio, about also adding AAPL00 Dual Link properties which may make it a better option than DSDT and could be the ticket.

[rr7]

Tried that already too legacyAGPM is currently installed.

 

For completeness, I just retried the dual link, No change.

 

I still remain hopeful for editing the tables.

 

I did load the kext into TextEdit but could find any strings that gave me a clue :/

 

Lots of strings though, I wonder of it had a debug/logging option

[eep357]

Your removing patched DSDT when trying the injection right ?Should at least be able to see similar differences in IOreg to what your getting when trying different DSDT edits. Have you tried removing kexts for one of the GPU's? FYI, this is what I found in Capri using Hexfiend

02 05 00 00 00 04 00 00 07 00 00 00
03 04 00 00 00 04 00 00 07 00 00 00
04 06 00 00 00 04 00 00 07 00 00 00

changed to

02 05 00 00 00 08 00 00 07 00 00 00
03 04 00 00 00 08 00 00 07 00 00 00
04 06 00 00 00 08 00 00 07 00 00 00

so IDK

[capo_saric]

Hi, guys...

I happen to have the same cpu as pcmantinker

I've made my internal display work with the EFI String for device 01660004, which indicates ig-platform-id: 01660004, Stolen RAM for FB: 32MB, Pipes: 3, Ports: 1, FBMem: 1

I also set the GraphicsMode to 1920x1080x64

 

<key>device-properties</key>
<string>7f0000000100000001000000730000000200000002010c00d041030a000000000101060000027fff04002c0000004100410050004c002c00690067002d0070006c006100740066006f0072006d002d006900640000000800000004006601140000006800640061002d0067006600780000000d0000006f6e626f6172642d31</string>

 

 

Sadly, I haven't got any of my external ports to work. My laptop has HDMI, DVI and DisplayPort, and I really need to get any of them to work as soon as possible... I'll update any progress I have

[pcmantinker]

capo_saric, do you have 64MB VRAM on your Intel HD 4000 or is it 32MB VRAM? I believe mine is 64MB and is unfortunately unchangeable.

[capo_saric]

capo_saric, do you have 64MB VRAM on your Intel HD 4000 or is it 32MB VRAM? I believe mine is 64MB and is unfortunately unchangeable.

 

Without any GPU recognized, "About This Mac" showed 64Mb Shared Memory, but none of the 64MB strings worked... It is also unchangeable

 

I've tried every single string with x32 and x64 graphics mode and that one is the only that has worked with my internal screen

[pcmantinker]

I finally have QE\CI on my internal display! I'm using the MacBook Pro 9,1 SMBIOS, LegacyAGPM.kext, 1920x1080x64@85, and DSDT injection for 01660004. It should also be noted that I have removed AppleIntelSNBFramebuffer.kext as it is not needed with the Intel HD 4000 (probably could stop the kext from loading with DSDT later). Here's the DSDT patch for injecting the ig-platform-id:

into method label _DSM parent_adr 0x00020000 remove_entry;
into device name_adr 0x00020000 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
	Store (Package (0x02)\n
	 {\n
			"AAPL,ig-platform-id", \n
			Buffer (0x04) \n
			{ \n
			   0x04, 0x00, 0x66, 0x01 \n
			}, \n
		}, Local0)\n
	DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))\n
	Return (Local0)\n
}\n
end

Using DSDT Editor, you'll have to apply the above patch as well as the DTGP patch from the patches directory. Also, you should edit the 0x04 (not the Buffer) to match your ig-platform-id. I can bundle the patches in a zip file if anyone needs it.

 

I don't know if any of my external ports work for video, but I'm really happy that I finally have the internal display working with QE\CI. Thanks everyone for your help! I'll post back my findings on external displays over HDMI or VGA.

 

EDIT:It appears as though external screens over HDMI and VGA don't work with this ig-platform-id, but I'm not too worried about it currently. It would be great to have use of HDMI, but it's not a priority.

[capo_saric]

I finally have QE\CI on my internal display! I'm using the MacBook Pro 9,1 SMBIOS, LegacyAGPM.kext, 1920x1080x64@85, and DSDT injection for 01660004. It should also be noted that I have removed AppleIntelSNBFramebuffer.kext as it is not needed with the Intel HD 4000 (probably could stop the kext from loading with DSDT later). Here's the DSDT patch for injecting the ig-platform-id:

into method label _DSM parent_adr 0x00020000 remove_entry;
into device name_adr 0x00020000 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
	Store (Package (0x02)\n
	 {\n
			"AAPL,ig-platform-id", \n
			Buffer (0x04) \n
			{ \n
			   0x04, 0x00, 0x66, 0x01 \n
			}, \n
		}, Local0)\n
	DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))\n
	Return (Local0)\n
}\n
end

Using DSDT Editor, you'll have to apply the above patch as well as the DTGP patch from the patches directory. Also, you should edit the 0x04 (not the Buffer) to match your ig-platform-id. I can bundle the patches in a zip file if anyone needs it.

 

I don't know if any of my external ports work for video, but I'm really happy that I finally have the internal display working with QE\CI. Thanks everyone for your help! I'll post back my findings on external displays over HDMI or VGA.

 

EDIT:It appears as though external screens over HDMI and VGA don't work with this ig-platform-id, but I'm not too worried about it currently. It would be great to have use of HDMI, but it's not a priority.

 

Nice to read that!

I'll be waiting for your update on external displays to know if it is worth making all that dsdt + kexts stuff you had to do.

[eep357]

I finally have QE\CI on my internal display! I'm using the MacBook Pro 9,1 SMBIOS, LegacyAGPM.kext, 1920x1080x64@85, and DSDT injection for 01660004. It should also be noted that I have removed AppleIntelSNBFramebuffer.kext as it is not needed with the Intel HD 4000 (probably could stop the kext from loading with DSDT later). Here's the DSDT patch for injecting the ig-platform-id:

into method label _DSM parent_adr 0x00020000 remove_entry;
into device name_adr 0x00020000 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
	Store (Package (0x02)\n
	 {\n
			"AAPL,ig-platform-id", \n
			Buffer (0x04) \n
			{ \n
			   0x04, 0x00, 0x66, 0x01 \n
			}, \n
		}, Local0)\n
	DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))\n
	Return (Local0)\n
}\n
end

Using DSDT Editor, you'll have to apply the above patch as well as the DTGP patch from the patches directory. Also, you should edit the 0x04 (not the Buffer) to match your ig-platform-id. I can bundle the patches in a zip file if anyone needs it.

 

I don't know if any of my external ports work for video, but I'm really happy that I finally have the internal display working with QE\CI. Thanks everyone for your help! I'll post back my findings on external displays over HDMI or VGA.

 

EDIT:It appears as though external screens over HDMI and VGA don't work with this ig-platform-id, but I'm not too worried about it currently. It would be great to have use of HDMI, but it's not a priority.

Great progress! ]That's the same patch I posted earlier and is also available in the Olarila thread I linked too, I'm glad you mentioned the AGPM kext as it was in that same DL and I completely forgot about it!I think the key is getting all the other pieces right first, then test different platform Id's. MacBookPro 9,1 smbios (even on All-In-One as mobo is similar to laptop), the legacyAGPM.kext, DTGP patch which is also in the Olarila post, delete Sandy brindge FB....Then can test some different ID's and even try the AAPL00 Dual Link. I'd love to test this along with various DSDT edit's all day, but someone gotta send me an Ivy Bridge first, so kinda hard when I can't even see if the littlest edit has an effect for my self first. Keep up the good worx!

[Akai92]

I finally have QE\CI on my internal display! I'm using the MacBook Pro 9,1 SMBIOS, LegacyAGPM.kext, 1920x1080x64@85, and DSDT injection for 01660004. It should also be noted that I have removed AppleIntelSNBFramebuffer.kext as it is not needed with the Intel HD 4000 (probably could stop the kext from loading with DSDT later). Here's the DSDT patch for injecting the ig-platform-id:

into method label _DSM parent_adr 0x00020000 remove_entry;
into device name_adr 0x00020000 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
	Store (Package (0x02)\n
	 {\n
			"AAPL,ig-platform-id", \n
			Buffer (0x04) \n
			{ \n
			   0x04, 0x00, 0x66, 0x01 \n
			}, \n
		}, Local0)\n
	DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))\n
	Return (Local0)\n
}\n
end

Using DSDT Editor, you'll have to apply the above patch as well as the DTGP patch from the patches directory. Also, you should edit the 0x04 (not the Buffer) to match your ig-platform-id. I can bundle the patches in a zip file if anyone needs it.

 

I don't know if any of my external ports work for video, but I'm really happy that I finally have the internal display working with QE\CI. Thanks everyone for your help! I'll post back my findings on external displays over HDMI or VGA.

 

EDIT:It appears as though external screens over HDMI and VGA don't work with this ig-platform-id, but I'm not too worried about it currently. It would be great to have use of HDMI, but it's not a priority.

 

I am so happy to see this thread, I am having troubles with probook 4540s and Hd4000. My device-id is 0166 and revision-id 0009. With some ids I have only-text screen and freeze. With id some I get blank screen and not freeze. With only id 3, I get resolution change-able screen but no ci qe. System profiler report that I get 0mb RAM. Anyway can anyone tell me how to make a dsdt than can be compiled? I am very new to dsdt.

 

BTW I found some hardware dumps of mbp 9,1 and 10,1 here: http://tdev.me/2010/...hardware-dumps/

 

BTW do you have graphicsenabler?

 

EDIT: I just use smbios mbp 9,1 and now I cannot get into Mac anymore. Weird that the line Unknown AGPM disappears too.

[rr7]

Your removing patched DSDT when trying the injection right ?Should at least be able to see similar differences in IOreg to what your getting when trying different DSDT edits. Have you tried removing kexts for one of the GPU's? FYI, this is what I found in Capri using Hexfiend

02 05 00 00 00 04 00 00 07 00 00 00
03 04 00 00 00 04 00 00 07 00 00 00
04 06 00 00 00 04 00 00 07 00 00 00

changed to

02 05 00 00 00 08 00 00 07 00 00 00
03 04 00 00 00 08 00 00 07 00 00 00
04 06 00 00 00 08 00 00 07 00 00 00

so IDK

 

i'm probably confusing the issue here. let me clarify.

 

when i say inject, i mean i've added the platform id, via DSDT, like you did in your patch. i've been doing the same thing, which all of the ID types. at the time of posting, none of them work for me. chimera graphics enabler just does id9. EFI strings do whatever someome has configired it to do. the end result is always the same. for me, i'm most at home doing the injection via DSDT so i know exactly what i'm putting in. maybe 'inject' means something more specificor in a specific way in the scene?

 

what i think is happening, is that there is simply not an platform id yet that matches my All-in-one. hence the hacking adaptor tables idea.

 

i will post tonight a list of all the adaptor types that get loaded with each platform id. i think in the case of most people, pcmantinker included, is that its simply not the right id being injected. id4 that he's now using has a single output, and its LVDS, i.e his internal display. it has no other output enabled. the one he was using had outputs enabled, but no ldvs, so no internal display. and so forth.

 

my mission, is to be able to edit the kext to assign whatever connectors to a given id. i'm thinking if i cna make a single output which is type 04 (dispplayport) thay my all in one will behave. if i can prove this, it also means we can create a documented method to help people create there own suitable adaptor tables.

 

for the record, i dont beleive that the HD4000 cares at all about IGPU/GFX0 or smbios types in order to make the display work, (instead it blindly assumes adaptor types from a pre-programmed list in the kext). although i'm sure it makes a difference for power management and fine tuning. but i dont think (at the moment) thats a point of fail. its documented that the HD3000 does care about all those things though.

 

as for the edited kext, if you've changed 3 instances of 04 to 08, then this will only afffect 2-3 id types. i dont remember right now which, but id5 uses that config and it hasnt changed with the edited kext. id A uses 04/04/08 connector types.

[rr7]

Your removing patched DSDT when trying the injection right ?Should at least be able to see similar differences in IOreg to what your getting when trying different DSDT edits. Have you tried removing kexts for one of the GPU's? FYI, this is what I found in Capri using Hexfiend

02 05 00 00 00 04 00 00 07 00 00 00
03 04 00 00 00 04 00 00 07 00 00 00
04 06 00 00 00 04 00 00 07 00 00 00

changed to

02 05 00 00 00 08 00 00 07 00 00 00
03 04 00 00 00 08 00 00 07 00 00 00
04 06 00 00 00 08 00 00 07 00 00 00

so IDK

 

Okay, I've made some progress on this!

 

The edit you made affected id0. By comparing your file and the original, and looking at the surround hex, I'm now able to change the connector types on each platform.

 

I chose id4 for now as it had a single output.

I changed the connector type from 02 00 00 00 LVDS to 00 04 00 00 Displayport

 

But my display still wasn't detected.

 

I then looked at all the Id and connector types where my display was detected previously, it seems the 04 06 hex before the connector type is where it gets detected. I change that line to 04 06 and the screen now gets detected and goes blank as before.

 

So at least now I'm In some kind of control

 

It's late now nearly 2am so I'm going to out it down,

 

I need to learn what these other values actually represent.

[eep357]

Perfect! Without my own to test with, getting the ball rolling was the most I could have expected to be able to do, and it sounds like your rolling now! Try it as HDMI or even DVI, since the displays built in and not a laptop, it could be a bit funky. Also would like to know what those 7's are for?

[eep357]

I wanted to share what I found so far in the Capri, and just get some of it written down for my own notes too, so I'm kinda editing this post as I go with any observations. 12 total ig-platform-id's but 2 of them have no pipes, ports or FBmem, haven't even looked at them all yet, but those 2 that can be seen here are 01620006 and 01620007, maybe they are for future versions that don't exist yet. After that the are all the familiar ones. The 10 07 00 00 10 07 00 00 that is present in each instance has a 20 before it on all but the two blank ones 01620006 and 01620007 which have an 18 there instead along with 01660004, so looks like 18 is desktop and 20 is laptop?. More decoding to be done.

 

rr7--01660004 only has the one connector 05 03 so I don't think changing that connector to 04 06 is the way to go, but instead edit and use one of the id's that already has that connector? id's 0a and 0b both have 04 06 already, but with connector type 08, maybe try changing one of these to 04 and using them? I'm sure all the other stuff factors into that somehow, just not sure how quite yet.

 

After a little more looking, 010000000 2000000 3000000 appears to be internal lcd display at port 1, not present in every id, then right after this will be 02050000 for port 2, except for on id#2 because it only has 1 port, so has zeros here instead. or like with ID#4 which also only has one port which is an internal lcd not located at port #1, but it's located at port #5 so it's internal lcd is 050300000 2000000 30020000. I've seen some where internal LCD is either at port# 01 or 05, but it is always the first port listed while the rest appear in numerical order. Since the most ports any id's have is 4, it may have either port 1 or port 5, but not both and these will always be internal lcd. So for laptop users, this is the key to get internal display working and should not be edited for external displays. id4 is interesting as it's the only one with ports (1 total) that has an 18 as noted above, but then also it's only connector which is at port 5, is an lcd. so a bit of an odd ball, I don't see how this would be for desktops and wonder if the 18 may be used to disable the id and 20 makes it usable by the OS?

 

I guess that's about all I can do until I win a free Ivy Bridge

 

note: The above is only from observation only and no testing, so take nothing I say as proven fact, but merely conjecture and thinking out loud in hopes that it may possibly prove to be useful. More heads are better than one!

[eep357]

ig-platform-id: 01660000, Stolen RAM for FB: 96MB, Pipes: 3, Ports: 4, FBMem: 3 - internal display at port #1
ig-platform-id: 01660001, Stolen RAM for FB: 96MB, Pipes: 3, Ports: 4, FBMem: 3 - internal display at port #1
ig-platform-id: 01660002, Stolen RAM for FB: 64MB, Pipes: 3, Ports: 1, FBMem: 1 - internal display at port #1
ig-platform-id: 01660003, Stolen RAM for FB: 64MB, Pipes: 2, Ports: 2, FBMem: 2 - internal display at port #5
ig-platform-id: 01660004, Stolen RAM for FB: 32MB, Pipes: 3, Ports: 1, FBMem: 1 - internal display at port #5
ig-platform-id: 01660008, Stolen RAM for FB: 64MB, Pipes: 3, Ports: 3, FBMem: 3 - internal display at port #1
ig-platform-id: 01660009, Stolen RAM for FB: 64MB, Pipes: 3, Ports: 3, FBMem: 3 - internal display at port #1
ig-platform-id: 0166000A, Stolen RAM for FB: 32MB, Pipes: 2, Ports: 3, FBMem: 2 - no internal LCD
ig-platform-id: 0166000B, Stolen RAM for FB: 32MB, Pipes: 2, Ports: 3, FBMem: 2 - no internal LCD
ig-platform-id: 01620005, Stolen RAM for FB: 32MB, Pipes: 2, Ports: 3, FBMem: 2 - no internal LCD

So based on what I'm seeing, which I should again mention may be totally wrong, I added the internal LCD info to the list above.

[rr7]

it looks likek the intel frame buffer isnt bothered about the adaptor type,i can change it to whatever and it still gets detected when i use 04 06 in the bytes before it.

 

here is a copy of my notes, in case anyone finds it useful. i still dontt yet know what these numbers mean. but im now starting to think it may justt be a screen mode issue again for me :\

 

AAPL,ig-platform-id: 01660000, Stolen RAM for FB: 96MB, Pipes: 3, Ports: 4, FBMem: 3
@0, 01 00 00 00 02 00 00 00 03 00 00 00 // (LVDS)
@1, 02 05 00 00 00 04 00 00 07 00 00 00 // (DisplayPort)
@2, 03 04 00 00 00 04 00 00 07 00 00 00 // (DisplayPort)
@3, 04 06 00 00 00 04 00 00 07 00 00 00 // (DisplayPort)- DETECTED 0x0

AAPL,ig-platform-id: 01660001, Stolen RAM for FB: 96MB, Pipes: 3, Ports: 4, FBMem: 3
@0, 01 00 00 00 02 00 00 00 30 00 00 00 // (LVDS)
@1, 02 05 00 00 00 08 00 00 06 00 00 00 // (HDMI)
@2, 03 04 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)
@3, 04 06 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)- DETECTED 0x0
port-number 0x7

AAPL,ig-platform-id: 01660002, Stolen RAM for FB: 64MB, Pipes: 3, Ports: 1, FBMem: 1
@0, 01 00 00 00 00 02 00 00  30 00 00 00 // (LVDS)
port number 0x0

AAPL,ig-platform-id: 01660003, Stolen RAM for FB: 64MB, Pipes: 2, Ports: 4, FBMem: 2
@0, 05 03 00 00 02 00 00 00 30 00 00 00 // (LVDS)
@1, 02 05 00 00 00 04 00 00 07 04 00 00 // (DisplayPort)
@2, 03 04 00 00 00 04 00 00 81 00 00 00 // (DisplayPort)
@3, 04 06 00 00 00 04 00 00 81 00 00 00 // (DisplayPort) - DETECTED 0x0 desktop


AAPL,ig-platform-id: 01660004, Stolen RAM for FB: 32MB, Pipes: 3, Ports: 1, FBMem: 1
@0, 05 03 00 00 02 00 00 00 30 02 00 00 // (LVDS)

AAPL,ig-platform-id: 01620005, Stolen RAM for FB: 32MB, Pipes: 2, Ports: 3, FBMem: 2 512mb vram
@0, 02 05 00 00 00 04 00 00 11 00 00 00 // (DisplayPort)
@1, 03 04 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)
@2, 04 06 00 00 00 04 00 00 07 01 00 00 // (DisplayPort) - DETECTED

AAPL,ig-platform-id: 01620006, Stolen RAM for FB: 0MB, Pipes: 0, Ports: 0, FBMem: 0

AAPL,ig-platform-id: 01620007, Stolen RAM for FB: 0MB, Pipes: 0, Ports: 0, FBMem: 0

AAPL,ig-platform-id: 01660008, Stolen RAM for FB: 64MB, Pipes: 3, Ports: 3, FBMem: 3
@0, 01 00 00 00 02 00 00 00 30 00 00 00 // (LVDS)
@1, 02 05 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)
@2, 03 04 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)


AAPL,ig-platform-id: 01660009, Stolen RAM for FB: 64MB, Pipes: 3, Ports: 3, FBMem: 3 - 0mb VRAM
@0, 01 00 00 00 02 00 00 00 30 00 00 00 // (LVDS)
@1, 02 05 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)
@2, 03 04 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)

AAPL,ig-platform-id: 0166000A, Stolen RAM for FB: 32MB, Pipes: 2, Ports: 3, FBMem: 2
@0, 02 05 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)
@1, 03 04 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)
@2, 04 06 00 00 00 08 00 00 06 00 00 00 // (HDMI) - DETECTED

AAPL,ig-platform-id: 0166000B, Stolen RAM for FB: 32MB, Pipes: 2, Ports: 3, FBMem: 2
@0, 02 05 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)
@1, 03 04 00 00 00 04 00 00 07 01 00 00 // (DisplayPort)
@2, 04 06 00 00 00 08 00 00 06 00 00 00 // (HDMI) - DETECTED