Contribute
Register

An iDiot's Guide To Lilu and its Plug-ins

jaymonkey

Moderator
Joined
Aug 27, 2011
Messages
2,506
Motherboard
ASRock-Z97 EX6
CPU
i7-4790K OC @ 4.8GHz
Graphics
Vega 64LC + HD4600
Mac
MacBook Air, MacBook Pro
Mobile Phone
Android, iOS
350539
An iDiot's Guide To Lilu and its Plug-in's
Last Update: 13th May 2019 (Updated Chapter anchor links)



About this Guide

This guide is written as a helping hand to those users who have some understanding of using legacy hackingtosh methods but are considering using Lilu as a means to migrate to Mojave or using Lilu in place of traditional/legacy MacOS patching methods.

Before we go any further I should state for the record that I have no direct affiliation with Lilu, my first encounter with it was in early 2017 when i needed to resolve an issue with the refresh rate of the 4K display on my laptop. Since then I've followed its development and progress and I now consider Lilu to be one of the most useful tools in the Hackingtosh community toolbox.

To make it easer to navigate I have split this guide in to different chapters :-
Click on the above links to jump directly to the appropriate chapter in the guide.



Chapter-1: What is Lilu ?

Lilu is a MacOS "Patching Engine " that allows for on-the-fly patching of the kernel and system extensions, Lilu offers a number of benefits over more traditional hackingtosh methods, in summary these are :-
  • Does not depend on a bootloader
  • Works in Recovery mode and the MacOS Installer
  • Supports a symbolic patching engine
  • Enables API access to the kernel and system extensions
  • Allows modification of running processes
Lilu has been around for a few years and much like when Clover first appeared on the scene it has taken a while for it to become mature and stable enough for mainstream use. On its own Lilu does nothing, it needs to be used with plug-in's.

Lilu has its own SDK meaning that anyone with the right skills can write a plug-in, as such it has gained a following of dedicated developers and users and has become the preferred 'Patching Engine' for many Hackingtosh gurus.

The three most popular Lilu plug-in's are WhateverGreen, AppleALC and AirportBrcmFixup and each of these have their own dedicated chapters in this guide, for a for a full list of all the available Lilu plug-in's and where to get them you can use this link.

Important Note: Lilu plug-in's are fully self contained solutions and will (in most cases) replace all legacy Clover patches and Injection/Enabler kext's for a plug-in's given purpose, as such you should remove any existing Clover patches and kext's that have been already installed for a plug-in's purpose ... for example when installing AppleALC you should remove (or disable) all Clover AppleHDA patches and uninstall any HDA Enabler, patching or dummy kext's. Failure to remove associated patches and kext's can result in unpredictable and often unstable results.

Each Lilu plugin has its own documentation and linked support threads that are usually detailed in the readme.md file or the Wiki on a plug-in's Git-Hub project page. You should familiarise yourself with these resources as they list the best places to get more specific help.

Binary releases of Lilu and plug-in's are downloaded by visiting the appropriate Git-Hub project and clicking on the Releases tab, you'll be shown the release history with the most recent version available at the top of page. Most users should download the latest Release version, in some rare cases you may need to download the Debug version or an earlier release.

In some very rare cases you may need to download Lilu's or a plug-in's source code and compile it yourself using Xcode, this will only need to be done when a specific fix or support for a new device has been added to the project and a public binary release is not yet available. When compiling a Plug-in you will need to copy the latest Debug version of Lilu into the project resources folder as all plugins need to be compiled against Lilu's API.

Lilu and its plug-in's can be used on any Hackingtosh system running MacOS Sierra or later and is recommended for MacOS Mojave.



Chapter-2: Hackintool

Hacktool.png

We're going to be using Hackintool (formally called Intel FB-Patcher) a lot in this guide which is written and maintained by @headkaze. Hackintool is powerful post install utility that everyone should have in their hackingtosh tool box. It can help with many aspects of configuring and checking MacOS including debugging iMessage, PCI device spoofing, USB patching, kext maintenance and generating device patches. In this guide we will only use a few of its many features but i recommend that everyone install it and explore its capabilities.

If you don't already have Hackintool installed , download it now using this direct link, unzip and install it as you would any other application. For more info on Hackintool including a change log see this post.

@headkaze is constantly improving Hackintool with a new releases being pushed out weekly so always be sure to check for updates using the apps built-in "Check For Updates" feature.

Screenshot 2019-05-15 at 17.53.01.png



Chapter-3: How to Install Lilu & Plug-in's

Lilu and it's plug-in's are provided as MacOS kext's and should all be installed in /Library/Extensions folder, you may read in some of the support threads of people installing everything in Clovers Kexts/Other folder but this should only be done for testing or development purposes. Installing them in /Library/Extensions will ensure that they are cached by the kernel and available to MacOS, this is the preferred and Apple endorsed location for all 3rd party MacOS kext's including FakeSMC. For a more detailed explanation of why we should install kexts in /Library/Extensions and not use Clover to Inject all the kexts see this guide.

Note: You should also have FakeSMC installed in Clovers Kexts/Other folder so that clover can inject FakeSMC if you need to boot the installer or MacOS recovery, this is the only kext you really need in Clovers Kexts/Other folder all other 3rd party kext's should be installed in /Library/Extensions.

You can download Lilu and the Plug-in's you need using the following links :-
Each link will take you to the appropriate Git-Hub page, click on "Releases" on the main page and download the latest release version, unzip each archive and copy all of the kexts into one place.

First we need to make sure that MacOS is allowed to load unsigned kexts/drivers by setting BooterConfig and CsrActiveConfig in Clover RTVariables section to the following values :-

Code:
<key>RtVariables</key>
    <dict>
        <key>BooterConfig</key>
        <string>0x28</string>
        <key>CsrActiveConfig</key>
        <string>0x67</string>
        .
        .
        .
    </dict>

You can also use the RTVariables section of Clover Configurator to achieve the same result :-

386314


The easiest method of installing kexts into /L/E is to use Hackintool which can do the job with just a few clicks.

Tip: If you have a lot of kexts to install then first copy them all to a common folder (if not already).

Run Hackintool, click on the "Tools" icon on the upper in-app menu and then on "Install Kexts(s)" on the lower menu

Hackingtool-kextinstall.png
Navigate to the folder you want to install the kext(s) from and select (CMD-Click) the ones you want to install so that they have a blue highlight then click on "Select".

Hackingtool-kextinstall-select.png
Hackintool will now install the selected kexts into /L/E, repair all kext permissions and rebuild the kext caches :-

Hackingtool-kextinstall-progress.png
Once it's finished you should see something like the following :-

Hackingtool=kextinstall-finished.png
Thats it .. job done ... don't worry that the output is red .. thats completely normal.

For more information on installing kexts and why we use /L/E see my How to Install Kexts Guide which includes two other methods to install kexts into /L/E if you don't want to use hackintool for some reason or in the very rare cases where it may not work for you.



Chapter-4: WhatEverGreen

When it was first released in 2017 WhatEverGreen only supported AMD GPU's, other GPU types such as Nvidia and Intel IGPU's along with some other display related patches where supported by Lilu using separate specific plug-ins. However, as of mid 2019 WhatEverGreen merges the existing AMD GPU Support with all of the following plugins:-
As such WhatEverGreen (WEG) is now the one-stop solution for all GPU/IGPU and Display related MacOS patching.

Important: It should be noted that as of July 2019 all of the above plug-in's are depreciated and are no longer supported. Use of them in conjunction with WhatEverGreen or the current version of Lilu could result in Kernel Panics or abnormal MacOS behaviour.

For AMD and Nvidia users, WhatEverGreen contains a number of default fixes and patches such as the common black screen on boot up issue and simply installing WhatEverGreen should be enough to enable the dGPU and get things working, for more experienced users there are a number of optional boot arguments that can be used with AMD and Nvidia GPU's which are detailed in the WhatEverGreen readme.md and manual.

