As mention in the basic knowledge guide about DSDT/SSDT, SSDT ( Secondary System Description Table ) are sub-tables which describe additional devices. By using SSDTs OEMs can manage DSDT better, and so SSDT can be shared between similar systems. SSDTs that comes with the system usually contain these information ( red means scope/device can be found in SSDT ):
- SATA management: _SB.PCI0.SATA
- Sensor management: PTID
- CPU management: _PR.CPU
- Intel HD Graphics management: PCI0.GFX0 or PCI0.VID
- Dedicated GPU management: various names like GFX0, PEGP or DGFX, etc…
- Features like Optimus, Switchable Graphics,..
To edit these tables, make sure to dump and decompile all DSDT/SSDT, edit the dsl file then save it as aml. To load the edited one, rename it by order: SSDT.aml, SSDT-1.aml, SSDT-2.aml,… and put them in the bootloader’s directory ( the same as DSDT.aml )
Drop OEM SSDT
This feature was created due to the fact that system’s original SSDTs that manage CPU are useless in OS X, which force users to create CPU management SSDTs which are optimized for OS X. By loading both OS X’s optimized SSDTs and original SSDTs, they can conflict each other, cause unstable CPU loading.
Drop OEM SSDT is made to wipe (drop) original SSDTs in BIOS/UEFI to avoid conflicts. Even though other SSDTs are also dropped, but these tables aren’t always important ( most systems can run with DropSSDT=True )
CPU management SSDTs
Bootloaders like Chameleon, Clover can create a SSDT compatible with OS X to control the CPU by setting GeneratePState/GenerateCState=True.
ssdtPrGen script made by Pike R. Alpha is better way to create CPU SSDTs for OS X, and will always be up-to-date. You can create your SSDT.aml using ssdtPrGen by selecting Tools > SSDT Generator in HVT
- ssdtPrGen script only supports 2nd/3rd/4th Core I and Xeon Processor. Other CPUs have to use the bootloader’s Generate features.
- Do not use both SSDT.aml and bootloader’s Generate features, it can cause unknown issues.
- It is recommended to use Drop OEM SSDT features to avoid conflicts between SSDTs
Intel HD Graphics management SSDT ( laptop-exclusive )
Most Intel iGPUs is defined in DSDT, but in some cases ( especially Haswell laptops ), the iGPU is managed in SSDT.
To check whether DSDT or SSDT is managing your iGPU, find these in the tables:
<span class=”typ”>Device</span> <span class=”pun”>(</span><span class=”pln”>GFX0</span><span class=”pun”>)</span>
<span class=”typ”>Device</span> <span class=”pun”>(</span><span class=”pln”>VID</span><span class=”pun”>)</span>
<span class=”typ”>Name</span> <span class=”pun”>(</span><span class=”pln”>_ADR</span><span class=”pun”>,</span> <span class=”lit”>0x00020000</span><span class=”pun”>)</span>
They are inside PCI0 scope.
For example, this system’s HD4400 is managed by ssdt7.dsl
In this case, for brightness fix you have to compile and load that ssdt. And if you apply a patch that rename GFX0 to IGPU, you have to do it in all related DSDT/SSDT.
Dedicated GPU management SSDT ( laptop-exclusive )
By default they are named DGFX, PEGP and have _OFF, _ON methods, for example: