the-darkvoid / OS-X-Fake-PCI-ID

Inject fake PCI ID's into devices for OS X drivers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

FakePCIID_Intel_HDMI_Audio.kext

RehabMan opened this issue · comments

I wanted your opinion on this.
Why is this kext mapping to 0c0c -> oc0d?

My HDAU device is natively recognized, so no opportunity to test this, but several people I've had try it have failed. So maybe something is wrong with it.

I looked at the patches generally used for HDAU 0c0c, and I see two things:

  • a patch that extends an upper range check from 0c0b to 0c0c
  • a patch that replaces a comparison against native id 0c0a with 0c0c

(In fact, you have the same patch in your Dell repo)

So shouldn't this kext be mapping from 0c0c -> 0c0a?

You are correct, there is an issue with it.
I noticed it yesterday when reading the Lenovo Y50 thread and confirmed the same.

0c0c -> 0c0d remapping is indeed not working. I will test 0c0c -> 0c0a.
The remap was based an on original Macbook11,1 though.

There may be multiple ids that work, but I think the issue is AppleUSBMergeNub not executing soon enough.

I ran some tests to figure out what the best solution is.

First booting up without any Clover patch / DSDT or FakePCIID:
https://dl.dropboxusercontent.com/u/13972199/audio/No%20Injection%20-%20No%20Display.ioreg

Default DSDT for HDAU:

Method (_DSM, 4, NotSerialized)
{
   If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }
   Return (Package()
   {
     "hda-gfx", Buffer() { "onboard-1" },
   })
}

Framebuffer patch:

Comment: Enable HDMI port 0x05 for Azul framebuffer 0x0a2e0008
Find: 01050900 00040000 07010000 
Name: AppleIntelFramebufferAzul
Replace: 01050900 00080000 07010000 

Result:
Plugging in HDMI or DP while booting or booted causes instant reboot due to crash in AppleHDA.

Using FakePCIID for Intel HDMI with 0x0a0c (DSDT injection):

 Method (_DSM, 4, NotSerialized)
 {
    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }
    Return (Package()
    {
        "hda-gfx", Buffer() { "onboard-1" },
        "RM,device-id", Buffer() { 0x0c, 0x0a, 0, 0 },
        "device-id", Buffer() { 0x0c, 0x0a, 0, 0 }
    })
 }

https://dl.dropboxusercontent.com/u/13972199/audio/FakePCIID%200a%20Injection%20-%20No%20Display.ioreg
https://dl.dropboxusercontent.com/u/13972199/audio/FakePCIID%200a%20Injection%20-%20HDMI%20Display.ioreg
https://dl.dropboxusercontent.com/u/13972199/audio/FakePCIID%200a%20Injection%20-%20DP%20Display.ioreg

Result:
Audio working for both HDMI and DP displays, hot-plugging supported

Using FakePCIID for Intel HDMI with 0x0d0c (DSDT injection):

 Method (_DSM, 4, NotSerialized)
 {
    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }
    Return (Package()
    {
        "hda-gfx", Buffer() { "onboard-1" },
        "device-id", Buffer() { 0x0c, 0x0d, 0, 0 }
    })
 }

https://dl.dropboxusercontent.com/u/13972199/audio/FakePCIID%200d%20DSDT%20Injection%20-%20No%20Display.ioreg
https://dl.dropboxusercontent.com/u/13972199/audio/FakePCIID%200d%20DSDT%20Injection%20-%20HDMI%20Display.ioreg
https://dl.dropboxusercontent.com/u/13972199/audio/FakePCIID%200d%20DSDT%20Injection%20-%20DP%20Display.ioreg

Result:
Audio working for both HDMI and DP displays, hot-plugging supported

So to summarize:

  • with the correct injections, FakePCIID works for unsupported HDAU
  • 0x0d0c or 0x0a0c both work
  • injection must be done prior to kext loading, not via AppleUSBMergeNub
  • not having AppleHDAController issue satisfied (eg. Clover patches or FakePCIID) causes HDMI hotplug problem (eg. this widespread issue is not likely a framebuffer issue, but rather incompletely implemented HDMI-audio)

BTW, how do you verify that the instant reboot is crashing in AppleHDA?

After reboot OS X will give the crash report popup, that indicates the executing thread crashes there.

Do you need native NVRAM for that crash report? (I'm generally using EmuVariable, as I don't like the idea of OS X writing to real NVRAM)

Not sure. I've always been using Native NVRAM.

When rebooting after a crash right after you first get a screen with multiple languages telling you that a crash had occurred.
After pressing enter it contains booting.

On desktop it will ask if you want to re-open the problems you had open, and if you want to send a report to Apple.
You can either ignore the report or view it. Viewing it often gives some insights on what is happening.

I guess I'll have to live dangerously and try using native UEFI NVRAM. Or at least next time I run into a reboot problem by KP. Thanks for the info!

What do you think? Should we just remove the AppleUSBMergeNub for Intel_HDMI_Audio?

Or are you still trying to find a way to make it work?

Interesting that it works for the WiFi case, but not the HDAU case. Must be different timing.

I think its fine to remove the AppleUSBMergeNub and use DSDT injection only.
Still better then applying binary patches on AppleHDAController.

Its weird how it also does not work when injecting the HDMI or DP cable later on.
I can see FakePCIID debug output returning correctly in all cases, but it just does not work.

So maybe its not timing, but something else we are missing in a non-DSDT approach.

Its weird how it also does not work when injecting the HDMI or DP cable later on.

The query is probably done early in driver initialization. Once done, its done... Hotplug later on will not cause it to requery.

I've removed the AppleUSBMergeNub property injector. Changes to the README to reflect installation requirements/usage of FakePCIID_Intel_HDMI_Audio.kext.