Intel HD Graphics 4600 (Haswell) working displayport

[Picasso]

Just an update on progress since last time. Since I don't have any options in my BIOS to modify the VRAM provided to the 4600, I tried playing around with the values under DSDT. I literally tested every value listed from 2GB - 1MB and it didn't seem to do anything about the glitches and artifacts. Some may have made it glitch faster, giving more image to work with before I would fix it but otherwise, no real significant change. I haven't looked much into trying to disable my GeForce yet, but I am planning on giving it a test within the next few days. At the very least, i'm hoping my battery performance goes up with it disabled.

 

I changed my SystemType back to 2 and haven't had any issues since that i've noticed. I briefly tested out ssdtPRGen to see if maybe, just maybe I could get CPUPM to work with my Haswell and give me support but that didn't work either. It's looking like waiting for 10.8.5 final is my only option at this point.

 

I also merged your IGPU change into my current DSDT. Performance doesn't seem to have changed since doing so, so that's good. I did notice that after the merge, I am given a brightness slider under Display prefs but it's purely cosmetic and doesn't work. I really need to look into fixing that. >_>

Can you post some test to compare with others cards? 

[gygabyte666]

*sigh* You gotta be more specific with requests. My last reply had a ton of info in it and I'm not going to even try to decipher what it is you're referring to. If it has anything to do with my dsdt, search the thread and the forum. Everything is already posted here. Again, you just need to look.

[Picasso]

*sigh* You gotta be more specific with requests. My last reply had a ton of info in it and I'm not going to even try to decipher what it is you're referring to. If it has anything to do with my dsdt, search the thread and the forum. Everything is already posted here. Again, you just need to look.

I mean test about how fast is to get video on board.  Like Heaven. We can compare with discrete cards your benchmark. 

And maybe it´s better on board video that a discrete video card.

 

http://unigine.com/products/heaven/

[TimeWalker75a]

Heaven is lousy, about 6 to 8 fps on Extreme preset, about 12 to 15 on Custom preset. Though according to CInebench this card scroes as much as AMD HD4870, which is a direct competitor to old G92-series cards like 9800GTX+ and GTS250. Personally, after switching from GTS250, the OSX UI w/ HD4600 performs very snappy. When it comes to extensive OpenGL graphics it performs on par with HD4000, possibly slightly better, but it's on 10.8 (no new GL support). Playing TeamFortress wasn't as pleasant as I otherwise had hoped.

[bcc9]

BTW, as of the current chameleon mainline version, there's no need to inject via dsdt or ssdt. You can simply configure your ig-platform-id in org.chameleon.Boot.plist. Mainline 2262 version of chameleon is here: http://www.insanelymac.com/forum/files/file/59-chameleon-22-svn/

ermac's announcement is on the home page: http://www.insanelymac.com/_/osx86/intel-hd4000-and-haswell-inject-aaplig-platfor-r1005

 

For the ig-platform-id I listed in post #1 that works with displayport, I use:

        <key>GraphicsEnabler</key>
        <string>Yes</string>
        <key>IntelAzulFB</key>
        <string>10</string>

in my org.chameleon.Boot.plist.

[ham4ever]

BTW, as of the current chameleon mainline version, there's no need to inject via dsdt or ssdt. You can simply configure your ig-platform-id in org.chameleon.Boot.plist. Mainline 2262 version of chameleon is here: http://www.insanelymac.com/forum/files/file/59-chameleon-22-svn/

ermac's announcement is on the home page: http://www.insanelymac.com/_/osx86/intel-hd4000-and-haswell-inject-aaplig-platfor-r1005

 

For the ig-platform-id I listed in post #1 that works with displayport, I use:

        <key>GraphicsEnabler</key>
        <string>Yes</string>
        <key>IntelAzulFB</key>
        <string>10</string>

in my org.chameleon.Boot.plist.

 

 

 

thanks my intel 4600 woooorkiing

[Picasso]

 

thanks my intel 4600 woooorkiing

 

Do you know how to get  ig-platform-id ??? thanks

[ham4ever]

Do you know how to get  ig-platform-id ??? thanks

 

i  jusy used this  in my org.chameleon.Boot.plist.

 

<key>GraphicsEnabler</key>

<string>Yes</string>

<key>IntelAzulFB</key>

<string>10</string>

[toleda]

Hypothesis is wrong, deleted.  See Post #115 for update.

[TimeWalker75a]

Good find, toleda! Hopefully this not off-topic indeed.

I guess the only option is to wait for new Core i3 processor release and hope for a major BIOS update coming from AMI... It's not the first issue with BIOS, at least not at my board. I can't disable UART and LPT, they simply won't turn off.. same with IGPU, if discrete graphics card is installed and IGPU is turned off in BIOS it's still seen by the system (Windows included)...

[gygabyte666]

BTW, as of the current chameleon mainline version, there's no need to inject via dsdt or ssdt. You can simply configure your ig-platform-id in org.chameleon.Boot.plist. Mainline 2262 version of chameleon is here: http://www.insanelymac.com/forum/files/file/59-chameleon-22-svn/ermac's announcement is on the home page: http://www.insanelymac.com/_/osx86/intel-hd4000-and-haswell-inject-aaplig-platfor-r1005For the ig-platform-id I listed in post #1 that works with displayport, I use:

<key>GraphicsEnabler</key>
        <string>Yes</string>
        <key>IntelAzulFB</key>
        <string>10</string>

in my org.chameleon.Boot.plist.

Thanks for this. Mine works using either 8-0 as the value. 10 does not work for me and sadly, this has not fixed my booting artifacts/glitching issues. However, using 9 as the value makes the booting glitches less obvious and switching my refresh rate seems not to fix the issue. When I can, I'll test out more values and maybe I can find the "sweet spot" for my system.

 

UPDATE: Got it! If I use 12 as the value, my startup artifacts and glitches virtually disappear and I do NOT have to change my refresh rate to make the system usable anymore! I still can see one tiny artifact on the login screen but it's so insignificant that it can be easily overlooked and considering I did further testing using around 9 different values without getting any fix for it, i'd say it's not worth any extra work on my part. Other than that, everything looks dandy. Thanks again for pointing this out. It made my testing MUCH easier.

[toleda]

Unexpected behavior with Azul framebuffer 03 00 22 0d.  Booting with both DP and HDMI connected, IOReg shows DP (port 0x7) and HDMI (port 0x5).  Booting with DP only, display shows on port 0x7.  Booting with HDMI only, display shows on port 0x7, not port 0x5.  Editing port 0x5 for the HDMI connector makes no difference.  It appears the Azul framebuffers are not configured to the physical motherboard connectors while the SB and IB framebuffers are.

[MiniHack]

Unexpected behavior with Azul framebuffer 03 00 22 0d.  Booting with both DP and HDMI connected, IOReg shows DP (port 0x7) and HDMI (port 0x5).  Booting with DP only, display shows on port 0x7.  Booting with HDMI only, display shows on port 0x7, not port 0x5.  Editing port 0x5 for the HDMI connector makes no difference.  It appears the Azul framebuffers are not configured to the physical motherboard connectors while the SB and IB framebuffers are.

Yes, that is what Pike R Alpha had said on his blog a while back. I agree also, what shows up in ioreg as Port Numbers is obviously not the physical port number as it depends on what is actually plugged in. Maybe to do with the time delay element that Pike also mentioned in the decoding of the binary for the kext for prioritising the different connectors. The other thing about this particular frame buffer is that two of the connections have the same time delay (or priority).

On my board I have one DP, 1 HDMI and 1 DVI connection. I have not managed  to amend any of the connection types successfully to DVI on my board (always scrambled). whereas the HDMI and DP connections both work fine and seem to swap around port numbers according to what is present at boot.

[TimeWalker75a]

Not sure how useful this could be, but I've traced the log to procedure AppleHDAController::checkCodecCommandTimeout(unsigned int, bool) inside AppleHDAController and the errors related to that:

