AppleHDA patching in Mountain Lion

[masa]

@masa

 

In the old patched kext from 10.7.4 with old DSDT (device-id 12) the mic works with ML. However, not very vanilla, but fine with the new speech recognition! Hope ErmaC can fix the mic!

 

yes, that's my current status too, looking forward to a new solution.

[ErmaC]

Hi guys.

my mistake.

I forgot to change the layout also in the Info.plist.

 

I correct the file in the previous post and posted the patched (complete) kext for AD2000b..

enjoy

 

Fabio

[bcc9]

I've updated my AppleHDA patch script to handle multiple codec ids and also dynamically figure out which extra comparisons should be patched to get the matching to work properly. The script supports osx 10.7 and osx 10.8.: patch-hda.pl.0.7.zip

 

The script works by continuing my idea of patching the codec comparisons by zeroing out the codec ids found as operands to the applicable comparison instructions. This is easier to do in a script than trying to compute a new jump location as the script does not even need to parse AppleHDA's match routine's instructions (see ati-personality.pl for an example of that kind of processing).

 

I think maintaining a script like this will be more generally useful & easier to maintain than a bunch of perl one-liner posts.

 

This script resembles the concept of HDA wizard http://www.insanelym...howtopic=266531 but instead of being GUI focused, it focuses on getting the AppleHDA binary patching done automatic&right across osx releases.

 

I've only added support for a few codecs that I've used on hackintoshes (idt 7675, alc 889 and alc992). I could try to fold in the codecs from HDA wizard, as well as this thread, if this looks good.

 

Examples, under 10.7:

 

% ./patch-hda.pl 111d7675
Patching AppleHDA codec 11d41984 with 111d7675
1 codec range comparison(s) to patch
Patching range comparison 11d41983
AppleHDA patched successfully.

under 10.8:

% ./patch-hda.pl 111d7675
Patching AppleHDA codec 11d41984 with 111d7675
No codec range comparisons require patching
AppleHDA patched successfully.
% ./patch-hda.pl 10ec0889
Patching AppleHDA codec 10ec0885 with 10ec0889
No codec range comparisons require patching
AppleHDA patched successfully.
% ./patch-hda.pl 'Realtek ALC889+inputs'
Patching AppleHDA codec 11d41984 with 10ec0889
No codec range comparisons require patching
AppleHDA patched successfully.
% ./patch-hda.pl
Usage: patch-hda.pl <codec-id>|<codec-name>
Examples: patch-hda.pl 111d7675
Examples: patch-hda.pl 'IDT 7675'
Supported codecs:
Target          Patch           Name
Codec ID        Codec ID
-------------------------------------------
111d7675        11d41984        IDT 7675
111d76d1        11d41984        IDT 76d1
111d76e0        11d4198b        IDT 76e0
10ec0269        11d41984        Realtek ALC269
10ec0889        10ec0885        Realtek ALC889
10ec0889        11d41984        Realtek ALC889+inputs
10ec0892        10ec0885        Realtek ALC892
10ec0662        10ec0885        Realtek ALC662
10ec0882        10ec0885        Realtek ALC882
10ec0883        10ec0885        Realtek ALC883
10ec0887        10ec0885        Realtek ALC887
10ec0888        10ec0885        Realtek ALC888
111d7603        11d41984        IDT 7603
111d7605        11d4198b        IDT 7605
11d4989b        11d4198b        ADI AD2000B
11060441        11d41984        VIA VT2021

%

 

Note: Since there is debate as to which codec to use for alc889, I offer two choices above. I could just take the patch codec id as an optional argument, what do people think?

 

Update: I added a bunch more codecs (including all the codecs that HDA wizard had).

[TimeWalker75a]

Good job, bcc9!! Will give this a try when I get home.

[TimeWalker75a]

Tried the 0.5 here on my ALC269 (which I have added to the script, the patch_id is 0x11d41984) and ALC888 and it fails for 10.7 kext apparently:

 

