bcc9

Perhaps the site admins can fix the links to the attachments. Most links in post #1 are to attachments in post #1. These used to work just fine; I assume one of the site outages broke things.

I think you need to ask pedah about ati-kext-utility, I only wrote the perl script in this thread and cobbled together readeon_bios_decode. I've never tried ati-kext-utility myself.

Whenever I have trouble with unintended resume from suspend, I first look at /var/log/system.log for clues, as the wake reason is reported there. Sometimes the wake reason doesn't make sense, but often it tells you that it's a USB event and then you can start tearing down your USB usage to isolate what is going wrong. Otherwise it's typically a misbehaving kext, and rolling back your tweaked kexts is a good way to narrow it down. As far as I know, hibernation on hackintoshes has been broken since 10.7, as nobody has bothered to replicate the genuine mac encryption. Thanks, that's not too much $$, but less than 1/2 what the smaller 6 cell battery is supposed to provide, so not very good capacity. You can watch maybe 45 minutes of video before the battery is dead with that capacity, I think.

Hi everybody, As you've probably noticed, I've been winding down support on this system as I believe everything "just works" if you use a generic install with chameleon as in post #1. For a long time, most reported problems have simply been due to using other install methods such as those found over at tonymac. Since I don't use these other installers I really can't tell you what is going wrong, other than to point you back to prior posts where there is the troubleshooting information on how to figure out for yourself where your problem is. Regarding, QE/CI, the immediate way to tell if this is working is to see if the nvidia kexts are loaded and running vs the generic kexts. Without the nvidia accelerated kexts, video playback performance will be poor. Video intensive applications such as final cut will refuse to even run. And you'll be unable to use a dual monitor setup, outputting from the hdmi to a tv for example. Regarding Slack21's Q on lid close, you do of course need to have AppleACPIPlatform patched, per post #1. My old 1340 is in my spare parts closet now as I don't think the lithium battery even works anymore. I suspect it's not worth buying a replacement battery, as the replacement battery would probably be half dead as well from sitting on a parts shelf for years. Am I right?

Yes, of course, works for me , etc. etc.

The wiki under-specifies the syntax for find/replace, and includes examples of both hex and base64. The code clarifies that both are in fact legal formats, and there are several commands that take find/replace strings with hex, not just the one in question (the ati driver patch commands come to mind, though the keyword is different). So this other configuration program must be able to handle hex strings, and it's simply a bug that it is failing to do so in this case. As for perl, sure, I'm not an expert either, but clearly converting in&out of a format needlessly is not great and isn't something I'd integrate. Certainly an option to output base64 directly would be easy, though I still maintain that the result is unreadable whereas the current output is readable...

Yes, I know xxd does, but it's rather senseless to convert from integer to hex string, back to binary, then to base64. My patch_codec routine already converts to binary, no xxd required. Perl even has base64 conversions functions available, though I haven't checked whether osx ships with these. The wiki page you list is one of the ones I checked before making my xml code, and it includes an example that uses find/replace with hex as a string. The example doesn't work for kext binary patching though, as the example prefixes the hex strings with 0x, but that doesn't parse. Since the wiki is wrong, I had to check the code to see what is really supported, and that's how I knew how to format the hex strings correctly. Per clover's GetDataSetting() routine: "data can be specified in <data></data> base64 encoded or in <string></string> hex encoded "

1. That sounds like a bug in clover configurator that should be fixed there, not here. The hex output is actually readable since the patches are just for hex codec ids. Converting the patches to data strings makes the patches unreadable. 2. I don't like your change as having perl convert the numbers to hex strings and then externally forking xxd to convert them back makes no real sense. The XML I'm generating works as is if you aren't using clover configurator.

Thanks for the bug report on hex parsing & analysis. Now I get why you were using the "Nexant" shorthand in that codec table change. So perl's built-in hex() function isn't sanity checking its input like I expected; I've added my own checking instead, and posted this as version 3.4. Also, in the codec map tables, I renamed the new "Nexant" entry to Conexant, to match the other entries.

