I have a Macbook Pro 12.1, and despite it's detecting the external Headphone part of the Headset it fails to detect the mic, so when I connect the headset, it assumes it's a regular headphones. sudo hdajacksensetest -c 1 Pin 0x10 (Green Headphone): present = Yes Pin 0x18 (Pink Mic): present = No Pin 0x21 (White SPDIF Out): present = No alsa-info.sh output - without headset connected: http://www.alsa-project.org/db/?f=fa7470534b5394fe9da61c3fab50dd0586f4907a - with headset connected:http://www.alsa-project.org/db/?f=b07725fe64c20b2495065daa40fe4fba51dee627 I have changed from the Fedora kernel version to a vanilla one (4.8.0-rc2) and got the same result. Also I've tried Kde Neon project, based on Ubuntu and the problem remains. If there's anything else I can do to help fixing this, please let me know.
Created attachment 239011 [details] alsa-info output for kernel 4.7.3-200.fc24 without headset
Created attachment 239031 [details] alsa-info output for kernel 4.7.3-200.fc24 with headset connected
Since the http://www.alsa-project.org/main/index.php/Help_To_Debug_Intel_HDA wiki page states we should upload the files, here they are. I have two files, one with the headset unplugged and other with it plugged. Another point, I've tried the MacOS (I have dual boot) with the same headset and it works fine. I have tried with another headset and it still don't work. Is there anything else I could do to help solving this?
Unfortunately there is no proper headset detection procedure defined for HD-audio spec. It's purely vendor-specific implementation. In some cases, it's reported to the mic pin detection, in some cases, it's reported via GPIO, and in some cases, it's vendor COEF verb. And this case is Apple, so we have no idea at all what's going on. You need trial-and-error approach for checking every bit...
Thanks for your feedback Takashi, but for a developer with zero knowledge on drivers programming, is there any blog/doc/etc I can follow to try. If there's nothing, can you point the code how to check or examples?
Well after spending some hours on sound/pci/hda/patch_cirrus.c file, trying to make changes and check if they produce any effect, I'm about to give up. I have grabbed the 4.8.4 kernel enabled the module unload, and then tried to change some code (commenting code and changing the 0x18 with other address) but failed to get some results. I understand it's difficult to give hints for people who don't have a clue about driver development, but I'll be glad if you try... or an IRC session... I'm really annoyed about this bug.
I've been able to change the address of the 0x18 input (external mic). Takashi, can you enlighten me on how can I generate values to try?
Created attachment 247961 [details] Windows information about external mic Gathered via High Definition Audio (HD Audio) tool
Created attachment 247971 [details] Windows information about the card
I've managed to get the windows 10 installed with the right drivers (from apple bootcamp) and it works as expected. Using the High Definition Audio (HD Audio) tool (https://msdn.microsoft.com/en-us/library/windows/hardware/dn613936(v=vs.85).aspx) I've created some screenshots and a dump from the registry, hoping it provides a source to get this sorted out.
Created attachment 247981 [details] Windows PIN configuration
Paulo, For testing the vendor COEF verb mentioned by Takashi Iwai, I think you need: - hda-verb - http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/high-definition-audio-specification.pdf You can read this to give you an example: http://www.asyndetic.com/2013/04/11/on-debugging-intel-high-definition-audio-in-linux-part-i/ For mic pin detection, maybe Takashi Iwai means using something like hdajackretask but I suppose it is more complex than that. In fact, I think that the problem would already been fixed if only hdajackretask was required. For GPIO, no idea.
Just to add that bug 52221 contains useful information, especially this comment: https://bugzilla.kernel.org/show_bug.cgi?id=52221#c17