~ g00dman$ sudo perl /Users/g00dman/Desktop/patch-hda.pl 10ec0269
Patching AppleHDA codec 11d41984 with 10ec0269
2 codec range comparison(s) to patch
Patching range comparison 10ec0884
Patching range comparison 10ec0885
Unexpected codec match count: 4 (2 expected)
Aborting with AppleHDA NOT patched

 

Same with the ALC888:

~ g00dman$ sudo perl /Users/g00dman/Desktop/patch-hda.pl 10ec0888
Patching AppleHDA codec 10ec0885 with 10ec0888
No codec range comparisons require patching
Unexpected codec match count: 4 (2 expected)
Aborting with AppleHDA NOT patched

The kext I was trying to patch is from 10.7.4 (2.2.0f3)

 

Whilst for the kext from ML (from the MAS) it worked for both of the codecs:

~ g00dman$ sudo perl /Users/g00dman/Desktop/patch-hda.pl 10ec0269
Patching AppleHDA codec 11d41984 with 10ec0269
2 codec range comparison(s) to patch
Patching range comparison 10ec0884
Patching range comparison 10ec0885
/Users/g00dman/Desktop/AppleHDA.kext/Contents/MacOS/AppleHDA patched successfully.

 

~ g00dman$ sudo perl /Users/g00dman/Desktop/patch-hda.pl 10ec0888
Patching AppleHDA codec 10ec0885 with 10ec0888
No codec range comparisons require patching
/Users/g00dman/Desktop/AppleHDA.kext/Contents/MacOS/AppleHDA patched successfully.

 

I can't test the ALC269 patch for ML since I have reverted back to 10.7.4 for now as I was experiencing a lot of problems with my laptop.

The 269 is more tricky to get working (as it needs 2 range comparison patching) so it would've been interesting to see if it works, but oh well...

Will give my ALC888 a test and update this post thereafter.

 

UPD:

 

Yup. ALC888 works absolutely fine in 10.8. But then again, i have never had problems with it .. just swapping 885 out with 888 always used to do the trick, whereas ALC269 left me puzzled for some time even in 10.7.

[bcc9]

Tried the 0.5 here on my ALC269 (which I have added to the script, the patch_id is 0x11d41984) and ALC888 and it fails for 10.7 kext apparently:

 

~ g00dman$ sudo perl /Users/g00dman/Desktop/patch-hda.pl 10ec0269
Patching AppleHDA codec 11d41984 with 10ec0269
2 codec range comparison(s) to patch
Patching range comparison 10ec0884
Patching range comparison 10ec0885
Unexpected codec match count: 4 (2 expected)
Aborting with AppleHDA NOT patched

It works for me, maybe you edited the script wrong?

./patch-hda.pl 10ec0269
Patching AppleHDA codec 11d41984 with 10ec0269
2 codec range comparison(s) to patch
Patching range comparison 11d41983
Patching range comparison 10ec0884
AppleHDA patched successfully.

When it says "Unexpected codec match count: 4 (2 expected)" that suggests that you're running 10.8 not 10.7 but you said you were running 10.7... Under 10.7, there are 4 matches expected (2 routines and 2 architectures since AppleHDA is FAT)...

 

sw_vers -productVersion reports 10.7.4 for you in this case??

[TimeWalker75a]

Oh, I see now.

I indeed was trying to patch the 10.7.4 kext while running 10.8 .. so this is the reason it failed. Will pass the script to my lappy and try it from there. Thanks for clarifying, should have looked closer that it uses sw_vers -productVersion to determine OS version. Silly me. Will report back shortly.

[bcc9]

Oh, I see now.

I indeed was trying to patch the 10.7.4 kext while running 10.8 .. so this is the reason it failed. Will pass the script to my lappy and try it from there. Thanks for clarifying, should have looked closer that it uses sw_vers -productVersion to determine OS version. Silly me. Will report back shortly.

Ok, good.

The script should probably take a root dir argument and then look in /System/Library/CoreServices/SystemVersion.plist for the OS version number, then it'd be easier to work on multiple volumes.

[TimeWalker75a]

Would've been more flexible to check the version number of version.plist in the AppleHDA.kext., if it's anything lower than 2.3.0f2 then the comparisons for 10.7 should be used, if it's 2.3.0 or above - the ones for 10.8. This way you are not dependent on the version of the OS you're currently running.

 

