Jump to content

Intel HD Graphics 4600 (Haswell) working displayport


bcc9
 Share

190 posts in this topic

Recommended Posts

This may or may not help. Im not really up on audio injection/HDA patching yet so take it a face value only. But HDMI will show in About this Mac and under speaker options in System preferences as a selectable item. I however, can't test as my monitor only has DVI input.

Voodoo and HDAEnabler1 see the codec, AppleHDA.kext does not.  Codec 0x80862807 is present in AppleHDA binary (Mavericks DPs).  I can make the HDMI/DP connector show up in System Information, unfortunately, cosmetic only.  Perhaps a native MacBookAir6,1 AppleHDA.kext might show something special.

Link to comment
Share on other sites

Voodoo and HDAEnabler1 see the codec, AppleHDA.kext does not.  Codec 0x80862807 is present in AppleHDA binary (Mavericks DPs).  I can make the HDMI/DP connector show up in System Information, unfortunately, cosmetic only.  Perhaps a native MacBookAir6,1 AppleHDA.kext might show something special.

Well I wasn't sure Just getting into patching AppleHDA. But I see what you mean about Voodoo seeing the codec. I can tell you MacBookAir6,2 has no affect on Hdmi. I use this as my smbios and it is very complete. I did notice that a lot of my SSDT's contain much information about video and audio in my Z87 bios. There is B0D3 which is in SSDT that appears to have something to do with HDMI audio. However, renaming in to HDAU(as in real macbookair6,2) and injecting "audio onboard-1 or 2" still has no effect. See below:

Device (HDAU)
                {
                    Name (_ADR, 0x01)
                    OperationRegion (HDAH, PCI_Config, 0x00, 0x40)
                    Field (HDAH, ByteAcc, NoLock, Preserve)
                    {
                        VID0,   16, 
                        DID0,   16
                    }

                    Method (_DSM, 4, NotSerialized)
                    {
                        If (LEqual (Arg0, Buffer (0x10)
                                {
                                    /* 0000 */    0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44, 
                                    /* 0008 */    0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B
                                }))
                        {
                            If (LNotEqual (And (VID0, 0xFFFF), 0xFFFF))
                            {
                                Store (Package (0x02)
                                    {
                                        "hda-gfx", 
                                        Buffer (0x0A)
                                        {
                                            "onboard-2"
                                        }
                                    }, Local0)
                                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                                Return (Local0)
                            }
                        }

                        Return (0x80000002)
                    }
                }
            }

This is DSDT.dsl from real Mac6,2

Link to comment
Share on other sites

Try this:

7e0000000100000001000000720000000200000002010c00d041030a000000000101060000027fff0400180000004400650076006900630065002d00690064000000080000000300220d2c0000004100410050004c002c00690067002d0070006c006100740066006f0072006d002d00690064000000080000000300220d
  • Like 1
Link to comment
Share on other sites

Hmm, been using 0000160a for some time and decided to spice things up a little. I've discovered that setting igd-platform to 0300220D makes my monitor (plugged in via HDMI) go all fuzzy on boot, but after about 10 seconds of tv-like fuzziness it switches on and reports to use LVDS connector-type (02 00 00 00).  I know that the port number for HDMI on my board is 0x6 so I went ahead and modified the 03 06 10 00 00 04 00 00 11 00 00 00 connector to be HDMI (00 04 -> 00 08) and left 11 as is (which to this days I have no idea what this byte stands for?) and screen remained fuzzy on boot. I then tried 11-> 06 as suggested by @toleda on the first page of this thread and it remained fuzzy. No changes with 07 or 82 either, connector-type remains LVDS. Reverting back to stock fb and setting igd-platform back to 0000160a again set the connector type on port 0x6 to HDMI (0008). How come LVDS connector appears in 0300220D if it's not there to begin with?

Link to comment
Share on other sites

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 
03 06 10 00 01 00 00 00
00 00 00 00 
01 05 12 00 04 00 00 00 00 00 00 00
02 04 14 00 00 08 00 00 00 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

 

Try this. LVDS is there but there is a delay that set priority. The higher the delay the higher the priority. Not sure if thats what your after but its the best I got!  :) 

Link to comment
Share on other sites

Try this. LVDS is there but there is a delay that set priority. The higher the delay the higher the priority. Not sure if thats what your after but its the best I got!  :) 

Ughh .. So which is the actual byte that defines the delay ? And how come the higher the delay the higher the priority, this doesn't make sense to me .. it's like "waiting for and hour is faster than waiting for a minute"... Also, what kind of connector is 01 00 ??

 

03 06 10 00 01 00 00 00 00 00 00 00 
01 05 12 00 04 00 00 00 00 00 00 00
02 04 14 00 00 08 00 00 00 00 00 00
 
