89 replies to this topic

[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
 AppleIntelFramebufferCapri.jpg   188.94KB   248 downloads  AppleIntelFramebufferCapri-2.jpg   268.66KB   233 downloads

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

[eep357]

That's what I'm talking about! I don't even have one, but like seeing some development come together! Looks good, I'm sure it will be useful to some one for something, someday Oh, and what I've been referring to as port 1, 2, 3 etc is partially for lack of a better term, they don't necessarily match what will be seen in ioreg where 04 is listed as port 7, 03 as port 6, looks like internal LCD shows as port 0 in ioreg wether it's 01 or 05.

[rr7]

thanks for all the helpand time you put in, its been awesome!

as for the ports, yes, it seems they are referred to in IOREG as 0,5,6,7 respectivly. i cant work out the significane of the 05 03 or 01 00 difference for LVDS

my display gets detected on any config where 04 06 (port 7) is enabled. and i can hack a different id with that port and it also then gets detected.
the driver actually doesnt seem to care much about what the connector-type is set to,i can change it to any of them and it makes no difference, as long as the port number is right,it picks it up (as display port)

and i think thats the answer to pretty much everyones problem, if you're displays are blank, then you need to match/try the port numbers.

annoyingly, my computer will throw a black screen when a platform-id is picked up, wether or not detects a display. the backlight also goes off. i now dont think port type/display detection is my problem, bit of a shame really!

perhaps the fact that i get that HD4000 kext failed to load due to IOGraphicsFamily kext not found error,cannot alloc Gen7Accel type thing is a clue.

for anyone interested, my internal display is eDP (embedded displayport), maybe thats a problem,but then surely eDP is whats ised on the newest retina macbook pro.

so i'm probably going to have to give up on this, i'm clean out of ideas:(

[eep357]

The first IOreg you ever uploaded where it looks like you were using id-5, was the only one where it had the Gen7 accelerator loaded. Also in the Capri binary, right after the connector section is a reference to the SB frame buffer, not sure if it needs to be loaded too, or what? in the 04 06, one of the two should be a sense ID or hotplugID, try changing to 04 05 or 04 02 for starters and see if any change?

[Akai92]

With id3-efi string I get resolution changer internal display (probook 4540s). Osx seems to recognize my monitor refresh rate (40hz and 60hz) but there's no ci qe.

Can you guys explain me more about injecting via dsdt. I use DSDT Fixer to fix errors, then patch with DSDT Editor, but it seems I cannot get the same result, atleast with id3-efi string.

Using smbios mbp 9,2 and legacyagpm.kext.

//EDIT: With "Graphics Mode"=1366x768x64@60Hz It said 0MB RAM. With no graphics mode specified it said 512MB but still no CI QE. With no graphic mode specified it still said 0MB. But if I push computer to sleep, but I still have not patched sleep so I had to hard restart my computer. After restart, it show 512MB RAM but no CI QE.Graphics still have glitches. .

Attached Files

•  DSDT-DTGP-fixed.dsl.zip   81.75KB   19 downloads
•  dsdt-id3.dsl.zip   81.74KB   7 downloads

[eep357]

The DSDT patch can be applied using DSDT editor. Use it to open DSDT, then open patch and apply, compile, save. The orig patch txt is available at Olarila.com in link I posted earlier in thread. It also includes a couple other files you may want, and can get DSDT editor app there too if needed. Since the patch is just a text you can easily change which ID it will patch into your DSDT before you apply it. You'll know what I mean as soon as you look at it. Changes in vram and stuff after sleep, could be cmos reset since no sleep fixes were applied yet, patched AppleRTC.kext for starters.

[Akai92]

The DSDT patch can be applied using DSDT editor. Use it to open DSDT, then open patch and apply, compile, save. The orig patch txt is available at Olarila.com in link I posted earlier in thread. It also includes a couple other files you may want, and can get DSDT editor app there too if needed. Since the patch is just a text you can easily change which ID it will patch into your DSDT before you apply it. You'll know what I mean as soon as you look at it. Changes in vram and stuff after sleep, could be cmos reset since no sleep fixes were applied yet, patched AppleRTC.kext for starters.

Thanks for information about AppleRTC. Right now I can use with efi string id 3 with resolution changer, but no ci qe. Anyone has solution for this?

[eep357]

Thanks for information about AppleRTC. Right now I can use with efi string id 3 with resolution changer, but no ci qe. Anyone has solution for this?

legacyAGPM.kext installed already?

[Akai92]

legacyAGPM.kext installed already?

Yes I installed legacyAGPM.kext.

[rr7]

right, i happened to go past an apple store today, and that got me thinking.

the retina macbook pro has some 2880x2160 display right? and that is beyond the capabilities of LVDS, so therefore its reasonable to assume that the rMBP has an internal eDP display connector, just like my AIO.

and quick look at the displays info screen (which i forgot to take a picture of) shows it an LCD and its connection type is indeed display port.

so far so good.

i then went and did an IOREG dump while i was playing with it, and emailed it to myself from the apple store

i've attached the ioreg dump here for anyone who's interested. i short, it has 2 graphics cards. HD4000 is running AAPL,ig-platform-id 01660002, which is a single LVDS connector on port 1 according to the capri kext.

in this id, my display isnt detected, as my screen seems to be connected to port 4 (port 0x7) or even port D according to the hardware docs.

so i played with DSDT to get settings matched up as much i could. and edited the kext port number as above to get my display detected (changed 01 00 00 00 to 04 06 00 00) which gets it detected. i changed the smbios to the macbookpro10,1 type.

at this point i compared IOreg results.

things to note:
*display still blank
*AGPM doesnt get loaded anymore, i tried legacyAGPM.kext, but it doesnt load either, i'm probably doing that wrong, but i dont know much about that bit yet.
*X86PlatformPlugin isnt loaded, looking at the rMBP ioreg, there are cpu and graphics settings all over that section, on mine, nothing. maybe that and the IOGraphics dependancy failure are connected? SOMETHING isnt loading right on my pc that works on pretty much everyone else's......has to be something like that. perhaps if i can cure all this first, the gfx will just load?

Attached Files

•  rMBP10,1-ioreg.txt.zip   96.87KB   6 downloads
•  rr7-id2.ioreg.zip   344.06KB   6 downloads

[eep357]

"IOGraphics dependancy failure are connected?" can you elaborate on this a bit?