[Guide] Intel Framebuffer patching using WhateverGreen

[the_gael]

In Terminal, rebuild cache:

sudo kextcache -i /

thank you

@headkaze - that is also odd it should have been 13, that is what I chose from the dropdown (I don't think 14 is an option) - as I said to @RehabMan I am going to run the install again - in fact I am going to do it several times.

@RehabMan and @headkaze I have run several times again and initially kept getting the same result - then on paying closer attention to the wording of the kextcache output I realised something.

I had thought that I could have all my injected kexts in both EFI/Clover/Kexts/Other and in Library/Extensions provided I had set in config.plist SystemParameters/Inject Kexts to Detect. I thought this meant that they would only be loaded from Clover if they were missing in Library/Extensions.

I read from the kextcache output

"AppleALC.kext - dependency 'as.vit9696.Lilu' not found.
AppleALC.kext is missing dependencies (including anyway; dependencies may be available from elsewhere)"

and wondered if it was a clash due to Lilu, WhateverGreen and AppleALC not being loaded from the same place.

I removed all three from EFI/Clover/Kexts/Other and rebooted - a check of kextcache output revealed that the error regarding finding Lilu was gone for AppleALC

I then carried on testing. Unfortunately the result remains the same I can't get HDMI audio either with just injecting the layout ID alone (tested with all layouts available in FB-Pacher) or with injecting layout ID and spoofing (again tested with all layouts)

@headkaze I believe that the error you saw when layout ID14 was selected in the first PR files I sent would have been due to me not first deleting the entry from config.plist and rebooting before trying another layout in FB-Patcher. I realise now that while you can change the layout ID without deleting the entry and rebooting the same is not true if you have already spoofed the device. At least that is the best theory I have come up with.

 

[RehabMan]

I thought this meant that they would only be loaded from Clover if they were missing in Library/Extensions.

No.

The big switch for "Detect" is presence of FakeSMC.kext or VirtualSMC.kext in kernel cache.

With InjectKexts="Detect":
If FakeSMC.kext or VirtualSMC.kext in cache (eg. installed to /L/E): NO kexts from Clover/kexts/Other are injected.
If neither FakeSMC.kext or VirtualSMC.kext in cache (eg. not installed to /L/E): ALL kexts from Clover/kexts/Other are injected.

My recommendation: Install "all kexts you need" to /L/E. Copy "essential kexts" to EFI/Clover/kexts/Other.
Note that there is overlap between the two sets "all kexts you need" and "essential kexts".

Unfortunately the result remains the same I can't get HDMI audio either with just injecting the layout ID alone (tested with all layouts available in FB-Pacher) or with injecting layout ID and spoofing (again tested with all layouts)

The setup you have now is proof enough that AppleALC + device-id inject is not enough to do what FakePCIID_Intel_HDMI_Audio.kext does (as I expected, since there just isn't code in AppleALC that does what we need it to do in this case).

Until such options/code are added to AppleALC, FakePCIID_Intel_HDMI_Audio.kext remains useful in this case.

 

[the_gael]

No.

The big switch for "Detect" is presence of FakeSMC.kext or VirtualSMC.kext in kernel cache.

With InjectKexts="Detect":
If FakeSMC.kext or VirtualSMC.kext in cache (eg. installed to /L/E): NO kexts from Clover/kexts/Other are injected.
If neither FakeSMC.kext or VirtualSMC.kext in cache (eg. not installed to /L/E): ALL kexts from Clover/kexts/Other are injected.

My recommendation: Install "all kexts you need" to /L/E. Copy "essential kexts" to EFI/Clover/kexts/Other.
Note that there is overlap between the two sets "all kexts you need" and "essential kexts".


The setup you have now is proof enough that AppleALC + device-id inject is not enough to do what FakePCIID_Intel_HDMI_Audio.kext does (as I expected, since there just isn't code in AppleALC that does what we need it to do in this case).

Until such options/code are added to AppleALC, FakePCIID_Intel_HDMI_Audio.kext remains useful in this case.

@RehabMan thank you for that explanation. @headkaze I will use FakePCIID_Intel_Audio.kext just now as it is known to be working for me on the BRIX I am currently testing on. I do like the FB-Patcher and will try to use it for USB on another machine (the one in my profile) so no doubt I will be in touch again soon. Thank you for all the help so far

 

[headkaze]

The setup you have now is proof enough that AppleALC + device-id inject is not enough to do what FakePCIID_Intel_HDMI_Audio.kext does (as I expected, since there just isn't code in AppleALC that does what we need it to do in this case).

Until such options/code are added to AppleALC, FakePCIID_Intel_HDMI_Audio.kext remains useful in this case.

It is odd as the device-id injection works for me and at least one other person I know of (@neocoma504). We also know device-id injection works for IGPU so I'm not sure why it doesn't work in @the_gael's case.

@the_gael Sorry I was wrong about the layout-id being 14 it was indeed 13 (0x0d). So the properties you're injecting do look correct.

 

[RehabMan]

It is odd as the device-id injection works for me and at least one other person I know of (@neocoma504). We also know device-id injection works for IGPU so I'm not sure why it doesn't work in @the_gael's case.

It really depends on what specific native device you have, and which problem in particular you're trying to fix.

 

[headkaze]

It really depends on what specific native device you have, and which problem in particular you're trying to fix.

In @the_gael's case it appears a simple device-id spoof in device properties is not enough. I originally thought that was all FakePCIID was doing but upon further inspection I see it injects into the PCI config space too. So it's more of a hardware level spoof injection. I think the ideal solution would be to integrate this type of injection into AppleALC and maybe have some sort of boot flag to toggle it.

 

[RehabMan]

In @the_gael's case it appears a simple device-id spoof in device properties is not enough.

Yes... As mentioned earlier, requires hooking PCI config space queries for device-id.

I originally thought that was all FakePCIID was doing but upon further inspection I see it injects into the PCI config space too. So it's more of a hardware level spoof injection.

Yup.

I think the ideal solution would be to integrate this type of injection into AppleALC and maybe have some sort of boot flag to toggle it.

I proposed the same to vit9696 a while back (when I was proposing my PR for no-controller-patch).

Yes... similar code already exists in WhateverGreen which could be adopted in AppleALC.

And then a bunch of patching could be removed (Controllers.plist related).

 

[SteveEvans]

I'm keen to switch to using Lilu/WEG, as I'm having issues (see HERE) installing Mojave which I believe it may solve. To do this however I need to understand the following.

My current setup using a Gigabyte Radeon RX 560 Gaming OC 4G requires frame buffer patching, first to select the Acre frame buffer and then a patch to correct the connectors.

The selection of the Acre frame buffer is done thus:

        <key>Graphics</key>
        <dict>
                <key>FBName</key>
                <string>Acre</string>
                <key>Inject</key>
                <dict>
                        <key>ATI</key>
                        <true/>
                </dict>
                <key>RadeonDeInit</key>
                <string>true</string>
        </dict>

The frame buffer is then patched thus. This relies on the Acre frame buffer being in place so I know what's being patched against. Without this knowledge I don't know what to find in order to replace it, as I'm not sure where the default frame buffer definition comes from. How would I use this new patching mechanism in such a case?

        <key>KernelAndKextPatches</key>
        <dict>
                <array>
                        <dict>
                                <key>Comment</key>
                                <string>ATI Connector patch new way</string>
                                <key>Disabled</key>
                                <false/>
                                <key>Find</key>
<data>AAQAAAQDAAAAAQEBAAAAABECAgEAAAAAAAgAAAQCAAAAAQIAAAAAACEDBQQAAAAABAAAAAQCAAAAAQMAAAAAAAAAAwUAAAAA</data>
                                <key>InfoPlistPatch</key>
                                <false/>
                                <key>Name</key>
                                <string>AMD9500Controller</string>
                                <key>Replace</key>
<data>AAQAAAQDAAAAAQMAAAAAABECBQEAAAAAAAgAAAQCAAAAAQIAAAAAACEDAwQAAAAABAAAABQCAAAAAQEAAAAAABAABAUAAAAA</data>
                        </dict>
                </array>
        </dict>

Thanks,

Steve

 

[KrishnaR]

Okay, so I am still new to the whole hackintosh thing. The frame buffer patching will re-enable the IGPU while still leaving the heavy lifting to the discrete GPU, right? Meaning that I can get the benefits of the IGPU, such as Airplay and DRM video on iTunes (broken for some reason, heard this would fix it), while leaving the heavy lifting the the discrete card? Was redirected here from this page on Airplay Mirroring, so that's what I'm guessing. Sorry for asking stupid questions, just sort of lost and don't want to break something. Running 10.13.6 (17G65) btw. I also already have Lilu and WhateverGreen installed.

 

[leo23fla]

Hello, I've been trying to fix the HDMI connection on my laptop, and its been frustrating because the connection type keeps resetting when connecting the HDMI, can anyone help me figure this out?
My laptop has 2 externals connections, HDMI and VGA, with the files I uploaded, VGA is working fine and internal display is working. in other hand when I connect the HDMI my internal display turns black and HDMI works. I don't know if brightness is related, but it's working and don't save across restarts.
Every help is appreciated, thank you.