For IGPU only or mixed GPU (dGPU + IGPU) systems, WhatEverGreen offers us a quick and easy method of enabling and customising the IGPU for MacOS than the traditional legacy methods of using Clover or customised Intel IGPU driver and framebuffer kext's.

Important: If you have a laptop with dual GPU's (dGPU + IGPU) with switched graphics, IE the dGPU is routed through the IGPU then you must disable the dGPU first before continuing, see RehabMans guide for more info.

Prerequisites

First install the latest versions of Lilu and WhatEverGreen in to /L/E (see the How to Install section towards the top of this guide) and reboot your computer.

Installing WhatEverGreen should take care of renaming all of the required ACPI identities for us so if you have any of the following Clover ACPI Fixes/Renames in your config.plist you should remove or disable them:-
  • Change/Rename GFX0 to IGPU
  • Change/Rename PEG0 to GFX0
  • Change/Rename HECI to IMEI
The above Clover ACPI Fixes/Renames use a global/generic method of renaming the ACPI identities in the DSDT that can cause problems for us later on. WhatEverGreen finds the DSDT code that requires new ACPI identities using more specific device identifiers and thus does a much better job.

Note: There is one exception to the above rule, if you have a laptop and are using @rehabmans old method to enable the backlight control (using ACPIBacklight.kext or IntelBacklight.kext) then you should keep the Change/Rename GFX0 to IGPU ACPI fix in place otherwise the code in the hot-patch SSDT-PNLF.aml will not work correctly. However you should really consider using his newer method and be aware that the AppleBacklightFixup kext used in the newer method is now depreciated as its functionality is now included in WhatEverGreen.

WhatEverGreen Configuration

WhatEverGreen is configured using Device Properties, this is a relatively new method of defining custom properties in a devices ioreg directory tree using Clover and was added specifically at the request of the Lilu developers who work closely with the Clover developers.

For a bit more information on Device Properties see this post in the Clover dev blog.

A Device Property is defined in Clover's config.plist Devices -> Properties section, a property consists of a name and a data value assigned against a device's PCI path. Both the PCI path and the property name(s) are defined as <key> types, the value of a property is defined as one of three types:-
  • As a <data> type
  • As a <number> type
  • As a <string> type
You can add Device Properties by directly editing your config.plist file using a code or text editor or you can use a plist editor such as Xcode or PlistEdit-Pro. Clover Configurator now also supports adding/editing Device Properties directly. I personally recommend using a code editor ( I use BBEdit) as it means you can cut and paste the code generated by the methods in this guide directly in to your config.plist and will avoid having to do any value conversions which will be required if you use a Plist editor, Xcode or Clover Configurator.

IGPU Device Properties

All IGPU patching is done in Hackintool's Patch mode which is the second icon on the top in-app menu and we use the bottom bar menu to select the Patch mode's sub-function. Click on Patch and then select the Info sub-function.
Hackingtool_V242_Check_PID.png
Note-1: If Hackintool correctly identifies your CPU Generation but the PlatformID drop down menu is empty and the Framebuffer and Connector sub-functions show no data then you should click on "FrameBuffer" in Hackintool's top menu and select the MacOS version you are using.

Hackingtool_V242_Top_Menu_FrameBUffer.png

Note-2: If Hackintool is unable to identify your CPU Generation automatically and/or you see ??? in the Current Framebuffer Info box or Hackintool incorrectly selects the wrong generation of CPU then you can manually select the correct CPU Generation using the dropdown menu :-
Hackingtool_V242_No_CPU_Gen.png

The first time you run Hackigtool it will attempt to detect your IGPU and select the default PlatformID for it, in many cases this will be wrong so the fist thing we need to do is select the correct one.

With the Info sub-function selected, the type of IGPU detected will be displayed in the lower Current Framebuffer Info box and details of the the selected PlatformID and any matching System Definitions (SMBIOS) will be displayed in the upper Selected Framebuffer Info box.

For example the first time I run Hackintool on my 2017 HP Spectre X360 laptop Hackintool selects 0x591B0000 as the PlatformID and suggests MacBookPro 14,3 as the System Definition (SMBIOS).
Hackingtool_V242_Wrong_PID.png
This shows conflicting information, the IGPU is correctly detected and displayed as a HD 620 IGPU in the Current Framebuffer Info box but the Selected Framebuffer Info box shows that 0x591B0000 is for a HD 630 IGPU so we know that PlatformID 0x591B0000 is incorrect, we can change this by using the PlatformID dropdown menu to select the correct one, if you don't already know the PlatformID you need then select each one in turn from the drop down menu until you find one that matches your IGPU type.

If you are configuring a Laptop then make sure you select a Mobile PlatformID (Mobile = Yes), if you are configuring a desktop system then make sure Mobile = No.

For my HP Spectre X360 laptop I already know that I need 0x59160000 so i select it using the dropdown menu.
Hackingtool_V242_PID_OK.png
We can now see that the IGPU type in the Selected Framebuffer Info box matches the IGPU type in the Current Framebuffer Info box which in the case of my HP Spectre X360 laptop is a Mobile HD 620 IGPU, and that the recommended System Definition (SMBIOS) is MacBookPro 14,2 ... I am already using the MacBookPro 14,1 SMBIOS which is close enough.

Pro Tip: Another good way to help you choose or confirm which PlatformID to use is to look at this post by @headkaze which lists details of all the available PlatformID's / FrameBuffers available in MacOS, sorted in to sub-lists in CPU generation order, for example if you have a Coffee lake CPU then scroll all the way down down to the Coffee Lake CPU section, at the top of each sub-list is a summary of all the PlatformID's that shows if they are for Mobile or Desktop systems, it also identifies which PlatformID's "Headless" (0 Connectors) which we will cover later in this guide :-

CFL-Platform'id's.png

You can get the specific details of each PlatformID by scrolling down further, for example the specific details of PlatformID 0x3E9B0000 are :-

CFL-PlatfromID-Specfics.png

From this we can see that this PlatformID is used with SMBIOS MacBookPro 15,1 and that it is for an Intel UHD 630 IGPU, Hackintool will also give you this information but sometimes it's easer to see and compare the data in list form rather than in an App.

Special note on Solo HD 4600: If you have a Haswell CPU with a HD 4600 IGPU and no dGPU and your Motherboard has two HDMI ports then you may want to try using PlatformID 0x0D220003 and SMBIOS iMac14,2. I have a system with this configuration and could not get its working properly by using the normal HD 4600 PlatformID of 0x04160000 after some trail and error I found that the PlatformID of 0x0D220003 (Iris Pro Graphics 5200) worked very well. I can't really explain the reasons why but it could be down to the Motherboard (Gigabyte H87N-WiFi) BIOS.

Important: Always use the correct System Definition (SMBIOS) for the selected PlatformID, Hackintool will in many cases display the recommended SMBIOS in the Upper Selected Framebuffer Info box. Use of a non matching PlatformID and System Definition (SMBIOS) can result in abnormal MacOS behaviour.

Note: There are a few PlatformID's where Hackintool will not list any recommend System Definitions (SMBIOS) or show "Unknown" next to "Model(s)" in the upper Selected Framebuffer Info box, this means that there are no matching Mac Models using that combination of CPU, IGPU & PlatformID however the IGPU PlatformID is still valid and should work, however if possible I recommend selecting an alternative PlatformID that has a framebuffer that matches your IGPU and also has a recommended/matching System Definition (SMBIOS) if at all possible.
Hackingtool_V242_No_SMBIOS.png Hackingtool_V242_Matching_SMBIOS.png
If you can't find a PlatformID that matches your IGPU with a recommended System Definition (SMBIOS) it does not mean that things wont work, it just means that you'll have to take your best guess at finding the nearest matching SMBIOS to your Hackintosh hardware, a good tool that can help you make this decision is MacTracker.