Also, I can report the audio working for my ALC269 under 10.7.4 with no assertions what so ever .. (patching AD1984B out)

~ johnshepherd$ sudo perl /Users/johnshepherd/Desktop/patch-hda.pl 10ec0269
Patching AppleHDA codec 11d41984 with 10ec0269
2 codec range comparison(s) to patch
Patching range comparison 11d41983
Patching range comparison 10ec0884
/Users/johnshepherd/Desktop/AppleHDA.kext/Contents/MacOS/AppleHDA patched successfully.

 

Brilliant work again, bcc9!

[bcc9]

Would've been more flexible to check the version number of version.plist in the AppleHDA.kext., if it's anything lower than 2.3.0f2 than the comparisons for 10.7 should be used, if it's 2.3.0 or above - the ones for 10.8. This way you are not dependent on the version of the OS you're currently running.

Hmm, but people cut&paste their AppleHDA Info.plists so I don't really want to look there. This does work:

chomp($osxvers = `/usr/libexec/PlistBuddy -c 'Print ProductVersion' $root/System/Library/CoreServices/SystemVersion.plist`);

so I'll add it.

It's great that the range comparison patches are auto-generating OK, I didn't even have a test case for the two range check case.

[TimeWalker75a]

Hmm, but people cut&paste their AppleHDA Info.plists so I don't really want to look there. This does work:

chomp($osxvers = `/usr/libexec/PlistBuddy -c 'Print ProductVersion' $root/System/Library/CoreServices/SystemVersion.plist`);

so I'll add it.

It's great that the range comparison patches are auto-generating OK, I didn't even have a test case for the two range check case.

 

It's not the info.plist I'm talking about, but the version.plist. nobody in their right mind would ever need to touch it.

This one: http://puu.sh/Oddz

Just parse this part

<key>CFBundleShortVersionString</key>
<string>2.3.0</string>

If it's anything lower than 2.3.0 - use 10.7 comparisons, else use the ones for 10.8.

 

Swapped out the code snippet and just tried patching 10.7.4 kext while running 10.8 and of course it failed again, cause it's getting the same version number, but from different place.

Patching AppleHDA codec 10ec0885 with 10ec0888
No codec range comparisons require patching
Unexpected codec match count: 4 (2 expected)
Aborting with AppleHDA NOT patched

 

Well, I guess if I was to patch the kext on another actual partition where 10.7.4 was installed it would have worked. But as I'm not patching the kext in the system folder, but on my desktop rather, because I have to tamper with the resources anyway...

[bcc9]

Swapped out the code snippet and just tried patching 10.7.4 kext while running 10.8 and of course it failed again, cause it's getting the same version number, but from different place.

My idea was if you were running a different version of the OS than you were patching, the invocation would be:

patch-hda.pl -r /Volumes/path-to-mount-point ....

which would set $root= /Volumes/path-to-mount-point

and then the OS version would match as expected.

[TimeWalker75a]

Yeah, I got it after I thought about your original intention to patch the kext in the system folder. From my point of view, it would have been more convenient and mor flexible to determine the kext version, instead of checking the version of the OS. This way you have more flexibility in terms of where you are trying to patch your kext. I guess very few people would need the kext patched in their system folder after they update, cause it would still require to swap the resources and info.plist and for this you need your kext out of S/L/E anyway.

 

If going the route of determining the kext version may as well make it default to be patched on desktop. Just get the username with 'whoami' to determine the homefolder name. or just use ~/Desktop instead ...

 

So the sequence would be as follow:

1. cp the kext from S/L/E to ~/Desktop

2. determine the kext version by parsing the version.plist

3. apply the necessary binary patch

4. cp the kext over to S/L/E set permissions and touch to update the cache.

 

If you skip the 1. step and make the user copy the kext to Desktop, this would allow a user to swap all the resources and info.plist out after an update and then run the script to do the finishing touches. You may have to add another input argument for step 4. because some might just need the patching to be done to pass the kext to another machine or volume.

[masa]

Thank you ErmaC, I just tested the updated kext but with no luck.

