gfoury

Oops. I forgot to do a git push. "Your branch is ahead of 'origin/master' by 7 commits." Try it now: https://github.com/gfoury/clover-config-plist-tools I will check out Enoch.

Hotpatching is not the solution to everything. We need to keep MaciASL patches around as a viable method no matter what, since text patching is considerably more powerful and understandable. I think there are many more patching guides using text patches. For new platforms, the first patchsets are going to be done in text. I don't want to lock out Chameleon--I'm using it right now on a couple machines.... I haven't tried this yet, but I think there's a way a Chameleon user can use a pure hotpatch set, although manually. Get the native AML files for the machine Get the Clover config.plist from the hotpatch you want to use. Feed the config and AMLs into check-dsdt-patches.py, and use the -d option. All the enabled binary patches in the config.plist will be applied to all AML files, and the results written into the output directory. Include the hotpatch's small SSDTs (SSDT-HACK etc) in what Chameleon loads I wrote the check-dsdt-patches.py utility to compare patched/unpatched AML files to make sure my patches are doing what I expect. Might be useful for other things. RehabMan has moved many of his repositories to using arbitrary device injection, a Clover feature I don't have a tool for. Maybe I should make one. I'm getting increasingly off-topic, but is there a best Chameleon for 10.11?

Thanks for the information. I don't think I'm having problems, but I'll mimic the behavior of your patch more closely. You can skip the rest of this post; it's just for background information. Instead of replacing the ACPI tables, I'm using RehabMan's "hotpatch" technique. This uses Clover's ACPI binary patching in combination with newly created SSDTs. For example, you can supply your own GPRW, as long as there is no conflict with an existing GPRW method. If you examine the Lenovo Z50 ACPI tables in Hex Fiend, you can get rid of the existing one with a binary patch of "GPRW\x02" to "XPRW\x02". Disassembly of the binary-patched AML files shows that the only "Method(GPRW, 2)" has been renamed to "Method(XPRW, 2)". So our own GPRW will now load successfully. Why would you use hotpatches instead of text-based MaciASL patches? It is more likely to survive BIOS updates; if the ACPI tables have been fixed elsewhere, hotpatching will keep the fixes. It is simpler for users. They can't miss a step in patching. All they need are the new SSDT files and a config.plist. (However, it is more work to create the patches in the first place.) It is possible the patches may work directly on other models in the same product line. The ACPI tables for the ASUS UX305FA are different than the UX303LA, but the parts of DSDT that we want to patch are identical. Anyway, it can be a fun puzzle too. (I see jhawk on this thread. His guide for the UX305FA was really, really helpful.)

I have some questions about the DSDT patch for ALS (Haswell). I'm not an ALS user, but I'm patching the UX305FA, and I'd like to avoid messing up the ALS for people who do want it. In the UX305FA native DSDT, the _QCD method calls ATKD.IANE(0xC6), not ATKD.IANE(0xC7). (There is no _QDD.) Is there a good reason to switch _QCD to 0xC7? Also, the native RALS method appears to be identical to the one in "ALS Patch (Haswell)" except that if the sensor is disabled, the native DSDT returns 0x190 (instead of your patch's 0x12C). Is this a significant enough difference that I need to binary-patch the DSDT to return 0x12C?