Note: If you need to change your SMBIOS then be sure to logout of all of Apple's on-line services such as iCloud and use the methods detailed in An iDiot's Guide To iMessage to set new system ID's and check the serial number is valid but unregistered.



Headless PlatformID's

Another reason that desktop users with dual (dGPU + IGPU) systems will want to over-ride Hackingtoo'sl suggested PlatformID is if you want to use your IGPU in Headless mode.

Genuine desktop Mac's with dual GPU configurations such as most iMacs and some Mac Mini systems use a Headless PlatformID to inform MacOS that the IGPU does not have any physical display connectors but it is still available to MacOS for IGPU hardware accelerated features. When a IGPU is configured as Headless MacOS uses it as a sort of GPU co-processor for features such Airplay Display Mirroring and Photo/Video Encoding/Decoding (Intel Quick Sync - IQS), this is an important feature of MacOS so if you have a dGPU as well as a supported IGPU then you should configure the IGPU as Headless.

Note: Systems with workstation class CPU's (Intel Xeon) do not have a IGPU as such you should not attempt to set a Headless PlatformID.

If you don't need to use a Headless configuration, you can skip down to the next section of the guide titled WEG Configuration Continued.

Headless IGPU Configuration

If your primary display adaptor is a dGPU such as Nvidia or AMD and you have a supported IGPU then using a headless PlatformID will allow your Hackingtosh system to be more stable and behave much more like a genuine Mac with access to IGPU hardware accelerated features.. Use of this mode requires that the IGPU is enabled in your BIOS and that the dGPU is set as the primary display adaptor, you must also use the correct Mac System Definition (SMBIOS) that supports dual GPU configurations and matches your CPU & IGPU type.

Recommended desktop System Definitions (SMBIOS) for headless PlatformID's are :-
  • Coffee & Kaby Lake CPU = SysDef: imac18,x
  • SkyLake CPU = SysDef: imac17,x
  • Haswell CPU SysDef: imac14,x or imac15,x
  • Ivy Bridge CPU SysDef: imac13,x or macmini6,x
  • Sandy Bridge CPU = SysDef: imac12,x or macmini5,x
Note: If your CPU, IGPU and selected headless PlatformID match a known Mac Configuration Hackintool will display the recommended System Definition(s) (SMBIOS) in the lower Selected Framebuffer Info box.

Currently known Headless PlatformID's are :-
  • Coffee Lake CPU - Only for MacOS 10.13.6 (17G2112+) and 10.14.X
    • UHD-630 IGPU = 0x3E920003 or 0x3E910003 or 0x3E980003
  • Kaby Lake CPU
    • HD-630 IGPU = 0x59120003
    • Unknown = 0x59180002 (not recommended)
  • SkyLake CPU
    • HD-510 IGPU = 0x19020001
    • GT2f IGPU = 0x19170001
    • HD-530 IGPU = 0x19120001
    • Iris Pro 580 = 0x19320001
  • Haswell CPU
    • HD-4600 IGPU = 0x04120004 or 0x0412000B
  • Ivy Bridge CPU
    • HD-4000 IGPU = 0x01620006 or 0x01620007
  • Sandy Bridge CP
    • HD-3000 IGPU = 0x00030030
You can confirm that a selected PlatformID is Headless in Hackintool by clicking on the Connectors sub-function, all entries should have the following values:-
  • index = -1
  • bus id = 0x00
  • pipe = 0
  • type = dummy
Additionally you should also see a 'Headless' Icon

Example using the Haswell headless PlatformID of 0x0412000B
Hackingtool_V242_Headless.png
Note-1: Headless IGPU mode only works well on dual GPU (dGPU + IGPU) desktop systems, it will not work on dual GPU laptops where both GPU's output to the same display panel, as such you should always disable the dGPU, see RehabMans guide for more info.

Note-2: As already stated, use of a headless PlatformID is only guaranteed to work when used in-conjunction with one of the recommended Mac System Definitions (SMBIOS), use of other System Definitions may result in an unstable system.

Note-3: When using a headless PlatformID the IGPU will no longer show up in System Information even though it is enabled in your BIOS, this is normal and is one way of confirming that the headless IGPU mode is activated.

Note-4: If your system is equipped with one or more working Thunderbolt 3 port(s) that you want to use to drive a display via an adapter and you have dGPU + Headless IGPU then you will need to enable the "Above 4G Decoding" option in your motherboards BIOS.

Note-5: If after configuring your IGPU as headless and you want to check everything is correct then use IORegistryExplorer and search for "IGPU", you should see the IGPU entry with the property AAPL, ig-platform-id set to the headless PlatformID (in reverse byte order) and a matching model description :-

370429

Note-6: You can use the attached VDADecoderChecker App to confirm that your IGPU is configured correctly for hardware video decoding. Sandy Bridge CPU's and above will support hardware H.264 encode and decode, if you have Kaby Lake or later then you will also have hardware support for HEVC (H.265).

Note-7: There is now no need to use the VDADecoderChecker app detailed in Note-6 above as newer versions of Hackintool will automatically test your IGPU and display the results in the GPU Info box on the Info -> System page, allowing you to confirm that your IGPU is configured correctly and that QE/CI, Metal and VDA Decoder are all working :-
Hackingtool_V242_Headless_QI-CE_ME_VDA.png


WEG configuration Continued

You can click through the other sub-functions in Hackintool's Patch mode to view the currently selected framebuffer settings and change any if needed. Most users wont need to change anything at this point but if you are curious about the settings WhatEverGreen uses for a particular PlatformID take a look at post#2 of the WEG guide.

When everything is how you want it, click on the Patch sub-function and select the Advanced sub-page, Check Spoof Video Device and select the correct IGPU device id in the dropdown menu next to it :-
Hackingtool_V242_Patch_Adavnced.png
Next click on the General sub-page and select Devices / Properties and check Graphic Device, deselect everything else for the time being. Now click on the Generate Patch button. In most cases WhatEverGreen only needs AAPL,ig-platform-id (or AAPL,snb-platform-id on Sandy Bridge systems) to be injected as a Device Property in order to correctly configure the IGPU. The additional properties are optional but useful to help identify the IGPU correctly. In the following example I've run Hackintool on my 2017 HP Spectre X360 laptop which has an Intel HD-620 IGPU and is using a "PlatformID"of "0x59160000".
Hackingtool_V242_Patch_General.png
You can now copy and paste the patch code snippet into your config.plist taking care to keep the correct structure, you only need to copy the <Key> and its <dict> block of code (which ends with </dict>).. using the above example I would highlight and copy :-
Hackingtool_V242_Patch_IGPU_Select.png
You then need mount your EFI partition and open your config.plist in a code editor (I use BBEDIT) and then paste the code into the Devices -> Properties section of you config.plist ... using the above example this is what it would look in my config.plist.

Code:
<key>Devices</key>
    <dict>
        <key>Properties</key>
        <dict>   <<----- Insert Patch code from Hackintool after this

            <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
            <dict>
                <key>AAPL,ig-platform-id</key>
                <data>
                AAAWWQ==
                </data>
                <key>AAPL,slot-name</key>
                <string>Internal</string>
                <key>device-id</key>
                <data>
                FlkAAA==
                </data>
                <key>device_type</key>
                <string>VGA compatible controller</string>
                <key>framebuffer-patch-enable</key>
                <data>
                AQAAAA==
                </data>
                <key>model</key>
                <string>HD Graphics 620</string>
            </dict>

        </dict>
    </dict>

Note-1: This is only an example to show the correct structure, your config.plist will include likely additional lines of existing code.

Note-2: If you are editing a fresh config.plist is possible that you may not have the <key>Properties</key> section below <key>Devices</key> if this is the case you should first insert :-
Code:
        <key>Properties</key>
        <dict>


        </dict>

And the insert the generated code from Hackintool's patch generator between <dict> and </dict>

