EMlyDinEsH Posted March 1, 2016 Author Share Posted March 1, 2016 Hi, I have a notebook asus N56JR.. I have a problem with brightness regulation [ Fn+ F5 ; Fn+F6 don't work]. I used the kext AsusNBFNkeys v2.5.5 (present in this site) and i tried to modify my DSDT.aml (Q0E e Q0F how explain in this site) but without success Then I tried to use "another DSDT.aml " and with my surprise work bluetooth and webcam (ASUS USB2.0 Webcam)!! but resolution it's wrong and another things such as all "Fn keys" I ask if it's possible mix my DSDT.aml (with corrections about brightness regulation) with the work part (bluetooth and webcam) of the "another DSDT.aml" . Help please Another DSDT is using my DSDT patches thats why they are working. Did you try applying attached DSDT patches ? Let me know if you still need help so i can patch for you. 1 Link to comment Share on other sites More sharing options...
EMlyDinEsH Posted March 1, 2016 Author Share Posted March 1, 2016 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? It can be 0xC6 or 0xC7, so it does not matter. For ALS, better use my patch instead. If you have issues then let me know so i can take a look and help to tweak it. Link to comment Share on other sites More sharing options...
mariano Posted March 2, 2016 Share Posted March 2, 2016 Another DSDT is using my DSDT patches thats why they are working. Did you try applying attached DSDT patches ? Let me know if you still need help so i can patch for you. Hello. I did not understand as I do . Now I'm using a new DSDT ; this works with everything except the "stop " (sleep mode ) that works with another DSDT now attach too. Could you please put the two DSDT to create a fully functional ? thank you DSDT(all work, no sleep).rar DSDT(sleep work).rar Link to comment Share on other sites More sharing options...
gfoury Posted March 2, 2016 Share Posted March 2, 2016 It can be 0xC6 or 0xC7, so it does not matter. For ALS, better use my patch instead. If you have issues then let me know so i can take a look and help to tweak it. 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.) Link to comment Share on other sites More sharing options...
Administrators Bronxteck Posted March 2, 2016 Administrators Share Posted March 2, 2016 the only issue with hot patching though is people do also use chameleon which does not have clovers ability to patch on the fly, hence the need for a binary in that scenario. Link to comment Share on other sites More sharing options...
gfoury Posted March 2, 2016 Share Posted March 2, 2016 the only issue with hot patching though is people do also use chameleon which does not have clovers ability to patch on the fly, hence the need for a binary in that scenario. 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? Link to comment Share on other sites More sharing options...
Administrators Bronxteck Posted March 3, 2016 Administrators Share Posted March 3, 2016 there seems to be an issue with your github link you provided but your script sounds very interesting. as for chameleon enoch branch has the latest developments trunk source is not updated as frequently as it should be. Link to comment Share on other sites More sharing options...
gfoury Posted March 3, 2016 Share Posted March 3, 2016 there seems to be an issue with your github link you provided but your script sounds very interesting. as for chameleon enoch branch has the latest developments trunk source is not updated as frequently as it should be. 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. Link to comment Share on other sites More sharing options...
EMlyDinEsH Posted March 5, 2016 Author Share Posted March 5, 2016 Hello. I did not understand as I do . Now I'm using a new DSDT ; this works with everything except the "stop " (sleep mode ) that works with another DSDT now attach too. Could you please put the two DSDT to create a fully functional ? thank you I need your unpatched DSDT from your dump also. Also give me your system specs and ioreg file (save using IORegExplorer app v2.1) 1 Link to comment Share on other sites More sharing options...
EMlyDinEsH Posted March 5, 2016 Author Share Posted March 5, 2016 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.) Your hotpatching sounds interesting and good one too, but need skills in order to make them at first. Please PM me for discussing this more in detail as we might me able to use your work in help users in our EDP app if you are interested, so we can work along to keep this updated for everyone as a simple solution. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now