Intel HD4000, Haswell and Broadwell Inject AAPL,ig-platform-id

[Slice]

I think ig-platform-id should be from a list known to Apple.

[StoneTemplePilots]

Why did you produce unproved rumor?

This gfx chip is supported by Clover and I think by Chameleon

Screen Shot 2014-02-17 at 20.21.04.png

 

​Yeah, it's injected with this ID but there an issue with the framebuffer.

For the moment I quit hackintosh on this board ...

[Micky1979]

As ErmaC and Slice said, ig-platform-id is know thing by Apple, but coming directly from Intel.

The problem is:  dev id Intel 8086 0156 aka HD Graphics 2500 Mobile....has native support by Apple? mmmh...there is a Mac with this chip atm?

even if bootloader injects the correct values ​​taken from a reliable Linux source, this does not mean that there are specific drivers in OSx (or support even if it is present in the info.plist).

worked for other people, at least one?

 

Micky

[faithie999]

As ErmaC and Slice said, ig-platform-id is know thing by Apple, but coming directly from Intel.

The problem is:  dev id Intel 8086 0156 aka HD Graphics 2500 Mobile....has native support by Apple? mmmh...there is a Mac with this chip atm?

even if bootloader injects the correct values ​​taken from a reliable Linux source, this does not mean that there are specific drivers in OSx (or support even if it is present in the info.plist).

worked for other people, at least one?

 

Micky

i don't know if/what "real" macs use HD2500, but from all i've read in various hackintosh forums, here's what i think is supposed to happen in the case of a hack with HD2500 gfx.

 

as i understand it, HD4000 and HD2500 are cousins.  both the stock 10.9.x AppleIntelHD4000Graphics.kext info.plist and AppleIntelCapriFrameBuffer.kext info.plist include PCI match for both HD2500 and HD4000 device id's (0156, 0152 for HD2500 and 0166, 0162 for HD4000).

 