It is very weird because when I use the AppleHDA, i will not be able to use any USB mouse or keyboard, I have to turn off my pc by the power button.

 

I thought the DSDT is suspicious, but I can control my mouse if I just remove AppleHDA from /S/L/E with leaving the dsdt there.

 

Tried 2 pattern of HDEF in dsdt, one just copied yours and my original shorter one with only ID modified.

 

Could you give me some advice? Thanks!

 

Hi guys.

my mistake.

I forgot to change the layout also in the Info.plist.

 

I correct the file in the previous post and posted the patched (complete) kext for AD2000b..

enjoy

 

Fabio

[bcc9]

I think the normal case is one installs/upgrades osx, and wants to fix AppleHDA in /S/L/E directly (either in the booted volume or a mounted one). I don't get why you think copying around AppleHDA is the normal case. When I provide scripts at insanelymac that require the user to do the copying, then a bunch of user questions pop up where they have trouble with their permissions and figuring out how to install.

For power users, you can specify the directory with -s. In that case I'll make the script try to guess the OS version from kext version. I think that's the best compromise.

[TimeWalker75a]

It is the best compromise indeed.

For some reason I always assumed that to swap out resources in a kext in S/L/E directory it needs to be copied from there to somewhere, otherwise permissions that are set for a given kext wouldn't allow editing it.. but then I recalled that this only applies to text-based files (this is when sudo nano comes around )... silly me again ...

[HELLFISH]

Hmmm. Perhaps someone can help me here, but I use the GA-EG45M-UD2H motherboard, which has 889A audio. However, something is strange with it, as no 889A regular methods will work. Not even in Lion. The only way I have ever been able to get sound is by using layout-id 885 and original snow leopard AppleHDA 10.6.0. Any newer AppleHDA, no sound. Anyother layout-ID, no sound.

 

I've pulled my codec information and pin configs from linux/windows and have attempted to get the sound working, but I always fail.

 

Using the ALC885HDA_Lion_MLion_V1-1.00, I see my layout is nearly identical to layout36. Only the Front Mic (pink) 0x1A and Rear LineIn (blue) 0x19 are swapped. So, I set layoutID in DSDT to 0x24. I then copy ALC885HDA.kext to S/L/E. I then copy layout36.xml.zlip and Platform.xml.zlip to AppleHDA.kext/Contents/Resources/

 

After permisions and cache rebuild, I still have no sound on reboot.

 

I also tried inserting PinConfig to ALC885HDA in layout36 section and in AppleHDAHardwareConfigDriver, but still no sound.

 

Perhaps I am forgetting something, or my head is just not big enough to understand o_O

card0-codec#2.txt

[CutOffz]

@masa and ErmaC

The same here. It took an eternity to boot ML after installing the new kext. After booting, no audio device found. I really don't know why, however i'll switch back to 10.7.4 now, cause the laggy booting makes me crazy! I hope ErmaC will find a solution. I'll keep on testing :-)

 

Tnx CutOffz

 

Thank you ErmaC, I just tested the updated kext but with no luck.

It is very weird because when I use the AppleHDA, i will not be able to use any USB mouse or keyboard, I have to turn off my pc by the power button.

 

I thought the DSDT is suspicious, but I can control my mouse if I just remove AppleHDA from /S/L/E with leaving the dsdt there.

 

Tried 2 pattern of HDEF in dsdt, one just copied yours and my original shorter one with only ID modified.

 

Could you give me some advice? Thanks!

[bcc9]

Ok, I've updated the script to version 0.6, with the new OS version parsing:

First, if the working directory (-s switch) is not /S/L/E, check the kext version

Second, check /S/L/CoreServices/SystemVersion.plist on the target volume

Third, check the version of the running system

 

and also you can override the OS version manually with -o

[TimeWalker75a]

Ok, I've updated the script to version 0.6, with the new OS version parsing:

First, if the working directory (-s switch) is not /S/L/E, check the kext version

Second, check /S/L/CoreServices/SystemVersion.plist on the target volume

Third, check the version of the running system

 

and also you can override the OS version manually with -o

Grea work there! Will give all of the scenarios a test when I get home.