Thanks. How about an <expect> XML keyword that takes an argument that is a number or a range, representing the number of times the <find>/<replace> pair should match? For example <key>expect</key><string>2</string> or <string>0-2</string> If the find/replace doesn't match the right expected number of occurrences, log an error. Yes a wiki will always be a moving target, never "done". But a wiki knowledge base built off of the popular, working guides could cut down on the need for so many newbie guides. Less to moderate at that point.

Ok, I've posted a new version that includes support for outputting a clover compatible XML configuration, instead of patching AppleHDA directly. The new version number is 3.3. New command line switch -x to enable this XML output. Example: % ./patch-hda.pl 10ec0892 -c 2 -x OSX version 10.9.2 detected Default target codec: 10ec0892 detected. Patching AppleHDA codec 11d4198b with 10ec0892 1 codec range comparison(s) to patch Patching range comparison 11d41984 <dict> <key>Name</key> <string>AppleHDA</string> <key>Comment</key> <string>Expect 2 matches</string> <key>Find</key> <string>8419d411</string> <key>Replace</key> <string>00000000</string> </dict> <dict> <key>Name</key> <string>AppleHDA</string> <key>Comment</key> <string>Expect 2 matches</string> <key>Find</key> <string>8b19d411</string> <key>Replace</key> <string>9208ec10</string> </dict> % The above example works for me on my z87 system. Now if clover would take an expect count here and report an error when there isn't a match, that'd make this work a lot better I think.

Generally speaking I don't like making the match string contain extra stuff that isn't being changed just to lower the chance of a false match. I think it'd be much better for the syntax to support an expect count, so the program can throw a warning if the match is being potentially mis-applied. The perl script does this now. Going ahead and supporting a syntax for clover that doesn't allow for this is a bit of a step backwards. But if everyone is happy with sloppy matching, I can make this script output the XML as is... I think there are almost no cases where this has been burning folks so far. Yes, and it'd be debatable whether there really is any violation going on. I just don't want to be putting up any such web page myself. Yes, that seems like the right place. I wasn't sure that was really being maintained; all the tech details seem to be buried into 1 flat FAQ. If the FAQ was broken out into a knowledge base for the main problem categories: Sound, video, bootloader, etc., then perhaps this info would be a sub-item within the main audio/sound knowledge base category.

Right, the target codec can already be specified as a number, just not the patch codec, currently. Proper sanity checking on the patch codec would be a bit messy (it should ideally match one of the real codec ids found in AppleHDA). But it wouldn't be hard to make the command line just accept a full hex codec ID without performing any checking... It would be pretty easy to spit out some XML for the user to apply, slightly harder to auto-patch an XML config file with the changes. Does clover yet have a config syntax that is standard&safe against aliasing? http://clover-wiki.zetam.org/Configuration/KernelAndKextPatches just shows Find/Replace operators, which leaves open the chance that the runtime-patch is going to be mis-applied. patch-hda.pl is careful to make sure that the number of matches found exactly match what is expected (to avoid any issues with false matches). Find/replace does not... In general I would think a US hosted server may not be a great choice for projects that are about binary patching OSX, because of potential DMCA claims. But I'm not a lawyer, etc., etc.

Thank you for the updates, I've merged these together plus pokenguyen's old change. Will add to post #1 in a moment. Obviously I'm doing a bad job having the time to maintain edits to this list myself. Seems like this would be better maintained via a wiki. Does insanelymac have a wiki for such things?

Scripts can't read the user's mind, but they can have a lot of intelligence. A relatively dumb script could read the PCI id of the video card, and spit out the best-commonly used patch for that card. A more intelligent script could read the video bios, parse the connectors, and output a patch for the connectors that were found. And so on. And, if the above syntax were more general, it could be used by both clover&chameleon, at which point there would be more reason to make a script to auto-generate the config statements.