then, for your specific HD2500 gfx, you need to inject the correct ig-platform-id, which i believe earlier in this thread accurately said is a trial-and-error process (there are 12 platform id's).  you'll note that the platform id's are actually HD4000 id's--the ones to choose from are 01660000 thru 01660004, 01620005 thru 01620007, and 01660007 thru 0166000B.   you can inject the platform id either with chameleon (or clover) or by putting it in your DSDT.

 

what i THINK this accomplishes is:  since os x sees the HD2500 gfx (device id 0156 or 0152, for mobile or desktop), it loads the HD4000 kext and the CapriFB kext.  then, because you've injected the correct platform id (by trial and error), those two kexts make the 2500 gfx function as HD4000, with full acceleration.

 

HOWEVER--based on countless hours working on two hacks, one with a  celeron 1017U and one with a 1037U, i've concluded that the Celeron gfx aren't quite HD2500, even tho system profiler reports HD2500 gfx. (i found one citation somewhere the other day that 1037U gfx are "HD2500 Graphics based on HDGraphics", and the intel site for both the 1017U and 1037U list gfx as HDGraphics).   in normal booting, HD4000 tries to load, but since it can't cope with the "almost-HD2500" you get weird gfx at the end of the boot process.

 

i say this because the only way i've been able to boot in normal mode is to remove the HD4000Graphics kext from S/L/E and inject the proper platform id.  then, in my experience on two machines, you get full resolution for whatever display you're using.  safe mode booting works because HD4000graphics kext doesn't load in safe boot.  (my plist incudes dual link yes, graphics mode 1920x1080x32, graphics enabler yes, IGPEnabler no, SkipNvidiaGfx yes)

 

i would guess that if someone way smarter than me could patch the HD4000 kext so that it functions properly with the 1017U/1037U gfx, we'd have a success.

 

i'd really like to have this figured out, since my 1017U is in a nice, inexpensive dell laptop, that without QE/CI there is no DVD player.

 

my 1037U is in a desktop that i'm using for a server.  it's attached to a full HD monitor, and the 1080p output of the gfx chip is fine.  in server service, i don't care about QE/CI. however, without HD4000graphics.kext there is no HDMI audio, which isn't a killer issue, either.

 

so, if someone could patch the HD4000graphics kext, we'd be eternally grateful!

 

ken

[MJKhaani]

Hi ErmaC and tnx for all the work you've done.

I have acer aspire V3-571g with this specification:

 

CPU: Intel Core i7-3632QM 2.2 GHz Ivy Bridge

Internal Graphic: Intel HD 4000

PCIx Graphic: Nvidia Geforce 710M 2GB

Wifi: AR9462 Network Wireless Adapter

Ethernet: NetLink BCM57785

Audio: Realtek ALC269

 

It took me 6 month to be able to boot mac os x installation, because of my BIOS ( BIOS version 2.12). To boot Mac OS X Installation i must set my internal graphic memory to 64MB and my BIOS haven’t have that option, So i ask and wait until now. Here is my internal graphic memory config:

Now I have problem with my graphics card. I've read that a lot of guys get their Intel HD 4000 to working with same DevID as mine by using EFI String or using Chameleon boot loader flags (GraphicsEnabler=Yes IntelCapriFB=[0 to 11]).

But none of them worked for me.

 

I've used Chameleon -IntelCapriFB - with all possible values but stocked after DSMOS arrived. What i've done wrong?

 

I have option to disable my internal graphic, So by that Can i use Geforce 710M in Mac?

BDMsg.rtf

KernelLog.rtf

ioreg.txt

[ErmaC]

Soon I'm going to rework the gma source and I try to Implement a better "injection"

 

The reply made by Herve here--> http://www.insanelymac.com/forum/topic/301965-intel-hd-4600/?do=findComment&comment=2083223

Is a good point where we can start...

 

Stay tuned.

 

ErmaC

[tazman1937]

Hey ErmaC - thanks for everything you've done with Chameleon.

 

I'm trying to install Mavericks on my samsung NP900X4C-A01US

HD4000, i5-3317U

 

I made an install with myHack, chameleon svn2286.

using bootflags:

GraphicsEnabler=Yes InjectIntel-ig=(00006601 - 0b006601)

 

tried all 11, I get blackscreen, no graphics recognized, same if I use IntelCapriFB=(0-11)

 

Do I need to patch AppleIntelFramebufferCapri.kext?

Is there a way to do this without DSDT patching? Because I have no clue how to do that.

 

Any help would be amazing.

[Micky1979]

Hi (I'm not ErmaC  ), anyway check your ioreg for "IMEI". If does not exist you need a fake id for this property, or if your chipset is 6 series.... you need to swap the AppleIntelMEIDriver --> IOPCIPrimaryMatch entry of AppleIntelFramebufferCapri and AppleIntelSNBGraphicsFB.kext inside the relative Info.plist. patch available in Pandora.

[tazman1937]

Okay, so maybe I wasn't clear: I'm stuck at install.  

Everything seems to load up fine (no hangs) but right at the moment the installer GUI should usually come up, it goes black.  I'm almost 100% positive this is due to wrong IntelCapriFB id but I'm not sure why, or how to fix it.  I just figured out how to change the FB hex value in my DSDT using cham. wizard, so I will give that a shot next.  

 

How would one check IOreg without ever getting to install?

 

Additionally, where can I find the proper IOPCIprimaryMatch value, if it's not set properly in the AppleIntelMEIDriver in the first place?

 

Thanks! sorry for being a noob.

[a1ucard]

i don't know if/what "real" macs use HD2500, but from all i've read in various hackintosh forums, here's what i think is supposed to happen in the case of a hack with HD2500 gfx.

 

as i understand it, HD4000 and HD2500 are cousins.  both the stock 10.9.x AppleIntelHD4000Graphics.kext info.plist and AppleIntelCapriFrameBuffer.kext info.plist include PCI match for both HD2500 and HD4000 device id's (0156, 0152 for HD2500 and 0166, 0162 for HD4000).

 

then, for your specific HD2500 gfx, you need to inject the correct ig-platform-id, which i believe earlier in this thread accurately said is a trial-and-error process (there are 12 platform id's).  you'll note that the platform id's are actually HD4000 id's--the ones to choose from are 01660000 thru 01660004, 01620005 thru 01620007, and 01660007 thru 0166000B.   you can inject the platform id either with chameleon (or clover) or by putting it in your DSDT.

 

what i THINK this accomplishes is:  since os x sees the HD2500 gfx (device id 0156 or 0152, for mobile or desktop), it loads the HD4000 kext and the CapriFB kext.  then, because you've injected the correct platform id (by trial and error), those two kexts make the 2500 gfx function as HD4000, with full acceleration.

 

HOWEVER--based on countless hours working on two hacks, one with a  celeron 1017U and one with a 1037U, i've concluded that the Celeron gfx aren't quite HD2500, even tho system profiler reports HD2500 gfx. (i found one citation somewhere the other day that 1037U gfx are "HD2500 Graphics based on HDGraphics", and the intel site for both the 1017U and 1037U list gfx as HDGraphics).   in normal booting, HD4000 tries to load, but since it can't cope with the "almost-HD2500" you get weird gfx at the end of the boot process.

 

i say this because the only way i've been able to boot in normal mode is to remove the HD4000Graphics kext from S/L/E and inject the proper platform id.  then, in my experience on two machines, you get full resolution for whatever display you're using.  safe mode booting works because HD4000graphics kext doesn't load in safe boot.  (my plist incudes dual link yes, graphics mode 1920x1080x32, graphics enabler yes, IGPEnabler no, SkipNvidiaGfx yes)

 

i would guess that if someone way smarter than me could patch the HD4000 kext so that it functions properly with the 1017U/1037U gfx, we'd have a success.

 

i'd really like to have this figured out, since my 1017U is in a nice, inexpensive dell laptop, that without QE/CI there is no DVD player.

 

my 1037U is in a desktop that i'm using for a server.  it's attached to a full HD monitor, and the 1080p output of the gfx chip is fine.  in server service, i don't care about QE/CI. however, without HD4000graphics.kext there is no HDMI audio, which isn't a killer issue, either.

 

so, if someone could patch the HD4000graphics kext, we'd be eternally grateful!

 

ken

 

I think this pretty much sums it up for us HD2500 mobile users on Yosemite. As i understand is either go back to Mountain Lion to get full Graphics Support or, settle for QE/CI in Yosemite and wait for maybe some day a patched HD4000Graphics Kext to solve our issue. Ive only two more test to do before i resign to this conclusion:

 

1.- Set Graphics Memory to 96 and try the different IGPProcessorIDs

2.- Inject CPU ID to "trick" osx that its not a celeron? I dont know if this would make a difference tough...

 

Anyways, if someone comes up with a better solution please share.

 

Thanks,