Getting rid of FakePCIID.kext about nucintosh

[huangzonghao]

@zoroo07 it seems the applealc wouldn't work unless the alcid is set. For me setting alcid=28 got it work on NUC8I5BEH. Should be similar on BEK. https://github.com/acidanthera/applealc/wiki/supported-codecs. and our codec should be realtek alc233

@zearp yes I have exactly the same issue here. And I was only able to realize it when I accidentally plugged a second display via that usb c dp. and magically the hdmi audio device appeared. For now applealc + fakepciid seems to be a seamless solution. I am currently looking into this as well. Hope we can eventually get it done

[mackonsti]

Hello everyone, apologies to join late, I accidentally found this thread while also searching for means to "get rid" of FakePCIID kext and HDMI Audio plugin, too... So here is a summary of my set up and findings:

• Using Catalina latest on NUC8i7BEH2 with Intel HD Graphics 655 declared as 0x3EA50004 i.e. [8086:3ea5]
• Audio device is Realtek ALC235 [8086:9dc8] that I set with layout ID 0x03 with AppleALC (Hackintool reports codec 0x10EC0235) -- haven't tested auto-sensing to be honest;
• Also using FakePCIID.kext and FakePCIID_Intel_HDMI_Audio.kext that works out-of-the-box and allows my USB-C-to-MiniDP on my Dell to get Audio; not using any other monitor (i.e no HDMI) just this connection;
• IGPU patching is kept very simple, I only inject AAPL,ig-platform-id in Clover, really (need AAPL,GfxYTile too as the orientation vertically is causing some funny macro blocks etc.)
• I make sure that hda-gfx set to "onboard-1" exists in both HDEF and IGPU devices (via IORegistryExplorer, for example)

As FakePCIID.kext does not load on my other NUC10 at all, I also wanted like @zearp to use a method that works and that can sustain in time. On my system indeed I get 2 different entries under HDEF device, i.e. AppleHDAController@1F,0 and AppleHDAController@1F,3 when using FakePCIID + HDMI Audio plugin (seen in IORegistryExplorer.app)

After searching a lot, found that Rehabman (the developer of this kext) writes that:

Sandy Bridge (HD3000) and Ivy Bridge (HD4000) use a single audio device (HDEF) with multiple codecs (also Skylake and later). Both onboard audio and HDMI audio live on the same HDEF device. As a result, there is no second device, so no need to rename it to HDAU.

Hence what we need to add is not a "true" device but a different CODEC and activate it under HDEF.

The AppleHDAController kext implements a whitelist for certain HDAU devices. Some PCs use devices that are not directly supported. But FakePCIID_Intel_HDMI_Audio can spoof the PCI IDs in order to satisfy AppleHDAController's whitelist check.

If you look closely inside FakePCIID.kext and more specifically FakePCIID_Intel_HDMI_Audio.kext i.e. the Info.plist I mean, you will see that our Intel Audio device gets detected by the section Intel HDMI Audio - 300-series 0xa348 0x9dc8 that injects a faked device RM,device-id as 70 a1 00 00 thus enabling the secondary CODEC.

What we need to figure out is if this CODEC can be enabled with any other means. Unfortunately, it seems Rehabman has quit the scene and isn't available to explain to us how this works i.e. how the kext fakes/enables this device ID that allows Apple's own kext to activate AppleHDAHALPlugIn.bundle and thus show in Hackintool this "Intel Kabylake HDMI" audio CODEC or device.

This is most likely what VoodooHDA does too, but as it's not actively maintained and has some other requirements (CSR active etc. that I don't want to do) it's also a blocker for me, too.

Today, I tried adding a fake HDAU device under IGPU 9with some device IDs) via an SSDT-HDAU.aml injection but to no avail. The new device does not get added in the IORegistry tree... So adding some device doesn't seem the way to go, we need to find a method to fake some IDs (via Clover or OpenCore) so something that theAppleHDAController.kext recognises...

My repo is here just in case, but the above is not published yet: https://github.com/mackonsti/nuc8i7beh

An exposure of this thread/ticket to people/coders would be great, as we need some insight on how the FakePCIID kext code works. We have the device IDs but... must make them work. Cheers...

[mackonsti]

Thanks for your welcome @zearp yes I have no solution for the SD card but as it's under the monitor I have no access to it so I didn't bother about it to be honest (not that a 100% working solution exists really). But I have some VERY good news to share! With vit9696 we managed to get FAN readings! Coming soon to a kext near you: acidanthera/bugtracker#395

