Dolnor

It works in 10.9GM with patched applehda 2.5.2fc2 and original ioaudioFamily 1.9.4fc11. But I got a much larger 'pop' before the sound comes out after sleep. Anyway, thanks very much.

The pop is expected and appears to be a bug with some variants of ALC268/269/271 and 272 audio codecs, has nothing to do with this fix. That's a part of Apple's new PM stuff implemented with 10.9 release related to Power Nap and such. Even antipop can't prevent it. Thanks for your feedback.

Not so perfect, I've found a requirement as outlined by intel that I wasn't setting:

 - Offset 68h: Immediate Command Status - 16 bit register

 
     Bit 0 - Immediate Command Busy (ICB): This bit is a 0 when the controller can accept
     an immediate command. Software must wait for this bit to be 0 before writing a
     value in the ICW register.
   
     Bit 1 - Immediate Result Valid (IRV): This bit is set to a 1 by hardware when a new
     response is latched into the IRR register. Software must clear this bit before
     issuing a new command by writing a one to it so that the software may determine
     when a new response has arrived.

I wasn't doing the last part in bold and this appears to be the culprit to jack sensing and audio not working after sleep because previously issued command (on boot) hasn't cleared IRV field. So the command that has been issued after wake was stalling the codec, as Intel says "undefined behavior will result". I've changed this and now even after 3 minute delay after waking the machine if there is no audio stream present sound and jack sensing remains functional.

commander_debug+release.zip

There are codec verbs that can be used to mute and unmute the amps as well as the entire codec widgets, so there is no need to implement the entire HID class and emulate mute tickle. I too have the "30sec delay" issue which always existed for me but I never knew the cause of jack sensing suddenly failing..

I can't wrap my head around it sadly as I have very little experience in coding IOKit stuff... all the codec verbs are defined long ago in linux  hda-verb-0.3 .. it was used at some point to control HDA codecs in a matter we currently do. 

So for EAPD update this had to be called from elevated terminal:

hda-verb /dev/snd/hwC0D0 0x14 SET_EAPD_BTLENABLE 2

Where:

- hwCOD0 = codec address

- 0x14 = output (speaker) node

- SET_EAPD_BTLENABLE = the command verb 0x70c

- 2 = PCM parameter 0x02

So it ends up sending 0x01470c02 to the codec.. looks familiar, doesn't it ?

Take a look at the sources of hda-verb, maybe you can come up with more elegant solution.

Also, please consider removing the IOLog outputs (make them debug only) from your kext, the amount of text it spits out is just ridiculous for a kext that simple. Your human-readable copyright is more than enough, we have ton of kexts that want to shine copyright IOLog messages at boot that it's just getting out of hands.. I don't want to know (and see) any of the stuff that is happening behind the curtains, make it just do the job and that's it .. same goes for BT uploader kext.

sure, why not

Here's a release version of my kext with debug messages turned off.

I've added missing dependency (thanks to slice for pointing that out to me) and now the kext initializes with IOAudioFamily (which wasn't really an option with VoodooPS2 implementation as Keyboard Device needs to be initialized very early in the boot process and it can't wait for IOAudioFamily to start right before DSMOS arrives), so having EAPD codec verb in your pinconfig is no longer a requirement. I should point out that there won't be any console messages coming from the kext.

p.s. sources are posted over at git

release_CodecCommander.kext.zip

If it is possible, can you consider making it a separate kext? As an owner of a laptop with an Elan touchpad, I can't use PS2 controller without kext conflicts.

I've considered.. it's a debug version for now. This kext is also made configurable ... you need to set make and model for your custom profile.

For Chameleon open up your DSDT and look up at the top:

"DELL  ", "QA09   "
 
Make: DELL
Model: QA09

kernel[0]: CodecCommander::init: DMI Vendor DELL
kernel[0]: CodecCommander:init:: DMI Board 0YW3P2
 
Make: DELL
Model: 0YW3P2

Config for my laptop looks as follows: 

By default EAPD updating will be off (for this test I've set it to YES and 20 for speaker node as it's most common).

Node numbers are set in decimal .. so if you have EAPD on node 0x14 you need to specify 20 inside the plist.

You should see this in the log upon boot (DMI bits will be there only if using Clover bootloader):

kernel[0]: CodecCommander::init: Initializing
kernel[0]: CodecCommander::init: DMI Vendor DELL
kernel[0]: CodecCommander:init:: DMI Board 0YW3P2
kernel[0]: CodecCommander::probe: Probing
kernel[0]: CodecCommander::start: Starting
kernel[0]: CodecCommander: power is on

kernel[0]: CodecCommander: power is off

 kernel[0]: Wake reason: PWRB (User)
 kernel[0]: 116.938186: performCountryCodeOperation: Not connected, scan in progress[0]
 kernel[0]: RTC: PowerByCalendarDate setting ignored
 kernel[0]: No interval found for . Using 8000000
 kernel[0]: RTC: PowerByCalendarDate setting ignored
 kernel[0]: CodecCommander: power is on
 kernel[0]: Previous Sleep Cause: 5
 kernel[0]: USBF: 116.955 AppleUSBEHCI: setPowerState - PCI device still has PMS status bit set. PMCSR is 0x8000
 kernel[0]: The USB device HubDevice (Port 1 of Hub at 0x1a000000) may have caused a wake by issuing a remote wakeup (2)
 kernel[0]: USBF: 116.956 AppleUSBEHCI: setPowerState - PCI device still has PMS status bit set. PMCSR is 0x8000
 kernel[0]: The USB device HubDevice (Port 1 of Hub at 0x1d000000) may have caused a wake by issuing a remote wakeup (2)
 kernel[0]: CodecCommander: sending codec verb command 1470c02
 kernel[0]: CodecCommander: command sent

Is it possible to make this as a standalone kext that wouldn't require rewrites and recompilation with every major source release from Apple?

I mean, it's actually possible to make a power state hook that would execute the update method when power state changes and boolean that EAPD felt asleep is equal to one. This would be a much cleaner solution and won't require any user input after updating ... I'm not skilled enough to code a kext like that, but I've attempted nonetheless but PM state hook wasn't successful on my part and all I achieved was that audio was enabled upon boot up whilst EAPD verb wasn't included in pinconfig.. 

Quoting myself here...

Well, I felt like having another kext in the system is pretty pointless, considering I already have a kext that is able to determine power state transitions.. and it just happens to be opensource. So I went ahead and modified it, so no more IOAudioFamily sources are required and no hassle for me after every updated (you don't generally update your PS/2 kexts that often, do you?).

The kext is made configurable and can handle both speaker and headphone nodes if they are defined properly. You still need to have the EAPD codec verb in your pinconfig for sound to be enabled upon boot though. Not anymore...

My codec only has EAPD on speaker node 0x14 (20) so I can't test headphones alone or headphones plus speakers for EAPD command verb updating. 

People who are using RehabMan's VoodooPS2Controller can give this a go, I've documented the settings I've added (as well what has been modified from RehabMan's sources) in the readme:

https://github.com/Dolnor/VoodooPS2Controller_EAPD_Handler

Cheers!

- Dolnor a.k.a TimeWalker

Is it possible to make this as a standalone kext that wouldn't require rewrites and recompilation with every major source release from Apple?

I mean, it's actually possible to make a power state hook that would execute the update method when power state changes and boolean that EAPD felt asleep is equal to one. This would be a much cleaner solution and won't require any user input after updating ... I'm not skilled enough to code a kext like that, but I've attempted nonetheless but PM state hook wasn't successful on my part and all I achieved was that audio was enabled upon boot up whilst EAPD verb wasn't included in pinconfig..