Copying the patch code from Hackintool's code generator and pasting it into your config.plist is in my opinion the easiest and most reliable method. However you can if you want use a Plist editor, Xcode or even Clover Configurator to add the properties but you will need to enter each property and its value one at a time making it more time consuming and prone to errors.

Note-2: The data values generated by Hackintool are base-64 encoded, if you use a Plist Editor or Clover Configurator to edit your config.plist then you will need to convert the base64 values into Hex and some values such as AAPL,platform-id and device-id will need to be entered in Reverse Byte Order (without the leading "0x") you can use Hackintool's calculator function to do the conversion.

Note-3: On Sandy Bridge systems the name of the Device Property will be AAPL,snb-platform-id (not AAPL,ig-platform-id)

Here is an example of adding the above AAPL,ig-platform-id and device-id properties using PlistEdit-Pro :-

350507

Alternatively you can use Clover Configurator :-
  1. Open Clover Configurator and load your config.plist and select the Devices section
  2. Towards the bottom of page you will see two tab buttons labelled Arbitrary and Properties
  3. Click on the Properties button
  4. Click on the "+" icon under the left panel
  5. Copy and paste the PCI path <key> value (starts with PciRoot) from the generated patch code into the "Devices" field
  6. Click on the "+" icon under the right panel
  7. Type in "AAPL, ig-platform-id" (AAPL,snb-platform-id for Snady Bridge) into the "Properties Key" field
  8. Type in the value into the "Properties Value" (see Note-2 below)
  9. Repeat steps 7 + 8 for device-id.
This is what the Device Properties look like for the just AAPL,ig-platform-id and device-id Clover Configurator :-

350108
Note-1: When using Clover Configurator we define the PCI path of the IGPU in the left panel and the name and data value of each Device Property in the right panel.

Note-2: The value for AAPL, ig-platform-id is entered (and displayed) in hex Reverse Byte Order without the leading "0x" so for the above example of "0x59160000" the correct value is "00001659", and the device-id value would be "16590000" you can use Hackintool's calculator function to do the conversion if your not sure.

Important: All other Clover options for IGPU enabling and spoofing should be left blank/empty in the "Devices" section of your config.plist file.

For most users the Device Properties generated by Hackintool should be enough for WhatEverGreen to correctly configure your IGPU, however on some systems it may be necessary to further modify the framebuffer defaults in oder to get all of the IGPU ports/connectors working correctly. For example you may need change a IGPU port connector from DVI to Display Port, you can use Hackintool to modify these more advanced settings and then generate updated patch code to add as additional Device Properties to your config.plist.

I wont cover these more advanced settings in this guide as they are already covered in CaseySJ's excellent guide which covers the topic in more detail :-


Important: Remove all options in the "Graphics" section of your config.plist such as Inject Intel, ig-platform-id ... etc :-

350109

In most cases you should also remove any DSDT edits or SSDT Hot Patches associated with the IGPU, as all ACPI patching should be taken care of by WhatEverGreen as long as your have defined the IGPU Device Properties correctly.

4K Displays

If you have a 4K display or video panel connected to the IGPU like i do on my laptop then you will need to add -cdfon as a MacOS boot argument, this enables WhatEverGreen's pixel-clock patches (that used to be handled by the now depreciated CoreDisplayFixUp plug-in) and allows for higher display resolutions and refresh rates on High-DPI display panels.

366999
You can also add the -cdfon argument using Clover Configurator :-

Clover-Configurator-CDFON.png

I also recommend increasing the IGPU's VRAM from the default value of 1536MB to the 2048MB maximum. If you already have the property <key> framebuffer-patch-enable in the device properties section of your config.plist then you just need to add :-

Code:
                <key>framebuffer-unifiedmem</key>
                <data>
                AAAAgA==
                </data>

If you don't already have the property <key> framebuffer-patch-enable in the device properties section of your config.plist then you need to add :-

Code:
                <key>framebuffer-patch-enable</key>
                <data>
                AQAAAA==
                </data>
                <key>framebuffer-unifiedmem</key>
                <data>
                AAAAgA==
                </data>

Note: Increasing VRAM to 2048MB on systems that are connected to a single 1080P display or when using a Headless PlatformID will have no beneficial effect.

For those users who want to use a Plist editor to add the 2048MB VRAM patch here is an example screen shot of PlistEdit Pro with just the basic PlatformID device properties and the VRAM patch defined, you can also see the raw patch code in the lower red box :-

366997
And this is how it looks in Clover Configurator :-

366998

Testing your Changes

Once you have made all the changes necessary to your Config.plist, save it and reboot, if you've followed the guide correctly your IGPU should now be working. If you encounter problems check that you have installed the Kexts correctly as detailed in the How to Install section of this Guide. Another very common mistake is that the value for the Device Property AAPL,ig-platform-id (or AAPL,snb-platform-id on Sandy Bridge systems) has been entered incorrectly.

Once you have completed installing and configuring WhatEverGreen, re-run Hackintool and check the Info -> System -> GPU Info section which will display the configured IGPU details and that hardware acceleration for QE/CI, Metal and VDA decoder are all enabled/supported :-
Hackingtool_V242_HD620_QE-CI-ME-VDA.png
It's also advisable to check/test that WhatEverGreen has renamed the HECI device in your DSDT as IMEI and that it is active in the ioreg, run the following command in terminal :-

Code:
ioreg | grep IMEI

Terminal should report the IMEI device path and the status, here is an example :-

Code:
    | |   +-o IMEI@16  <class IOPCIDevice, id 0x100000264, registered, matched, active, busy 0 (36 ms), retain 11>

As stated in the prerequisites section of this guide, WhatEverGreen should take care of sorting out the IMEI (Intel Management Engine Interface) , however in some very rare cases it appears that it can fail. If you get an error when performing the above test then use the Clover HECI -> IMEI Rename/Fix.

Code:
                <dict>
                    <key>Comment</key>
                    <string>change HECI to IMEI</string>
                    <key>Disabled</key>
                    <false/>
                    <key>Find</key>
                    <data>
                    SEVDSQ==
                    </data>
                    <key>Replace</key>
                    <data>
                    SU1FSQ==
                    </data>
                </dict>

You can also use Clover Configurator to enable the HECI -> IMEI Rename/Fix.

382970

DRM Content - Video Playback Fails / Black Screen

Playback of DRM content on non Mac Hardware can be very difficult to resolve, I'm no expert on the subject but I've added what info and knowledge I have on the subject below which may be of help.

Warning: As far as I know DRM playback on newer (Kaby Lake +) solo IGPU systems running Mojave is likely to be the most problematic and according to the official WhatEverGreen support thread unlikely to work until the developers have found a workaround and updated WhatEverGreen's "Shki" module.

DRM Support in WhatEverGreen

WhatEverGreen includes all the code from the now depreciated "Shiki" plug-in which is responsible for enabling DRM protected content playback on Hackingtosh systems. In most instances that I've been able to test, WhetEverGreen automatically configures "Shiki" with the correct parameters based on the detected CPU/GPU.

However it's been reported by a number of users here at TMx86 and other forums that WhatEverGreen does not always get things right and fails to configure "Shiki" with the correct parameters which can result in a black screen when playing back DRM protected content. If you find you are unable to play DRM content in iTunes or NetFlix in a Web Browser then try adding shikigva=1 as a MacOS boot argument in your Clover config.plist.

This will ensure that WhatEverGreen configures "Shiki" to use the hardware renderer of a GPU for DRM playback, the value for the shikigva= boot argument is made up by adding the following 8 BIT values together :-

001 = Force Hardware Online Renderer
002 = Allow Non BGRA
004 = Force Compatible Online Renderer
008 = Add Executable Whitelist
016 = Disabled Unused
032 = Replace Board ID
064 = Unlock FP10 Streaming