(I tried picking up an Amazon Warehouse deal (France) for a NUC i7 then i5 but sent them back, they weren't working so I am out of luck for second hand NUC8's to be honest, I am no longer trying second hand as it's tiresome to send them back etc. but new ones have not come down in price (even in Amazon DE) they are quite high despite NUC10 being out and NUC11 recently)

Nevertheless, for the Digital Audio, we need to pick the brains of the developers of WhateverGreen for that so they can possibly integrate such feature to activate the Codec just like FakePCIID+HDMI_Audio does, as only a developer can understand what Rehabman's kext does and how (and if) this can be replicated.

ACPI is not involved I think as it's addressing a different subsystem. It's just a matter of "informing" the OS that this Codec exists upon boot time, just like FakePCIID does. Something to do with that extra Apple driver/kext loaded...

If you look closely, the 2 different CODECs raise 2 different drivers:

• Analogue audio raises AppleHDADriver
• Digital audio raises AppleHDAHDMI_DPDriver

So the idea is to get this AppleHDAHDMI_DPDriver upon boot time, Catalina or Big Sur...

[mackonsti]

Hi @zearp and everyone, hope you are well and safe. I may have something here but it requires your Xcode building (rather than coding) skills. I came across today the following guide/article: https://osy.gitbook.io/hac-mini-guide/details/hda-fix and expanded here: https://github.com/osy/HaC-Mini/blob/master/details/hda-fix.md

According to the author: "AppleHDAController has direct support for mapping one PID to another by modifying the Info.plist." thus we should be able to map our integrated Intel HDMI audio device ID to the natively-supported Kaby Lake identifier e.g. 8086:A170) for example. But "because we are using AppleALC with its own patching system, we can leave this kext untouched and modify the Controllers.plist in AppleALC" instead (and not break kext signatures etc.)

I searched and found that Controllers.plist does indeed belong to the AppleALC code, but any change/addition needs re-compilation of the kext, according to the developers: https://github.com/acidanthera/AppleALC/wiki/Adding-codec-support

My understanding is that if we could find our CPU's audio controller ID and get it to be mapped to the supported Skylake or Kabylake ID, we add it to Controllers.plist and rebuild the kext. Then, we could still use the same Realtek ALCxxx coded as before via alcid=XX for analogue audio, too, hopefully ending the FakePCIID need.

What do you think? I have no means or knowledge in compiling via Xcode, anyone knows to try this? According to lspci -nn my two NUCs have:

NUC8:
00:1f.3 Audio device [0403]: Intel Corporation Coffee Lake High Definition Audio Controller [8086:9dc8]
NUC10:
00:1f.3 Audio device [0403]: Intel Corporation Comet Lake High Definition Audio Controller [8086:02c8]

which I guess this is the ID the guide author refers to...?

[zearp]

The section for audio is here. It was also in the old config but didn't have some of the current fields defined. The DeviceProperties section can be used to do what FakePCIID does in a way. Don't know if it can do the same in all cases though.

I think what did the trick was adding AAPL,slot-name and hda-gfx. There was not really an idea behind it but an attempt to get audio over hdmi to work on the new macOS. A case lets see what happens. I remember for laptops adding these entries sometimes helps but for desktops I've not needed it till now.

[zearp]

No problem! If you follow the Dortania guide for Coffee Lake you should be ok. I don't recall if I used the desktop or laptop one. The NUC is essentially a laptop board in a little box. Both will probably get you up and running to a working desktop and then in post-install you can use the guide again to figure out which ACPI patches are needed based on the DSDT of the machine (for OpenCore we don't patch the whole DSDT we simply use it for reference to see whats needed to be patched). And of course can have a look at how I did it.

It's a good thing to do for it for yourself like you do instead of simply downloading a ready made EFI and call it a day. Though I do understand those too, I was one of them once due to lack of time. I have this repo for those not too lazy to learn and willing to understand but maybe lack some time to do it all from scratch. If you have any questions about the OpenCore transition on your NUC let me know.

[zoroo07]

Hi zearp,

have you tried using voodoohda.kext instead?
I just got a NUC8i5bek and installed using some of your solutions to get the install to work.
I did try voodoohda and it gave me a digital HDMI out and headphone. This audio AudioALC kext didn't work for me however. The system isn't stable so I'm going to try using your solution instead of you hybrid and see if that works better.