kernel[0]: Sound assertion - Command/Response TIMED OUT and ( kRequestStateMatch == fCodecRequest->state = 2 ), fCodecRequest->command->codec: 0xffffff80184a4800, fCodecRequest->command->verb: 0xF0000, fPoweredDown: 0
kernel[0]: Sound assertion in AppleHDAController at line 5459
kernel[0]: Sound assertion in AppleHDAController at line 5460
kernel[0]: Sound assertion in IOHDACodecDevice at line 161
kernel[0]: Sound assertion in IOHDACodecDevice at line 567
kernel[0]: Sound assertion in AppleHDAController at line 4693
kernel[0]: Sound assertion in AppleHDAEngine at line 599
kernel[0]: Sound assertion in AppleHDAEngine at line 6963

 

I've tried making it go directly to 0x80B3 offset by patching 0f84b2010000 to 0f85d6010000 and all the errors except 599 assertion are gone from the log (which as of 10.8.5 I also get on my ALC269, and it wasn't there before.. so its nothing to worry about)...When OSX starts up a display mirror icon appears in the menu bar for a brief second and then GUI freezes, mouse is not responding, nor is the keyboard.

 

I think in general it just stalls expecting the command from codec and it never happens (same as with BT 30 sec timeout for configurePM procedure that I had patch to not wait for 30 seconds)...

 

In the attached pdf with purple arrows is marked the routine of this procedure based on console log and the end result. With red circle what I believe is the failure, which ends up as return, meaning the procedure partially loops and thus errors in console appear twice in a row. With green circle is what I believe should happen when this procedure succeeds.. I could of corse try just reversing the je to jne at 0x807e to see if the comparison to 1 would return false (not equal) and it would jump to 0x80b3.. but I don't want all the errors to be produced along the way. I'm not that good with assembly code so pardon if I'm just waffling complete nonsense here .. but that are my observations. 

 

checkCodecCommandTimeout.pdf

[toleda]

Haswell/HD4600  HDMI Audio is working in 10.8.5, see Mountain Lion HDMI Audio - OSx86 10.8 (Mountain Lion) - InsanelyMac Forum

 

Summary, two patches (credit: PikeRAlpha) and new HDMI audio dsdt edits/HDMI audio ssdt (credit bcc9):

1. AppleHDA.kext, fixes missing codec

2. AppleIntelFramebufferAzul.kext, assigns DP to port 0x5 and HDMI to port 0x7 in 0x0300220D framebuffer, DP and/or HDMI audio working

3. dsdt/ssdt, add HDAU@3, remove HDEF/hda-gfx injection, both dsdt edits and the ssdt enable native HD4600 AGPM.

 

My hypothesis was completely wrong.  Appears device_id 0x0c0c was included in AppleHDAController and disabled. Intentional?  Test plan failure? Interestingly, the disabling is different in AppleHDA.kext _v2.4.7 and _v2.5.2.

 

Mavericks details: Haswell HDAU solution | Pike's Universum

[TimeWalker75a]

Haswell/HD4600  HDMI Audio is working in 10.8.5, see Mountain Lion HDMI Audio - OSx86 10.8 (Mountain Lion) - InsanelyMac Forum

 

Summary, two patches (credit: PikeRAlpha) and new HDMI audio dsdt edits/HDMI audio ssdt (credit bcc9):

1. AppleHDA.kext, fixes missing codec

2. AppleIntelFramebufferAzul.kext, assigns DP to port 0x5 and HDMI to port 0x7 in 0x0300220D framebuffer, DP and/or HDMI audio working

3. dsdt/ssdt, add HDAU@3, remove HDEF/hda-gfx injection, both dsdt edits and the ssdt enable native HD4600 AGPM.

 

My hypothesis was completely wrong.  Appears device_id 0x0c0c was included in AppleHDAController and disabled. Intentional?  Test plan failure? Interestingly, the disabling is different in AppleHDA.kext _v2.4.7 and _v2.5.2.

 

Mavericks details: Haswell HDAU solution | Pike's Universum

Yeah, I was searching in post-problem area as well, should have looked at controller init first... time out occurs because it fails to initialize it.

 