If after adding shikigva=1 (001 = Force Hardware Online Renderer) as a boot argument and re-booting you are still unable to play DRM protected content, then try changing the boot argument to shikigva=57 (001 + 008 + 016 +032) reboot your PC, and test DRM content again.

When using shikigva=1 or shikigva=57 MacOS should automatically select the most appropriate hardware renderer to use based on the detected/configured hardware. However if necessary you can manually configure MacOS to use a preferred GPU for DRM playback by using one of the following terminal commands :-

Force MacOS to use Intel IGPU :-
Code:
defaults write com.apple.AppleGVA forceIntel -boolean yes

Force MacOS to use AMD/ATI dGPU :-
Code:
defaults write com.apple.AppleGVA forceATI -boolean yes

Force MacOS to use Nvidia dGPU :-
Code:
defaults write com.apple.AppleGVA forceNV -boolean yes

If after trying shikigva=1 and shikigva=57 you still cant play DRM content then you could try shikigva=60 (004 + 008 + 016 + 032) which will force MacOS to use an alternate/compatible DRM renderer method.

If necessary you can reset the MacOs DRM configuration back to defaults with the following terminal commands :-
Code:
defaults delete com.apple.coremedia
defaults delete com.apple.AppleGVA
sudo rm -rf /Users/Shared/SC\ Info
sudo defaults delete com.apple.coremedia
sudo defaults delete com.apple.AppleGVA

Once you have entered the above commands, reset your PC and try again.

I'm still trying to nail down DRM issues so if you found a section that works for you please post your stories below, so we can help others and improve the above info.



Chapter-5: AppleALC

AppleALC is a plug-in for Lilu that dynamically patches the AppleHDA kext to enable High Definition Audio (HDA) support on non-native audio codec's. Like WhatEverGreen it replaces many of the patches and kext's that we have traditionally used to enable Audio in MacOS, as such you must remove all existing AppleHDA enablers, patches, dummy kext's, DSDT Edits ... etc and ensure you have a vanilla AppleHDA kext before installing AppleALC.

Nvidia HDMI Audio

AppleALC can enable HDMI audio on most Nvidia GPU's and all you need to do is install Lilu + AppleALC (see the How to Install section towards the top of this guide), if you have a supported card AppleALC will detect it and enable the HDMI audio controller. To see a list of supported Nvidia devices see this page, the Nvidia devices are at the bottom of the list.

On-Board Audio Codec support

AppleALC supports many different built-in (on-board) Audio codecs from Realtek (ALC), Conexant, IDT and others, in most cases all we need to do is install Lilu + AppleALC and make a simple configuration change to the config.plist but before we do that you should understand how AppleALC works.

Understanding how AppleALC works

AppleALC works a bit different to traditionally pre-patched or dummy kext AppleHDA solutions, the best way to think of AppleALC is as a large database of codec connector, layout and platform patches. Upon loading, Lilu/AppleALC will automatically detect the type of audio codec you have and will dynamically apply a set of codec patches from its database to AppleHDA.

The patch set that AppleALC will use is defined by using an index identifier. For backwards compatibility (and terminology) the patch set index identifier is the value of a property called "layout-id" which has traditionally been used in the hackingtosh world to select a layout in a pre-patched version of AppleHDA (or dummy HDA kext).

Lilu & AppleALC interactions