thanks for your work mate!

Paul

[zearp]

I've looked into it but it seems that its no longer being actively maintained, just like FakePCIID. Ideally the solution is either with an ACPI patch or AppleALC options/configuration. Everything works great now, I just like to minimise the number of kexts used.

I opened the issue cuz maybe I missed something in the config that causes audio over HDMI not to work without re-plugging the cable or using FakePCIID. There must be a better way to add the IOHDACodecDevice audio device when HDMI is used, I just can't figure it out lol.

[zearp]

I think I currently use layout 14 in the EFI. I've tried a few and didn't notice any differences in regards to audio over hdmi. Not sure why I ended up on 14. For my usage most important is headphone auto-sensing which works fine in 14 and probably others too.

To get audio over hdmi to work without FakePCIID kext I think we need to somehow create the device thats added when re-plugging the cable as shown in the IOreg dump. I have no clue what else to try that I haven't tried yet, like manually adding the device in the OpenCore config.

[huangzonghao]

I didn't realize my audio output auto-switching didn't work until I saw your post, as I have always had the speaker plugged in via audio jack.

And a quick test shows:

1. If the system boots up with headphone plugged in, it will show "Headphone" in output device list, even after the headphone got unplugged.
2. If the system boots up without the headphone, it will show "Internal Speakers" in output device list. And plugging headphone back in wouldn't make it switch.
3. Both alcid=14 and alcid=28 have the same issue.

Not sure what's wrong at the moment.

[zearp]

I can't reproduce that, auto-sensing here works no matter if I boot with the headphones connected or not. I don't use any alcid=XX boot flag in my config and only use the layout-id property to set the layout. I don't know if you modified the config or maybe use a different EFI all together but auto-sensing should work.

[huangzonghao]

So I just tried the out using layout-id following the instructions here https://dortania.github.io/OpenCore-Post-Install/universal/audio.html#testing-your-layout

And the result is exactly the same as I have had with alcid: both 14 and 28 wouldn't trigger the auto-sensing up.

And more interestingly, I also tried to kill coreaudiod, and it won't make the change either. (If I boot up the system up with headphone plugged in, and then unplug the headphone and kill coreaudiod, the audio device would still be listed as headphone)

So I guess it must be some value being fixed during boot. I'll report back once I find more clue.

[zearp]

Not sure if it's stored in NVRAM but you can wipe it and see what it does. I'm using my headphones on and off quite often during the day and sensing for me works fine on all machines including my test NUC that always runs the current EFI hosted here. So if you're using my EFI and didn't change anything it should just work.

[zearp]

@mackonsti Thanks for your post, very interesting to see your process and files. I will check our your repo in more detail when I got some time to sit down and see how you did things. Always interesting to see the different NUC8 configs.

I was thinking that since re-plugging the video cable creates the device without the need for any kexts or patches, maybe there's a way to re-plug the cable without actually re-plugging it. Like via ACPI or something else, if possible there would be a quick switch during start-up where it virtually re-connects the cable and then we're set. Wpould be the ideal solution. Maybe re-initialising those ports in ACPI can do the trick?

Currently I'm trying to figure out how to get usb on the usb-c port working properly again after patching Thunderbolt firmware and there's an issue where the Thunderbolt controller doesn't turn on fast enough so it panics when waking up from sleep. I might give up on Thunderbolt though, cuz it's above my pay grade and I only have limited Thunderbolt devices to test with.

If I can't figure out Thunderbolt fixes I'll focus on the audio stuff and revert to my previous ACPI patches that didn't include TbtOnPCH and only fixed usb-c hot plugging. Thunderbolt works fine with those patches, just not Thunderbolt hot plugging.

Currently everything is based on Osy's work by including 2 different TbtOnPCH patches. One is needed for unpatched Thunderbolt firmware, it contains a full DROM and the Thunderbolt controller will show up as 2x Asus (which si wrong but it still works). The other TbtOnPCH patch is loaded once the firmware is patched, it's pretty much the same but without the DROM inside. With that patch loaded and the firmware patched the Thunderbolt controller shows up as Apple with 1x 40gb/s port, perfectly native but causes sleep and usb issues currently.