[TimeWalker75a]

Ok, I remembered I don't have any installations on the other volumes, so I can't really test the case of patching the kext on another volume.

However I've tested the patch in S/L/E and it works absolutely fine, so does the -s argument:

 

bash-3.2# sw_vers -productVersion
10.8

bash-3.2# perl /Users/g00dman/Desktop/patch-hda.pl -s ~/Desktop/ 10ec0888
OSX version 10.7 detected
Patching AppleHDA codec 10ec0885 with 10ec0888
No codec range comparisons require patching
/Users/g00dman/Desktop//AppleHDA.kext/Contents/MacOS/AppleHDA patched successfully.

[xxmacmanxx]

Hello everybody,

 

I'm reading this thread with a lot of interest, because I want to understand how this patching works. But since Snow Leopard I never was able to do this on my own and downloaded some preedited kexts, which actually work pretty well (Thanks, toleda).

 

I have read through this thread, but I've found that none of you is using my codec: ALC887

 

So, please be patient with me as I do not fully understand what I need to do get it working.

 

But I try:

 

So first of all I need to patch my AppleHDA by running this command:

 

sudo perl -pi -e 's|\x85\x08\xec\x10|\x87\x08\xec\x10|g' /System/Library/Extensions/AppleHDA.kext/Contents/MacOS/AppleHDA

 

And then you write about layout.xml.zlib and platforms.xml.zlib. Where do I get them and do I need them? What has to be done to get my codec working? My DSDT is already patched with HDEF.

 

Again, I'm sorry to interupt your discussion with my noobish questions, but I really do not know what I should do for my codec.

 

Greetings,

xxmacmanxx

[TimeWalker75a]

Well, to understand thing more clearly i guess you ought to read another thread .. the one that tells you the basics:

http://www.projectos...wtopic=465&st=0

 

Even though the info posted there might seem totally off considering the structure of the kext as of later OS versions, but the basic principles of finding your node complexes and describing them still apply. Just on top of that you will be required to do a binary patch and use a compatible layout number(one of those found in the resources folder of the kext).

It's just now the pathmaps are located in the Platforms.xml.zlib file which you need to decompress (with a tool provided somewhere in this topic), edit according to you codec's data and compress back again. The node (read port) configuration is layoutXX.xml.zlib .. same thing with them - decompress, edit, compress. The config data or pinconfig in other words is a plist file located in a hardwareconfig plugin of the AppleHDA.kext.

 

If you had a previously working kext from 10.7.x it should ease the work for you just a little. If you know the layout id you were using you can use the layoutXX.xml for the ports configuration, the info.plist to get the pinconfig for the given layout and look for the working pathmap in your Platforms.xml by comparing the pathmap numbers from the working kext. Then you would just adapt all of these for a new architecture of the kext..

 

Also I suggest you try using bcc's new perl script posted on the page 4 of this topic, it will do binary patch work for you. Even though a one-liner patch could seem just enough.

[Micky1979]

You can't use the old patched one, it is incompatible with the new zlib architecture in ML. You have to use ML vanilla one, that comes with the install.

In 10.7 he was using the stock one until i had patched the 10.7.4 recently, he is using it as of now for his 10.7 install and for 10.8 there's no solution since sources are not out yet.

He has no DSDT modifications for HDEF, he uses layout injection through Clover settings:

<key>PCI</key>
<dict>
<key>HDAInjection</key>
<string>12</string>
</dict>

I have been chatting with him a lot lately.

 

Sorry if it seems silly:

 

you could use AppleHDA from 10.7.4 in ML, with inside layout.xlm and Platform.xlm compressed in .zlib?

 

Has anyone tried it?

 

I can not try because my Lappy is on HP Service :censored2:

 

 

(I'm on ML on a old machine, such as forklift, I will not work on this PC for long........hope)

[DoiX]

@Micky, in my case, Lion AppleHDA is working fine in ML but it messes up the UseKernelCache=No load thus why i wanted to get the ML drivers patched.

 

HDAInject isn't working in my case, could be because of the DSDT or Clover is just force injecting the hda id instead of what i chose to inject.