When Lilu loads it finds the value of "layout-id" and passes it to AppleALC which creates a new Device Property called "alc-layout-id" that inherits this value. AppleALC then sets the value of "layout-id" to a new target ID (usually 7) and patches the target layout in AppleHDA (using Lilu's patching engine) with the connector info, platform and layout files required for your codec (indexed by the value of "alc-layout-id").

This method allows AppleALC to negate the dropped layout-id's in Mojave (see the Audio section of this post for more info ) as the injected value of "layout-id" is only used as an index in AppleALC's codec patch database. It should be noted that AppleALC will use this layout-id re-mapping scheme on all versions of MacOS not just Mojave.

Check Supported Codecs

To see if AppleALC supports your codec look for its name in the source code's Resources folder. If your codec is not supported then you can ask for it be included in the next version by posting on the official AppleALC help thread. Create a post with the details of your codec (see post #1 in the help thread) ). One of the guru's there should see your post and offer to help, you will probably need to generate a codec dump in linux, I'm not going to cover that here as its out of the scope of this guide but whoever picks up your post and offers to help will give you a link on how to do this.

If your codec is already supported by AppleALC you can check which layout's are supported by opening the info.plist file within the appropriate codec folder, from the code you can see which layout id's are available, the comments may give you a clue as to which one to use,

As an example my 2017 HP Spectre X360 laptop has a Realtek ALC295 codec, so i open the info.plist within the ALC295 sub folder :-

359220

In this example I know that Mirone's patch set is the one I need which is layout 3, in your instance read each of the comments to see a layout description matches your system, if your not sure make a list of all of the available layout-id values and try each one in turn until you find one that works. You can also use Hackintool to see which layouts are supported (detailed in Method 2 below).

AppleALC Configuration

First install the latest versions of Lilu and AppleALC in to /L/E (see the How to Install section towards the top of this guide), now all you need to do is to configure AppleALC with the layout-id you want to use, there are two methods you can use to do this.

Method 1 (Legacy Clover value)

Lilu supports querying Clover for the value of "layout-id" from the legacy parameter "Clover/Devices/Audio/Inject" in your config.plist so all you need to do is to set the string value of "Inject" to the correct layout id for your codec.

Example using layout 3 :-

Code:
    <key>Devices</key>
    <dict>
        <key>Audio</key>
        <dict>
            <key>AFGLowPowerState</key>
            <true/>
            <key>Inject</key>
            <string>3</string>
            <key>ResetHDA</key>
            <true/>
        </dict>

If you use Clover Configurator then the setting is in the Devices Section

350199

It should be noted that it's quite likely that Lilu will drop this legacy method of reading the value of "layout-id" from "Clover/Devices/Audio/Inject" at some point in the future, so you may be better of using the second method which uses Device Properties and brings AppleALC configuration in-line with other Lilu plug-in's such as WhatEverGreen.

If you don't know what Device Properties are see the "Configuration" section of the WhatEverGreen part of this guide above.

Method-2 (Device Properties) - Recommended

After installing AppleALC + Lilu reboot and edit your config.plist and set the string value of "Clover/Devices/Audio/Inject" to "No" and define "layout-id" as a custom Device Property. You can now use Hackintool to generate the Audio Device Property code for you by clicking on the Audio icon, you should now see the detected Codec type(s), select the HDA codec by clicking on the line entry, the devices info should now be detailed in the Audio Info box and a drop down menu where you can select the codec layout you want to use, the drop down menu will only contain the valid layout-id's that are applicable to the detected codec.
Hackingtool_V242_Audio_Select_Layout.png
Once you have made your selection, click on the Patch icon and select the Patch sub-function, if you want your Audio device to have the correct name and show up in the PCI devices section of System Information then check the Spoof Audio option on the Advanced options (un-check everything else on the Advanced page)
Hackingtool_V242_Patch_Audio_Advanced.png
Now click on General and uncheck everything except for Device / Properties and the Audio Device options, then click on Generate Patch.
Hackingtool_V242_Audio_patch_gen.png
You can now copy and paste the code from the Hackintool code generator straight into your config.plist making sure you keep the <dict> structure correct you only need to highlight the PCI <key> and the <dict> block below it :-
Hackingtool_V242_Audio_Patch_Select.png
And here is what it looks like once pasted in to my config.plist :-

Code:
    <key>Devices</key>
    <dict>
        <key>Properties</key>
        <dict>   <---- Insert code generated by Hackintool after this

            <key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
            <dict>
                <key>AAPL,slot-name</key>
                <string>Internal</string>
                <key>device-id</key>
                <data>
                cKEAAA==
                </data>
                <key>device_type</key>
                <string>Audio device</string>
                <key>layout-id</key>
                <data>
                AwAAAA==
                </data>
                <key>model</key>
                <string>Sunrise Point-LP HD Audio</string>
            </dict>

        </dict>
    </dict>

Note-1: If you are editing a fresh config.plist is possible that you may not have the <key>Properties</key> section below <key>Devices</key> if this is the case you should first insert :-

Code:
        <key>Properties</key>
        <dict>


        </dict>

And the insert the generated code from Hackintool's patch generator between <dict> and </dict>.

Note-2: This is only an example to show the correct structure, your config.plist will likely include additional lines of existing code.

For those wanting to use a Plist editor here is an example of adding the layout-id 3 Device Property using PlistEdit-Pro :-

360780
Alternatively you can use Clover Configurator :-
  1. Open Clover Configurator and load your config.plist and select the Devices section
  2. Towards the bottom of page you will see two tab buttons labelled Arbitrary and Properties
  3. Click on the Properties button
  4. Click on the "+" icon under the left panel
  5. Copy and paste the PCI path key (starts with PciRoot) from the generated code into the "Devices" field
  6. Click on the "+" icon under the right panel
  7. Type in "layout-id" into the "Properties Key" field
  8. Type in your "layout-id" value into the "Properties Value" field as a 8 digit Hexadecimal (eg 3 = 03000000)
This is what the above example looks like using Clover Configurator:-

350314

Note-1: We define the audio device's PCI path key in the left panel and the Device Property in the right panel.

Note-2: The data values generated by the Hackintool code generator are in base-64 so if you use Clover Configurator or plist editor then you will have to convert the value to an 8 digit hex number, you can use the calculator function in Hackintool to do this. For example you want to use layout id 13, Hackintool generates a base64 value of "DQAAAA==" if we enter this in to Hackintool's calculator we get a hex value of "0d 00 00 00", enter this as the value for "layout-id" without the spaces.

Hackingtool-Audio-Calc.png
After making the changes/edits save your config.plist and reboot, now you can test if the audio working. If audio is not working then work through each of the valid layout-id's for your codec, saving the config.plist file and rebooting between each test.

If after testing all valid values of layout-id for your codec audio is still not working then you may have a codec configuration that needs a new patch set ... as with a non-supported codec, the best place to get help is the official AppleALC help thread. Create a post with the details of your codec (see post #1 in the help thread) ) and write that none of the existing layouts work on your system. One of the AppleHDA guru's should see your post and offer to help.

Trouble Shooting AppleALC

Checking if AppleALC has loaded Correctly


We can easily check if AppleALC has loaded and initialised correctly by using IORegisteryExplorer, if you don't already have this installed you can download it using this link.

Run IORegisteryExplorer and enter "HDEF" in the search box, you should now see the ioreg directory tree for your "HDEF" device, using the above example this is what mine looks like :-

350275
Note: If you don't see HDEF and you are sure that you have installed Lilu + AppleALC correctly see the section below titled ACPI HDA/Codec Rename Issues.

In the above screen grab w can see that AppleALC has automatically created a new property called "alc-layout-id" which has inherited the layout-id value of 3 as defined in the config.plist (using Clover/Devices/Audio/Inject or as a Device Property) ... remember that this is the index value to the patch set in the AppleALC patch database. We can also see that "layout-id" has now been set to 7 which is the target layout in AppleHDA that AppleALC has patched and that MacOS is using.

If you don't see "alc-layout-id" in your "HDEF" directory tree then AppleALC is not loading or initialising correctly, the usual cause of this is that the kexts have not been installed correctly. Try deleting the Lilu + AppleALC kext's from /L/E, download them again and re-install using the method detailed in the How to Install section of this guide.

HPET Issues (High Precision Event Timer)

After following the guide to install AppleALC and performing the above check you find that the "alc-layout-id" property exists in the ioreg and the value for it and the property "layout-id" seem correct but you still have no sound then its possible that you might be suffering form an IRQ Conflict caused by the HPET (High Precision Event Timer).

The HPET is a basic requirement for MacOS to run correctly and almost all install guides on this forum state that you should enable the HPET option in your BIOS, however on some motherboards and laptops the native DSDT code for the HPET can cause a IQR conflict that can stop the AppleHDA kext initialising correctly.

One method of checking for this issue is by executing the following command in terminal :-

Code:
kextstat | grep 'Lilu\|AppleALC\|AppleHDA'

In the resulting output you should see the Lilu, AppleALC & AppleHDA kexts listed ...

Code:
MonkeyPro-2018:~ Jay$ kextstat | grep 'Lilu\|AppleALC\|AppleHDA'
   20    4 0xffffff7f81041000 0x22000    0x22000    as.vit9696.Lilu (1.2.8) 54014689-C8DA-318B-84F4-944BBA7AD2AC <8 6 5 3 2 1>
   23    0 0xffffff7f811bd000 0xdf000    0xdf000    as.vit9696.AppleALC (1.3.3) B60FCBAF-6BC2-36EF-A1E6-D5BE2863C35B <20 13 8 6 5 3 2 1>
  138    1 0xffffff7f830a7000 0x1d000    0x1d000    com.apple.driver.AppleHDAController (282.10) 70256EC9-AF38-31BD-A3C5-9C0E30B64AA3 <137 113 107 13 8 7 6 5 3 1>
  157    0 0xffffff7f8323a000 0xb7000    0xb7000    com.apple.driver.AppleHDA (282.10) B2208DA8-8CD9-36D8-BD59-C6D9A5379585 <156 138 137 124 113 107 7 6 5 3 1>
  159    0 0xffffff7f830c6000 0x2000     0x2000     com.apple.driver.AppleHDAHardwareConfigDriver (282.10) C4F674A0-5828-3D97-82BF-A81C8B8BDDBA <5 3>

As you can see from the above example if AppleHDA is loading then you will also see the AppleHDAController and AppleHDAHardwareConfigDriver kexts but the important one to note is AppleHDA.

If you do not see AppleHDA in the output (com.apple.driver.AppleHDA) then first check your BIOS settings and ensure that you have the HPET option enabled, if it is enabled and you still do not see AppleHDA in the output from the above command then you'll need to patch the HPET code in your DSDT.

The simplest method is to use the Cover option FixHPET in ACPI/DSDT/Fixes :-

Code:
    <key>ACPI</key>
    <dict>
        <key>DSDT</key>
        <dict>
            <key>Fixes</key>
            <dict>
                <key>FixHPET</key>
                <true/>

You can also apply the fix using Clover Configurator :-

375289


This should work for most users however if after applying the Clover HPET fix you still find that AppleHDA is not loading (using the above terminal command) then you may need to apply the fix directly to your DSDT, RehabMan has a DSDT patch in his Repo which you can apply to your DSDT using MaciASL:-

Code:
#Maintained by: RehabMan
# HPET fix to avoid AppleIntelCPUPowerManagement panic
into method label _STA parent_hid PNP0103 remove_entry;
into device name_hid PNP0103 code_regex Name\s\(_STA\,\s+0x0F\) remove_matched;
into device name_hid PNP0103 insert
begin
Name (_STA, 0x0F)\n
end;

into method label _CRS parent_hid PNP0103 remove_entry;
into device name_hid PNP0103 insert
begin
Method (_CRS, 0, NotSerialized)\n
{\n
    Return (BUF0)\n
}\n
end;

To apply the patch open your DSDT in MaciASL, click on the Patch button and copy/paste the above code into the patch editor and then click on Apply, save the patched DSDT and try again, for more info on patching your DSDT see Rehabmans full guide, make sure you disable the Clover fix is already applied.

ACPI HDA/Codec Rename Issues

Like WhatEverGreen, AppleALC and Lilu should apply the appropriate ACPI renames to your DSDT automatically, however sometimes it can fail in which case you may need to apply the renames manually. You can confirm if your device has been renamed successfully by using IORegistryExplorer and searching for HDEF.

IOREG-HDEF.png
If HDEF exists in your ioreg then there is no need to do any further checks, however if it is not found and you have correctly installed Lilu + AppleALC and configured layout-id using one of the two methods detailed in this section of the guide then you should try applying the HDEF rename manually.

First check the native name of your HDA device by opening your vanilla (without edits) DSDT in MaciASL and search for "HDEF", if no results are found then try searching for "HDAS" if that search fails try searching for "AZAL"

If your HDA device is called "HDEF" then there is no need to rename the device, however if it is called "HDAS" then add the following Clover rename patch to the "Clover/ACPI/Patches" section of your config.plist :-

Code:
                <dict>
                    <key>Comment</key>
                    <string>change HDAS to HDEF</string>
                    <key>Disabled</key>
                    <false/>
                    <key>Find</key>
                    <data>
                    SERBUw==
                    </data>
                    <key>Replace</key>
                    <data>
                    SERFRg==
                    </data>
                </dict>

If your HDA device is called "AZAL" then the rename patch is :-

Code:
                <dict>
                    <key>Comment</key>
                    <string>change AZAL to HDEF</string>
                    <key>Disabled</key>
                    <false/>
                    <key>Find</key>
                    <data>
                    QVpBTA==
                    </data>
                    <key>Replace</key>
                    <data>
                    SERFRg==
                    </data>
                </dict>

You can also rename the HDA device using Clover Configurator by selecting the appropriate rename patch :-

350284


AppleALC EAPD wake verbs

As an added bonus, AppleALC also takes care of EAPD wake verbs for most codec's so there is no need to install/use Codec Commander, you can check if AppleALC supports EAPD wake verbs for your codec by looking at the release history commit comments, if it is supported and you already have Codec Commander installed then you should remove it .



Chapter-6: AirportBrcmFixup

This plug-in is pretty straight forward, it includes a set of patches required for native and non-native Broadcom Airport/Wi-Fi cards. The patches deal with things like enabling continuity and handoff, renaming your WiFi as an Airport device, plus a few other handy patches. As with all the other Lilu plug-in's in most cases (see notes below) you should remove all previous WiFi related patches and enabler kext's.

One reason to consider using this plug-in is that it negates the problem that you can no longer use a Clover patch to enable Handoff on MacOS 10.13.X and 10.14.X. You don't need to set any Device Properties for this plug-in, if it finds a supported WiFi device it will apply all the necessary patches automatically.

If you don't already know the VID & PID of your installed WiFi adapter then you can use Hackintool to identify your device, click on the PCI icon and find your WiFi device in the list and make a note of the Vendor ID (VID) and Device ID (PID).
Hackingtool-PCI-WIFI.png
In the above example my WiFi device has a VID of 14E4 (Broadcom) and a PID of 43BA (BCM43602 Chipset)

To see if your WiFi device is supported, take a look at the info.plist on the projects Git-Hub project page and search for your WiFi Devices PID.

360645
If you see your devices VID + PID in the list then your good to go, simply install AirportBrcmFixup (and Lilu if not already installed) using the method detailed in the How to Install section of this guide.

If necessary, you can over-ride the default MacOS WiFi local and explicitly set a country code for your WiFi device using the boot argument brcmfx-country=XX, this is sometimes necessary to get 5Ghz WiFi working at full speed on some WiFi routers. A common value for this is "#a" which is a special value that effectively tells MacOS to ignore the WiFi country code set by your router. I've always had to use the "#a" country code on all versions of MacOS in order to get full 5Ghz WiFi bandwidth with my router.

BRCMFX-CC-Code.png

Note 1: I think the guide/readme.md on this plug-in's Git-Hub page is a bit out of date in that states it should be used with other 3rd party WiFi enablers. I believe that earlier versions of AirportBrcmFixup did require the use of additional software depending on what type of card you have. However from my testing it appears that this is no longer the case and AirportBrcmFixup should do pretty much everything required so no need for any other software.

Note 2: AirportBrcmFixup only deals with the Airport/WiFi side of a combo card it does nothing to enable/support Bluetooth. To enable Bluetooth on all my Hackingtosh systems I use RehabMans BrcmPatchRAM ... see his Git-Hub Project page for more info.

I've tested AirportBrcmFixup with a DW1830 (BCM43602) in my laptop and a BCM943602CS in my desktop system and it works great, no other patches or enablers needed. .. handoff and continuity have never worked better.

Based on my experience I suggest you try AirportBrcmFixup on it's own and remove all other WiFi/Airport enablers, kext's and patches ... as long as your device is supported (see the info.plsit) you should be ok, if it does not work then you may need to add one of the 3rd party kext enablers mentioned in the readme.md .... please post your success (and failures) below so we can confirm this for other users.

For a full list of all the patches this plug-in provides along with a list of boot arguments see the projects Git-Hub readme.md.



Chapter-7: Other useful Lilu Plug-in's

Here is a list of some other useful Lilu plug-in's, most of these just need to be installed in /L/E and don't require any additional configuration to work, however you should read the documentation for each plug-in before installing just to make sure. I'll try to keep this list updated as other Lilu plug-in's are released.

BT4LEContiunityFixup

If after installing AirportBrcmFixup you continue to have BT Continuity issues (AirDrop, Handoff, FaceTime Continuity .. etc) you could try installing BT4LEContinuityFixup which applies a few more specific patches to enable MacOS BT-LE Continuity features on non-native Broadcom BT-LE chipsets ... as with the other Lilu plug-in's you should disable or remove any existing Clover Bluetooth patches, but be sure to keep the BrcmPatchRAM kexts in /L/E.

HibernationFixup

As the name suggest this Lilu plug-in allows the enabling of MacOS save-to-disk hibernation modes 3 and 25 on certain systems. I have not used HibernationFixup myself but have read many positive posts that it does work as long as your system meets the hardware requirements (specifically native NVRAM, not emulated). Be sure to read all the documentation first before installing.

VirtualSMC

A lilu plugin that emulates the Apple SMC (System Management Controller) .. typically we have always used FakeSMC for this task and as of now (May 2019) I would recommend that you continue to use FakeSMC as its still unstable on some systems and needs more sensor plugins before it can be recommended over FakeSMC.

I'm sure that VirtualSMC will at some point surpass FakeSMC but it is still quite early in its development cycle. I think this is a plug-in to keep an eye on as I am sure at some point in the future it will be preferable to use VirtualSMC in place of FakeSMC.

NoTouchID

Many of the newer SMBIOS's are for Apple Mac's that include a finger print reader (TouchID), if you use one of these SMBIOS on a Hackingtosh then your likely to encounter stutters during the boot phase and whenever MacOSprompts for a system password as the hardware is not present. Installing NoTouchID should resolve this issue.

NightShiftUnlocker

By default Apple's night shift feature is only enabled on certain SMBIOS's, this simple Lilu plugin enables Apple's Night Shift feature on those SMBIOS's that don't normally support it. Once installed in /L/E you should be able to access the Night Shift options in System Preferences -> Displays -> Night Shift.



Chapter-8: Final thoughts

Lilu and its plug-in's such as WhatEverGreen, AppleALC and AirportBrcmFixup consolidates everything that has been learnt by the entire hackingtosh community over the last five years and does a lot of the hard work that used to achieved with multiple Clover patches, custom and dummy kext's, hot patches ... etc with just a handful of kext's and the injection of a few Device Properties.

Once you take the time to understand Lilu and its plug-in's you will find that they really can simplify the patching of critical area's of MacOS with the minimum amount of effort. Of course there are always going to be exceptions where these solutions wont work but for many users, Lilu and its plug-in's should be considered a viable and mature alternative to the traditional hackingtosh methods that we have used for the last few years.

It goes without saying that Lilu and its plug-in's are in constant development so I recommend keeping an eye on the Git-Hub release pages, the latest version of each project will always be shown at the top of the page along with details of the changes and commits to that version. You can use Hackintool (Click on the Installed icon on the in-app menu) to check for updates to Lilu and it's plug-in's.

I'd like to take this opportunity to thank all of the developers involved with Lilu and its plug-in's for all their hard work and their contribution to the hackingtosh community, and @headkaze for the constant development of Hackintool , it should be noted that they in-turn (where applicable) acknowledge the original creators of any methods that some of the plug-in's use, these credits can be seen at the bottom of the readme.md on each of the Git-Hub project pages.

Cheers
Jay



Getting further Help and Support

If you need help outside the basic scope of this guide then do not post your question here, please create a new thread in the appropriate sub section of the forums such as Post Install, Laptops .. etc.

If you suspect there is a bug in Lilu or one of it's plug-in's then you should post your findings to the relevant support thread(s) documented in the readme.md of the appropriate Git-Hub project page, the same is true if you need to report an unsupported device for inclusion in the next release.
 

Attachments

Last edited:
Joined
Jun 7, 2017
Messages
4
Motherboard
GA-G1 Gaming
CPU
i5
Graphics
HD530
Mac
MacBook Air, MacBook Pro, Mac mini
Mobile Phone
iOS
jaymonkey, thanks a lot for this guide!

Each time a new OS was published I fiddled around with kexts, configs, patches and somehow always got my system up and running. But it always was a pain. Same with Mojave. No Audio, USB only partially working, ...

Now I followed your guide ... and my system is up and running within minutes. Audio via DP works, USB works - this is great.
So, again, thanks a lot for your guide.
 

jaymonkey

Moderator
Joined
Aug 27, 2011
Messages
2,506
Motherboard
ASRock-Z97 EX6
CPU
i7-4790K OC @ 4.8GHz
Graphics
Vega 64LC + HD4600
Mac
MacBook Air, MacBook Pro
Mobile Phone
Android, iOS
jaymonkey, thanks a lot for this guide!

Each time a new OS was published I fiddled around with kexts, configs, patches and somehow always got my system up and running. But it always was a pain. Same with Mojave. No Audio, USB only partially working, ...

Now I followed your guide ... and my system is up and running within minutes. Audio via DP works, USB works - this is great.
So, again, thanks a lot for your guide.
@blitzjunge,

Correct ... anything handled by Lilu and its plug-in's should survive major & minor MacOS updates ....

Glad you fund the guide useful.

Cheers
Jay
 
Joined
Feb 18, 2012
Messages
90
Motherboard
Hp Spectre X360 15 (Clover UEFI)
CPU
i7 7500U, 512 GB PCIe NVME Hynix
Graphics
Intel 620, 4K Screen
@jaymonkey
Very well written guide as always. :thumbup:

One Question: The AirportBrcmfixup page on github has following installation types listed:

Installation types
  • Clover Airport Fix + AirportBrcmFixup
  • Clover Airport Fix + AddProperties(fake device-id) + AirportBrcmFixup (preferable)
  • Clover Airport Fix + AirportBrcmFixup + FakePCIID + FakePCIID_Broadcom_WiFi.kext
  • AirportBrcmFixup + FakePCIID + FakePCIID_Broadcom_WiFi.kext
Which fix are you using, is it the second one? Can you please provide some info on AddProperties for fake device id? Also I am not sure which Clover Airport Fix is referred there, is it:

ACPI/DSDT/Fixes/FixAirport_4000
<key>FixAirport_4000</key>
<true/>
 

jaymonkey

Moderator
Joined
Aug 27, 2011
Messages
2,506
Motherboard
ASRock-Z97 EX6
CPU
i7-4790K OC @ 4.8GHz
Graphics
Vega 64LC + HD4600
Mac
MacBook Air, MacBook Pro
Mobile Phone
Android, iOS
@johnyg07,

I think that guide on GitHub is a bit out of date .. earlier versions of AirportBrcmFixup did need to be used with other WiFi enablers depending on what type of card you have. But as far as I know the current version of AirportBrcmFixup should do pretty much everything so no need for any other enablers, kext's .. etc.

I've tested it with a DW1830 (BCM43602) on my laptop and a BCM943602CS in my desktop and it works great, no other patches or enablers needed. .. handoff & continuity have never worked better.

I suggest you try just AirportBrcmFixup on it's own ... as long as your device is supported (as detailed in my guide) you should be good to go.

Let me know how you get on ....

Note: I've added an extended version of the above to the AirportBrcmFixup section of the guide.

Cheers
Jay
 
Last edited:
Joined
Nov 4, 2011
Messages
453
Motherboard
GA-Z170X-UD3 F23g
CPU
i7-6700K
Graphics
RX-580
Mac
iMac
Hi @jaymonkey. Congratulations on yet another great guide of yours which is extremely well written and easy to follow. I have been using all the plugins you mentioned in your guide for quite some time now, long before "the great plugin merge" took off the ground.
Thank you for the effort you put in to make a rather complex procedure so simple to apply for all the noobs out there, me included.
Greetings
 
Joined
Feb 18, 2012
Messages
90
Motherboard
Hp Spectre X360 15 (Clover UEFI)
CPU
i7 7500U, 512 GB PCIe NVME Hynix
Graphics
Intel 620, 4K Screen
I've tested it with a DW1830 (BCM43602) on my laptop and a BCM943602CS in my desktop and it works great, no other patches or enablers needed. .. handoff & continuity have never worked better.

I suggest you try just AirportBrcmFixup on it's own ... as long as your device is supported (as detailed in my guide) you should be good to go.
@jaymonkey

I also have DW1830 on my spectre. I see that wifi is detected and seem to be working at slower speeds. Bluetooth is not detected.

Here are some of my observations:
When I installed mojave on a USB SSD, wifi was detected on first boot with clover USB without the AirportBrcmFixup. I only had Lilu and WEG kext in clover.

I upgraded my highsierra with mojave and it was smooth. But for some reason I only see 11 mbps speed on the network monitor.

I have tried several combinations. I upgraded BIOS, re-patched DSDT.

With Lilu, AirportBrcmFixup
With Lilu, AirportBrcmFixup and country code kernel parameter (#a)
With Lilu, AirportBrcmFixup, country code clover patch
With Lilu, AirportBrcmFixup, counter code kernel parameter, FakePCIID.kext, FakePCIID_Broadcom_WiFi.kext

In all the combinations, the wifi speed is shows as 11 mbps only in network utility. I am not sure what else to try. can you suggest something here. debug files and network utility screenshot is attached.

Also, it would be great if we can list down the DSDT patches and other clover fixes for hp spectre 360 in one place. I can create a guide if we can review the steps I used.

EDIT:
I just realized that network utility is not showing the current speed. I can see the speed by option+click on wifi icon on menu bar. it is showing 145 mbps right now. Will revert all the changes and test again.
 

Attachments

Last edited:

jaymonkey

Moderator
Joined
Aug 27, 2011
Messages
2,506
Motherboard
ASRock-Z97 EX6
CPU
i7-4790K OC @ 4.8GHz
Graphics
Vega 64LC + HD4600
Mac
MacBook Air, MacBook Pro
Mobile Phone
Android, iOS
.... I also have DW1830 on my spectre. I see that wifi is detected and seem to be working at slower speeds. Bluetooth is not detected.

In all the combinations, the wifi speed is shows as 11 mbps only in network utility. I am not sure what else to try. can you suggest something here. debug files and network utility screenshot is attached.
@johnyg07,

I have the same card in my Spectre X360 ... I am only using AirportBrcmFixup

Its not un-known for some network settings getting corrupted during MacOS updates .... the first thing I usual do is to reset the network configuration files ... see section 3.2 of my iMessage guide ..

Follow the instructions titled Re-setting OSX's Network and System configuration

Its a completely safe process and is usually the first thing Apple do when network issues arise ..

Hope it helps ...
Cheers
Jay
 
Top