Unfortunately I'm no expert when it comes to ACPI so I'm pretty much experimenting and learning as I go but like you said it would be nice if someone who knows this stuff inside out could have a look at these issues as they might be easy fixes when you're good with ACPI and such.

My "ultimate" goal would be an EFI thats a bare bones as possible and provides as close to vanilla experience as possible. As far as those goes I think the only remaining things are this FakePCIID, Thunderbolt and maybe CIR. Maybe the sd card reader too but I use passive cooling on my NUCs so I have no access to that port and the guy who wrote the driver isn't supporting our chipset and as it stands now only certain versions work and the sd card is painfully slow with both reading and writing so I didn't really bother with that much. Also the CIR interface would be nice to get working but I didn't get far with that at all. I do have Apple remotes to test with but I couldn't even make the CIR receive any signals at all in macOS lol.

Other than that I think all there h/w inside the NUC is working as best as it can. I recently changed some frame buffer patch settings to make it run in Apple GOP mode instead of default. Since the graphics in the NUC are mobile based it works great, makes it more vanilla and improves performance a little bit too.

Feel free to clone and submit PR requests to improve and make this OpenCore config better. I think we're very close to a "golden" OpenCore based EFI that others with NUC repo's can use to improve theirs and then hopefully the cycle continues and things only get more optimised and better for everybody hackintoshing the NUC8.