Link to comment
Share on other sites

In original Framebuffer 82000000 32000000 04000000. It is removed from here to bypass a bug that showed up in DP4. Causing black screen on boot. However, this should still work now even with DP5 and fixed bug. Because we set order direct by 10 12 or 14. Changing order now give you ports 5,6,7. Well its actually 7,5,6 in this case.

 

I don't know that I completely understand the delay order 100%. But, it "appears" the longer delay is used first to check for external monitor on port we will call xx. If no external on xx than fall back to next priority yy(next highest).

  • Like 1
Link to comment
Share on other sites

Ah, I see from where this comes now - Pike's blog .. should have read the post he made, but I couldn't be bothered since I don't have 10.9 nor do I plan installing any of DPs. Will give it a shot.

 

UPD:

Yeah, it appears to work flawlessly here, though I'm not sure what I've gained from it :D

HDMI codec is still not seen by the OS no matter what I had tried (also, I've tried getting a codec dump for it today from Ubuntu 12.04 and it was unable to detect HDMI codec either).

Link to comment
Share on other sites

Yea Pike has that post on his blog. But I actually figured it on my own as I could not get DP4 to show desktop without hot plugging the monitor. I posted to his blog about the issue with no response which was no big deal. But when I posted back that I figured it out, my comments were deleted. Then shortly after he made his post. Keep in mind I offered no solution at the time just that "I figured it out". As for the codec, no luck here either. I did get the intel spec sheet but have not looked into it throughly to come up with any answers. If there even are any to be had. Im not well versed on HDA Patching.  

Link to comment
Share on other sites

HDMI codec is still not seen by the OS no matter what I had tried (also, I've tried getting a codec dump for it today from Ubuntu 12.04 and it was unable to detect HDMI codec either).

Really? The haswell hdmi codec dumps just fine for me under fedora. /proc/asound/card0/codec#0 Attached.

codec0.txt

  • Like 1
Link to comment
Share on other sites

Really? The haswell hdmi codec dumps just fine for me under fedora. /proc/asound/card0/codec#0 Attached.

Yeah, card0/codec#0 appeared as "generic audio codec" with just one node for me under 12.04, perhaps it still lacks support and I should've updated to 12.10, the only codec I was able to dump was 892 under card2/codec#2. Not that having a codec dump at hands will actually do anything at this point. I've looked at the binary disasm from 10.8.5 12F33 and it looks to have all proper function group and widget initializers and yet there is no codec attaching to HDAU (B0D3).

 

 

Yea Pike has that post on his blog. But I actually figured it on my own as I could not get DP4 to show desktop without hot plugging the monitor. I posted to his blog about the issue with no response which was no big deal. But when I posted back that I figured it out, my comments were deleted. Then shortly after he made his post. Keep in mind I offered no solution at the time just that "I figured it out". As for the codec, no luck here either. I did get the intel spec sheet but have not looked into it throughly to come up with any answers. If there even are any to be had. Im not well versed on HDA Patching.  

Thats not the first case of stuff accidentally going missing and then reappearing as a magical solution to a general problem. 

Link to comment
Share on other sites

Yea well it dosen't bother me. I'm not the most knowledgeable person and it usually takes me time to figure things out but I usually get to it.  :) I posted a codec dump from VoodooHDA. a few posted back which list the codec also. But Like I said I can not get it to function. It will show up in about this mac, but no audio. Injection of HDAU or renaming of B0D3 to HDAU or both have no effect. But I do remember back when I had my P5Q board that once I got HDMI to show in about this mac i had to Patch HDA to make it show up under sound in system profiler.?? I'll have to go back and look...

  • Like 1
Link to comment
Share on other sites

Prior to 10.8 it was required to patch in you ids for nvidia and amd cards, as of 10.8 it's not. Any card with an onboard codec works as long as you have patched the connector properly. Here with haswell it's not the case. I've attempted copying over DSMs from Apple's IGPU and HDAU, renaming register AUVD to the one Apple uses which has brought me nowhere.

Link to comment
Share on other sites

Re: HDMI audio. I've noticed this bit in my console logs, which suggest that there has been a timeout in the procedure AppleHDAController::probeStreamCapabilities() determining the state of the codec, which causes HDA Controller to fail to initialize and thus HDA Codec Device not attaching to HDAU (B0D3) device? Also, what kind of codec is  0xffffff8018f10600 anyway?

 

From what I understand it tries to send a request (fCodecRequest) with a codec verb to match the codec state to be equal to 2. And it tries to get this info from codec with identifier of 0xffffff8018f10600 (does it even exist?) and sends the codec verb of 0xF0000 to determine it's state. But as there is no such codec, it stalls and reaches a timeout?

kernel[0]: Sound assertion - Command/Response TIMED OUT and ( kRequestStateMatch == fCodecRequest->state = 2 ), fCodecRequest->command->codec: 0xffffff8018f10600, 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
Link to comment
Share on other sites

Do these thing have anything to do with each other?

 

IOFBHDMIDongleRom 44502d48444d492041444150544f5204     Which is DP-HDMI ADAPTOR

 

This is under IOService - AppleIntelFameBuffer@2

 

Now up under HDEF@1b under AppleHDADriver we have

 

Multidisplayports

0       0x14

1       0x17

2       0x2a

 

Could the ports not be mapped correctly to correspond with the framebuffer?

Link to comment
Share on other sites

I get same Multidisplayports layout as there is on a MBA6,2 (0x20, 0x23, 0x42). And with original Air they have 0x0, 0x5 and 0x5 for IGPU framebuffer ports, and 0x7, 0x5, 0x6 for me. So these ports do not go very well together even on vanilla hardware, which means we are ok. Though I was unable to locate the IOFBHDMIDongleRom property in either my or original unit's IO Registry. 

 

On my HD3000 laptop I didn't have HDMI/DisplayPort in System Profiler up until I've done all the necessary DSDT edits, then DigitalAudioCapabilities showed up. When I patched the framebuffer the audio routing to HDMI started working. Here, with all the DSDT edits it doesn't even show up in System Profiler with patched AppleHDA ... which I believe is the case for all of us here.

Link to comment
Share on other sites

 

Try this:

7e0000000100000001000000720000000200000002010c00d041030a000000000101060000027fff0400180000004400650076006900630065002d00690064000000080000000300220d2c0000004100410050004c002c00690067002d0070006c006100740066006f0072006d002d00690064000000080000000300220d

This EFI strings in OCB plist  work for me with 32MB video card in bios.

 

There is some kind person who tells me how to calculate EFI strings, "{0x80860412, "HD Graphics 4600"}, / / Haswell Integrated Graphics Controller"
 
Link to comment
Share on other sites

This should work:

 

8a01000001000000010000007e0100000300000002010c00d041030a000000000101060000027fff04002400000067007200610070006800690063002d006f007000740069006f006e0073000000080000000c0000001e000000730061007600650064002d0063006f006e006600690067000000e200000047000000000000000000000000000000000003000600260a00d90ade0000000000000000000000000000000000000000000000000000000000000000000000000000000000000001010101000610f09c020100000000000000000002905a4c05a0058403a00000001a0000003000200003000600a00584030018000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002c0000004100410050004c002c00690067002d0070006c006100740066006f0072006d002d00690064000000080000000600260a
Link to comment
Share on other sites

UPDATE: EFI strings in OCB plist 

 

32MB Video card in Bios, work with DVI and HDMI recognized as Iris Pro

 

7e0000000100000001000000720000000200000002010c00d041030a000000000101060000027fff0400180000004400650076006900630065002d00690064000000080000000300220d2c0000004100410050004c002c00690067002d0070006c006100740066006f0072006d002d00690064000000080000000300220d

 

Intel Iris Pro:

 

  Modello Chipset: Intel Iris Pro

  Tipo: GPU

  Bus: Integrato

  VRAM (totale): 1024 MB

  Fornitore: Intel (0x8086)

  ID dispositivo: 0x0412

  ID revisione: 0x0006

 

Doesn't work for me, only with DVI and 64MB I had black screen

8a01000001000000010000007e0100000300000002010c00d041030a000000000101060000027fff04002400000067007200610070006800690063002d006f007000740069006f006e0073000000080000000c0000001e000000730061007600650064002d0063006f006e006600690067000000e200000047000000000000000000000000000000000003000600260a00d90ade0000000000000000000000000000000000000000000000000000000000000000000000000000000000000001010101000610f09c020100000000000000000002905a4c05a0058403a00000001a0000003000200003000600a00584030018000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002c0000004100410050004c002c00690067002d0070006c006100740066006f0072006d002d00690064000000080000000600260a

 

Many Thanks to TimeWalker75a and Cobra03

Link to comment
Share on other sites

It can't in the first place, at least on gigabyte boards, as the device is being described in one of OEM SSDT tables hence you can't just drop these.

When I injected the AAPL,ig-platform-id via DSDT instead of SSDT on my gigabyte motherboard it was working just fine, per post #1. I didn't notice any functional impact from breaking the bios's SSDT4 table... 'course the SSDT patch is cleaner.

 

However, he's probably hoping that the bootloader will just handle this like it does for older intel hd graphics. I've seen no commit to the mainline to more generally handle AAPL,ig-platform-id injection. Chameleon mainline that is.

Link to comment
Share on other sites

 Share

×
×
  • Create New...