The codec is not missing it's just that 0x0c0c controller (non Apple-native) is not being rooted correctly (on purpose I assume). The series of checks for it's initialization are similar to how codec-id is being matched in AppleHDA. Here device-id of 8086 HDMI controller is being matched instead, but only the one used by Apple is actually being rooted all the way through to initialization. Actually, the checks (or *disabling* how you call it) are fairly identical across 10.8.5 and 10.9, I ended up just doing the same thing as I would with codec-id matching:

Could you test the same approach for 10.9 binary as well ? Left is for 10.9 and right is for 10.8.5: http://puu.sh/4D7C4.png

As you can see the algo is identical: compare device-id of hdmi audio controller (not codec) to 0x0c0b if it hasn't matched jump and compare with 0x0d0b, then if hasn't matched jump and compare with 0x0c0c and here we end up with dead route. Whereas if we change device id of 0x0c0b to 0x0c0c we will get a match and jump to check if device id is 0x0a0c and if we patch here again to 0x0c0c we get a mach and jump to controller init subroutine.

 

Also, I've mentioned it over Pike's blog. The sound assertion 599 you may see in 10.8.5 appears due to missing device-property called MaximumBootBeepVolume. I've checked your git repos and none of the edits seem to include it, so people with Haswell (and everyone else who has updated to 10.8.5 and possibly 10.9 DPs) are bound to get sound assertion errors in their log due to lacking this property.

[Pike R. Alpha]

The JA instruction below the CMP 0x0c0b in AppleHDAController::setupHostInterface() won't make the jump when you change it to 0x0c0c because it is equal and not greater than. The result is that not all devices will be checked (which is what we want it to do). This is why we only changed the JMP for 0x0c0c.

[TimeWalker75a]

This jump will most likely require an address recalculation after every OS update though, that's why I was looking at trying to make it more universal. The approach i've mentioned works for me (with 0x0c0c) in 10.8.5 but the operator sure is different in 10.9 DP8 after comparing 0x0c0b to controller's device id. Though, 77 is still an "jump short if not below or equal", whilst 7F used in 10.8.5 is "jump short if not less or equal" .. which is basically same thing since *equal* is there. So it should work nonetheless.

 

UPD:

My understanding of the check sequence in both 10.8.5 and 10.8 DP8: 

	If (!(gDeviceId <= 0x0b0c)) // device id is not 0x0a0c or 0x0b0c
	{
		If (!(gDeviceId <= 0x0d0b))
		{
				If (!(gDeviceId <= 0x1c1f))
				{
					If (dDeviceId == 0x1c20){ ... }	
					Else { ...}
				}
		}
		Else
		{
			If (gDeviceId == 0x0c0c) { Fail () }
		}
	}
	Else
	{
		If (gDeviceId == 0x0a0c) { Init () }
		Else{ Fail () }
	}