(The NUC8 might be dated but they are pretty cheap now and the Iris graphics are so much better than the UHD in the NUC10. Despite the NUC10 having a faster processor I opted to go for NUC8's instead. They're not that much slower and much cheaper if you shop around. Especially customer returns on Amazon. I picked up an i5 model for 175 euro that had some stuff missing from the box and also had some user marks. An absolute steal for a decently fast 4c/8t processor in a tiny box when you're a bit of a nerd and have disks and ram sticks laying about.)

[zearp]

Thanks for digging up and sharing that info, I'll have to read into it more but as I understand it now it wouldn't be too hard and also not too difficult to test if a custom AppleALC kext with all the correct info does the job. Would be a great way to fix it!

[mackonsti]

If you can read the code and understand what device FakePCIID kext + HDMI_Audio injector does, it would be great @zearp so that we can find what "phantom" digital audio device is injected and check if we can natively map/add it in a custom AppleALC before submitting it for official release to the acidanthera developers.

[zearp]

If I understand correctly it should be a matter of gathering the correct information, create a new entry in the controllers plist and compile AppleALC and try it out. I don't know when I have some time to experiment with this but hopefully somewhere this weekend. Would be awesome to finally get rid of this kext haha.

[zearp]

Unfortunately my plate has been pretty full so I didn't get to testing any of this yet.

[zearp]

I was getting weird panics with FakePCIID loaded in Monterey, so I decided to manually add some PCI devices and to my surprise audio over hdmi started working. I've confirmed on Big Sur this also works and I assume Catalina will be ok too.

So in the end the solution was a lot easier than expected!

[mackonsti]

Hi @zearp can you possibly share with us the idea behind adding compatible devices, please? Which devices did you add and to what components? Graphics or audio? Can you possibly post here some parts of your config.plist please? I would be interested to test myself, too but I do not see a mention or short guide on your main repo page. Thank you!

[mackonsti]

Thanks @zearp but I fail to see how your working section for audio managed to bypass the need for FakePCIID and HDMI_Audio plugin... I am trying to understand here... because I already had something like this in my own configuration in Clover... Allow me to explain (your feedback is welcome!)

PciRoot(0x0)/Pci(0x1F,0x3) is the same location as AAPL,slot-name with value Internal@0,31,3 as 31 is 0x1F so we're not defining some "hidden" or non-existing device; what on earth would a re-definition of AAPL,slot-name do for such an audio device, I wonder?

hda-gfx with onboard-1 was in a way already added with AppleALC kext if you had checked IORegistryExplorer but I also added it manually in my config;

The device_type as Audio device I kind of fail to see the need, as this was mainly part of the exported data from Hackintool and I have no clear understanding if it's cosmetic or plays some role, somewhere;

layout-id with DgAAAA== i.e. ID=14 is not what I use on my NUC8i7; did you use this value for a long time or changed it recently? I have been using ID=1 (decimal) for ages, really, since started using AppleALC.

model string is obviously cosmetic.

So you say that, by removing FakePCIID and the HDMI_Audio injector, you have both analogue and digital audio appearing like before? (with FakePCIID?) Please can you take a screenshot of IORegistryExplorer under HDEF and post the two devices like my image in my earlier post? Do you see 2 distinct audio CODECs i.e. Analogue audio via AppleHDADriver and Digital audio via AppleHDAHDMI_DPDriver ?

Thank you!

[zearp]

I think what answers your question is that adding PCI devices in Clover isn't the same as adding PCI devices in OpenCore. I think thats the crux here and it explains why adding the same kind of properties did not work in Clover but does work in OpenCore. Apples and oranges.

I understand on the surface adding the same properties should give the same results but that would assume Clover and OpenCore use the exact same methods to setup PCI devices. Very unlikely to be true. You'd have to understand exactly how Clover does it and also how OpenCore does it. Something I can't help with because I don't know enough about the inner workings of Clover or OpenCore for that matter.

As for your other questions, I'll try to answer as best as I can but some of them you could've answered yourself. I'm not saying that to be mean or something, it's that I'm pretty busy lately and don't really want to put in too much time in things that are not relevant to me such as Clover stuff. So any answers might take a long time and may be incomplete for your needs. In those cases its always best to DIY and just compare files or even boot up with the EFI from my repo and compare IOreg/etc. Today is a slow day so I'll do my best to give you the info you want.

I've been using the same layout-id for a very long time. Different layout-ids will work fine on the same machines, sometimes with only small differences. On my Dell hacks certain layout-ids break certain in and/or outputs but make auto-sensing work and the other way around. If sound works it works, the layout-id isn't important as long as everything you need works.

The old config section only had one entry setting the layout-id;

Nucintosh/EFI/OC/config.plist

Lines 274 to 278 in 9b3bf88

	<key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
	<dict>
	<key>layout-id</key>
	<data>DgAAAA==</data>
	</dict>

The current section has quite a few more;

Nucintosh/EFI/OC/config.plist

Lines 303 to 315 in 5ee52af

	<key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
	<dict>
	<key>AAPL,slot-name</key>
	<string>Internal@0,31,3</string>
	<key>device_type</key>
	<string>Audio device</string>
	<key>hda-gfx</key>
	<string>onboard-1</string>
	<key>layout-id</key>
	<data>DgAAAA==</data>
	<key>model</key>
	<string>Cannon Point-LP High Definition Audio Controller</string>
	</dict>

Which exact entry did the trick I don't know. It would require a bunch of reboots to find that out. Maybe I'll do that some time but don't count on it in the short term. I'm also interested in knowing but my time is limited and I just want solutions for now. If you must know short term you have to do it yourself.

I wouldn't put much effort in time in Clover anymore if I were you but I understand your need to find out why it works in OpenCore and not in Clover. I wouldn't be able to tell you because I don't use Clover at all. As for OpenCore their documentation provides some info on how they setup the devices. Check out this section: https://dortania.github.io/docs/latest/Configuration.html#x1-270006

The only kext I used was FakePCIID.kext from the official release found here. I did not use any of the other kexts in the release, I've seen others use them but since it worked fine without them I didn't add anything extra. I try to keep the number of kexts needed to a minimum.

Both devices are present in IOreg, I don't know how a screenshot helps you but here you go:

The tl;dr would be that you're using Clover and I use OpenCore which do things in different ways. For me Clover is depreciated at this point in time to be honest. There is also a lot of OpenCore code added to it which makes it a real Frankenstein boot loader not really suitable for the future. OpenCore is the way to go.

Another thing to keep in mind is that your config is very different from mine. I don't use any renames other than whats required for the Thunderbolt/usb-c and IRQ patches. I've browsed your files for a bit and its very different to mine. Maybe nothing there would influence the audio stuff, I don't know. I just know there are many differences in the configs and patches etc. Lots of variables and things to consider on top of everything else.

It may not even be possible to get audio over hdmi to work with Clover without using FakePCIID because the functionality FakePCIID provides simply isn't provided by Clover while it is by OpenCore.

Good luck!

[mackonsti]

Thank you for taking time to reply and post your insight on what you did @zearp it is very appreciated. Apologies if the way my text was put, gave the idea of lacking research in answers (that is not the case) ; indeed Clover and OpenCore probably have differences (I am no developer, either) but your solution provided concrete results that I am eager to try out ASAP (with trial-and-error of course). Allow me to come back with my findings for others to see, hopefully Google will index this page with the right keywords 😄 Cheers mate.