234 replies to this topic

[bcc9]

TimeWalker75a, on 03 August 2012 - 07:34 AM, said:

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]

TimeWalker75a, on 03 August 2012 - 08:27 AM, said:

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]

TimeWalker75a, on 03 August 2012 - 08:45 AM, said:

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]

bcc9, on 03 August 2012 - 08:58 AM, said:

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]

TimeWalker75a, on 03 August 2012 - 09:06 AM, said:

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!

.: ErmaC :., on 02 August 2012 - 07:07 PM, said:

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

Attached Files

•  card0-codec#2.txt   17.19K   10 downloads

[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

masa, on 03 August 2012 - 05:33 PM, said:

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]

bcc9, on 03 August 2012 - 10:19 PM, said:

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]

TimeWalker75a, on 18 July 2012 - 05:29 PM, said:

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


(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.