So, we can assume that by changing 0x0b0c to 0x0c0c we make it execute the Else statement (it's equal!), where when checking for match to 0x0a0c, which we substitute with 0x0c0c again, we get an equals match and we go to Init () ?

Honestly, the difference in jump operators (0x77 vs 0x7F) is most likely due to different ways of compiling the binary for target OS 10.8 and 10.9..  the algo still remains the same.

 

UPD2: 

Well, it supposedly ends up as a panic in 10.9 DP8 .. so not so universal after all.. 

 

UPD3:

Changing the opcode for this *initial* check from 77 to 7f appears to work though. Hopefully, if it's a case of this opcode being JA for target OS 10.9 (and JG for 10.8) it would be pretty much universal to patch it like this, without the need to recalculate the jump address (which will most likely change with updates):

0b0c000077 >  0c0c00007f
0c0a0000 > 0c0c0000

UPD4:

The person who was testing DP8 patch for me has mistakenly left Pike's patch in place as well, which resulted in panic. So my assumption was indeed correct and it's still possible, even in 10.9 DP8 to patch:

3d0b0c0000 > 3d0c0c0000
3d0c0a0000 > 3d0c0c0000

[bcc9]

So my suspicion here http://www.insanelymac.com/forum/topic/290783-intel-hd-graphics-4600-haswell-working-displayport/page-3?do=findComment&comment=1937848 that you needed the connector-type set correctly for working HDMI audio was right.  I originally found this years back when working on HDMI audio for nvidia graphics, and some people found it to be a necessary fix at the time.

Looks like it's now needed for intel too; nice work.

I agree with TimeWalker that a patch that needs to be re-done each release is not very desirable.  
I haven't seen documentation for the patch, or bothered to look at the code, but if it's just matching on the device-id have you tried overriding that via injection, instead of doing a binary patch?

[TimeWalker75a]

So my suspicion here http://www.insanelymac.com/forum/topic/290783-intel-hd-graphics-4600-haswell-working-displayport/page-3?do=findComment&comment=1937848 that you needed the connector-type set correctly for working HDMI was right.  I originally found this years back when working on HDMI audio for nvidia graphics, and some people found it to be a necessary fix at the time.

Looks like it's now needed for intel too; nice work.

I agree with TimeWalker that a patch that needs to be re-done each release is not very desirable.  

I haven't seen documentation for the patch, or bothered to look at the code, but if it's just matching on the device-id have you tried overriding that via injection, instead of doing a binary patch?

It appears to be reading the controller id from physical PCI root (same as with codec-ids), as substituting ID hasn't done anything. I've tried it at one point and even though IOReg pretty much was matching one from MBA6,2 there wasn't any improvement. I found that on my mobo with no DP I'm perfectly fine with 0x0A160000 platform id, which makes my HDMI appear with signal type 8 and connector type 8 with no additional edits to the framebuffer. 

 

Pike's binary patch just reroutes the 0x0c0c controller id to the offset where Apple's 0x0a0c is being router for initialization. This requires address calculation (nothing major, but still not terribly comfortable for most people out there).

[bcc9]

It appears to be reading the controller id from physical PCI root (same as with codec-ids), as substituting ID hasn't done anything. I've tried it at one point and even though IOReg pretty much was matching one from MBA6,2 there wasn't any improvement. I found that on my mobo with no DP I'm perfectly fine with 0x0A160000 platform id, which makes my HDMI appear with signal type 8 and connector type 8 with no additional edits to the framebuffer. 

You can dsdt edit a patch that changes the PCI ID for a device in the PCI config memory, thru the device's _INI method.  This is what I really meant, and it sounds like it would do the job.

 

Edit: Actually, wait, I think that only works for subsystem ID, with the device-id being read only.  

Edit: Actually, wait, I think that only works for subsystem ID, with the device-id being read only.  

I wonder if we could patch this via an efi driver, since the integrated graphics device-id is being determined at run-time based upon the CPU.

[TimeWalker75a]

We can override memory maps and god knows what, so I wouldn't be surprised it's possible.. but such a fix would be a really involved one I'd say.

[TimeWalker75a]

Updated my post #118 here, which has direct relation with post #116. Apparently there *IS* a universal solution to this patch, at least at this point in time!

[toleda]

Haswell DVI2HDMI and HDM!x2 audio working.

 

Three displays supported, two with HDMI audio (Intel)

1. DP + HDMI or DP + DVI
2. DVI (w/DVI2HDMI adapter)
3. HDMI, HDMIx2 or HDMI + DVI
4. Native: DP and DPx2, no Azul edit required

AppleIntelFramebufferAzul.kext/Framebuffer 0x0300220D/edit

01 05 12 00 00 04 00 00 07 01 00 00 
02 04 14 00 00 08 00 00 06 00 00 00
03 06 12 00 00 08 00 00 06 00 00 00

[The Real Deal]

Fellas, sorry if a bit off topic, don't want to create a new topic for a minor issue.

 

How i can find the value to patch and substitute in AppleIntelFramebufferAzul to show a correct Iris Pro ID instead of HD4600 (0412 to 0d22) in this capture ?

 

I can hex edit, no problem.

 

Thanks a lot