Injected headphone does not work upon reboot
syscl opened this issue · comments
Now the only issue for me is the injected headphone will lose sound after next boot. This won't be fixed until rebuilding caches and eject headphone(or sleep more than 1 min). The log of CodecCommander v2.4 is listed below:
8/21/15 1:36:14.000 PM kernel[0]: CodecCommander: Version 2.4.0 starting.
8/21/15 1:36:14.000 PM kernel[0]: CodecCommander: Evaluating device "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/HDEF@1B" [8086:8c20].
8/21/15 1:36:14.000 PM kernel[0]: CodecCommander: ....CodecVendor Id: 0x10ec0668
8/21/15 1:36:14.000 PM kernel[0]: CodecCommander: ....Codec Address: 0
8/21/15 1:36:14.000 PM kernel[0]: CodecCommander: ....Subsystem Id: 0x1028060d
8/21/15 1:36:14.000 PM kernel[0]: CodecCommander: ....PCI Sub Id: 0x1028060d
8/21/15 1:36:14.000 PM kernel[0]: CodecCommander: Node ID 0x14 supports EAPD, will update state after sleep.
8/21/15 1:36:14.000 PM kernel[0]: CodecCommander: Node ID 0x15 supports EAPD, will update state after sleep.
8/21/15 2:37:17.000 PM kernel[0]: CodecCommander: Version 2.4.0 starting.
8/21/15 2:37:17.000 PM kernel[0]: CodecCommander: Evaluating device "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/HDEF@1B" [8086:8c20].
8/21/15 2:37:17.000 PM kernel[0]: CodecCommander: ....CodecVendor Id: 0x10ec0668
8/21/15 2:37:17.000 PM kernel[0]: CodecCommander: ....Codec Address: 0
8/21/15 2:37:17.000 PM kernel[0]: CodecCommander: ....Subsystem Id: 0x1028060d
8/21/15 2:37:17.000 PM kernel[0]: CodecCommander: ....PCI Sub Id: 0x1028060d
8/21/15 2:37:17.000 PM kernel[0]: CodecCommander: Node ID 0x14 supports EAPD, will update state after sleep.
8/21/15 2:37:17.000 PM kernel[0]: CodecCommander: Node ID 0x15 supports EAPD, will update state after sleep.
This is a known issue. No resolution known at this time.
I've just found this issue occurs when booting OS X with injection headphone. Hence this will affect those people who do not remove their headphones before reboot or more exactly during the booting progress.
This issue affects all the platforms including Windows, Ubuntu, however, under Windows and Ubuntu it can be fixed after re-injecting headphone.
Can I modify CodecCommander.kext to active the headphone after reboot?
I did try that before. Feel free to see if you can get it working and I will merge it into the repository.
You'd need to send the right HDA verb commands as part of the custom commands on startup.
Replying to @syscl here from issue #11:
No I do not have an idea to fix this issue. I tried doing a diff of the alsa dumps in linux between the first boot with headphones plugged in (when they don't work) and after re-plugging them (when they do work). There are no meaningful differences in the dumps as far as i can tell (the amp-out values are different before/after on the headphone and speaker nodes, but OSX always has both amps running even when no sound is coming out of the headphones).
If I cared to figure this out, I think my next course of action would be to track down what else is happening when you unplug/replug the headphones. This is probably a good place to start: https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c#L4129. When you're unplugging/replugging, one can assume you're switching from (defective) ALC_HEADSET_MODE_HEADPHONE to ALC_HEADSET_MODE_UNPLUGGED and back to ALC_HEADSET_MODE_HEADPHONE. I looked at the registers that are set back and forth when this happens (in alc_headset_mode_default and alc_headset_mode_unplugged) and nothing jumped at me. I would then look at what snd_hda_gen_update_outputs(codec) does (last line in alc_update_headset_mode). I haven't done this last part.
That's how I'd go about it, but honestly I don't care enough to go through with it. I never ever have headphones plugged in when I cold boot this laptop, so there's really no incentive for me to go through it..
Note: All of the above is accurate with my (very) limited knowledge of how this code works. I would encourage you to retrace my steps as I may have overlooked something along the way.
I have fixed this issue. Although I am not familiar with AppleHDA, but after adding 3 patches for 2 kexts(AppleHDA.kext and AppleIntelFramebufferAzul.kext), the injected HP problem disappear!
I've tested on my DELL Precision M3800(3200x1800 model). And now I can enjoy the injected HP!
Here's my REPO with the update: https://github.com/syscl/M3800
And the 3 patches listed below my config.plist under that REPO.
Hope it will work for you, cheers! syscl