RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,015
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
b) Add SSDT-Config creates RMCF device , sets AUDL to 1 (no audio injection) and FAKH to 1 (HDMI audio related)
c) Add SSDT-HDEF
// inject properties for audio
Method(_SB.PCI0.HDEF._DSM, 4)
{
If (Ones == \RMCF.AUDL) { Return(0) }
I'm trying to understand this line as, I would guess that as we set \RMCF.AUDL to 1 in 3b) , we should just return out of the method at this point? However I see later that we do the following:
AUDL is set to 1 in SSDT-Config.aml. It selects layout-id=1. Your comment above "AUDL to 1 (no audio injection)" is wrong. The code will not inject audio only if AUDL is Ones. Any other value causes that value to be injected for layout-id (this repo uses layout-id 1 for ALC283, and layout-id 2 for ALC233). Ones is not the same as 1 (or One). Ones all bits set to 1 (eg. twos complement -1). Read ACPI spec for further discussion of built-in constant 'Ones'.
d) SSDT-NUCHDA
Seems to create RMCF.cache entry with CodecCommander / CodecCommanderProbeInit sections. The later has a LayoutID and PinConfigs which seem to be the real PinConfigs for our Codec
Are these used in preference to the PinConfigurations Data that exists directly under HDEF?
The content in SSDT-NUCHDA is configuration data for CodecCommander.kext. Most people patch AppleHDAHardwareConfigDriver.kext to fix the HDA pinconfigs. I use CodeCommander.
Last edited: