Contribute
Register

[Guide][New VoodooI2C] Asus Vivobook S15 X510UAR 10.13+

Last edited:
kcstudiohk said:
thx, i have been updated

[solved] CodecCommand.kext not owned by root , fixed and work
Thanks all for this project ! Bravo !
Click to expand...
Correct, that is necessary for this kext for some reason:

sudo cp -R CodecCommander.kext /Library/Extensions
sudo chmod -R 755 /Library/Extensions/CodecCommander.kext
sudo chown -R root:wheel /Library/Extensions/CodecCommander.kext
sudo kextcache -i /

Install script attached. Just place next to CodecCommander.kext and double click.

or use latest Kext Utility if you prefer GUI (KCPM Utility Pro might not be sufficient).

Cannot test HDMI audio because I don't have an appropriate device to connect.
saintno1997 said:
New update! All function working for now :D
Click to expand...
saintno, here's my test results feedback for you:

1) MaciASL compile errors remain. Tried both, first your new EFI folder form github, then with the files you attached in your zip - same errors. Saintno, in MaciASL, can you please go into Prefs (cmd ,), iASL, click onto update iASL, close Prefs, and hit compile again?

If you still don't get any errors with your hotpatched DSDT, please download my package here and open "DSDT with compile errors (via patchmatic)/DSTD.dsl in MaciASL. You can also decompile DSDT.aml via "aml2dsl all files HERE.command" in that folder. You can than see yourself what I mean.

It's with 100% certainty one or more of the hotpatches which does not apply to ALL Vivobook S15 models depending on motherboard.

2) Patched UsbInjectAll: that sounds fantastic. I only see 9 XHC USB ports anymore in IOreg, vs. the 18 from before. That should eliminate the need for a patched SSDT-UIAC, I would say? I already see my BT discovery working in 10.13.6 WITHOUT port limit patch now - CHEERS!!

3) VoodooI2C by hieplpvip / @baohiep : as before I went back to your VoodooI2C kexts, because @baohiep 's are a regression for me:
- for highlighting text, there is only a very small "sweet spot" right to the left of the middle bar marker on the bottom of the trackpad. If I miss that, no highlighting but contextual menu (right or secondary click) instead.

- same with dragging, for examples windows: if I miss that "sweet spot", no dragging...

- for me, acceleration is set too high and not adjustable.

Hopefully you can edit at least the area for left press and hold - it needs to be enlargened upwards, for people with even just a little bit larger hands. Probably you have smaller hands and fingers and always touch lower. Until then, please don't abandon your compile but add it again either as a choice, or maybe better the other way around until hieplpvip / baohiep's VoodooI2C has been edited to be more compatible.

4) Config.plist: three requests/ recommendations:

a) best please remove your EDID under Graphics and add it separately as a text file for your BQ414T (BQ414T-EDID.txt). Remember mine is different, and I am not sure if there could be any negative side effects when injecting an inappropriate EDID

b) in Kernel and Kext patches, include the two patches "Prevent Apple I2C kexts from attaching to I2C controllers, credit CoolStar" from RehabMan/OS-X-Clover-Laptop-Config (attached). These are essential for all which do follow the guideline and install all kexts also to /L/E. Without these patches, trackpad WILL not work with kexts from /L/E.

c) just a suggestion: in GUI, activate "Custom Icons". Advantage: volumes with custom icons are displayed with such. If no custom icon, Clover theme icon will be used. Should be enabled by default, but isn't.

5) with CPUFriend, does your CPU Package Frequency in HWMonitor ever go down below 800 MHz, as before with the plist directly modded via freqVectorsEdit.sh, when it would go down to 600 MHz every once in a while (and potentially all the way down to 400 MHz on full idle)?

That's it for now. Thanks again for all the motivation, and progress !!!
 

Attachments

  • coolstar's VoodooI2C KextsToPatch entries.zip
    35.5 KB · Views: 83
  • install CodecCommander.zip
    1.4 KB · Views: 77
Last edited:
bugsb said:
Correct, that is necessary for this kext for some reason:

sudo cp -R CodecCommander.kext /Library/Extensions
sudo chmod -R 755 /Library/Extensions/CodecCommander.kext
sudo chown -R root:wheel /Library/Extensions/CodecCommander.kext
sudo kextcache -i /

Install script attached. Just place next to CodecCommander.kext and double click.

or use latest Kext Utility if you prefer GUI (KCPM Utility Pro might not be sufficient).

Cannot test HDMI audio because I don't have an appropriate device to connect.

saintno, here's my test results feedback for you:

1) MaciASL compile errors remain. Tried both, first your new EFI folder form github, then with the files you attached in your zip - same errors. Saintno, in MaciASL, can you please go into Prefs (cmd ,), iASL, click onto update iASL, close Prefs, and hit compile again?

If you still don't get any errors with your hotpatched DSDT, please download my package here and open "DSDT with compile errors (via patchmatic)/DSTD.dsl in MaciASL. You can also decompile DSDT.aml via "aml2dsl all files HERE.command" in that folder. You can than see yourself what I mean.

It's with 100% certainty one or more of the hotpatches which does not apply to ALL Vivobook S15 models depending on motherboard.

2) Patched UsbInjectAll: that sounds fantastic. I only see 9 XHC USB ports anymore in IOreg, vs. the 18 from before. That should eliminate the need for a patched SSDT-UIAC, I would say? I already see my BT discovery working in 10.13.6 WITHOUT port limit patch now - CHEERS!!

3) VoodooI2C by hieplpvip / @baohiep : as before I went back to your VoodooI2C kexts, because @baohiep 's are a regression for me:
- for highlighting text, there is only a very small "sweet spot" right to the left of the middle bar marker on the bottom of the trackpad. If I miss that, no highlighting but contextual menu (right or secondary click) instead.

- same with dragging, for examples windows: if I miss that "sweet spot", no dragging...

- for me, acceleration is set too high and not adjustable.

Hopefully you can edit at least the area for left press and hold - it needs to be enlargened upwards, for people with even just a little bit larger hands. Probably you have smaller hands and fingers and always touch lower. Until then, please don't abandon your compile but add it again either as a choice, or maybe better the other way around until hieplpvip / baohiep's VoodooI2C has been edited to be more compatible.

4) Config.plist: three requests/ recommendations:

a) best please remove your EDID under Graphics and add it separately as a text file for your BQ414T (BQ414T-EDID.txt). Remember mine is different, and I am not sure if there could be any negative side effects when injecting an inappropriate EDID

b) in Kernel and Kext patches, include the two patches "Prevent Apple I2C kexts from attaching to I2C controllers, credit CoolStar" from RehabMan/OS-X-Clover-Laptop-Config (attached). These are essential for all which do follow the guideline and install all kexts also to /L/E. Without these patches, trackpad WILL not work with kexts from /L/E.

c) just a suggestion: in GUI, activate "Custom Icons". Advantage: volumes with custom icons are displayed with such. If no custom icon, Clover theme icon will be used. Should be enabled by default, but isn't.

5) with CPUFriend, does your CPU Package Frequency in HWMonitor ever go down below 800 MHz, as before with the plist directly modded via freqVectorsEdit.sh, when it would go down to 600 MHz every once in a while (and potentially all the way down to 400 MHz on full idle)?

That's it for now. Thanks again for all the motivation, and progress !!!
Click to expand...
#1 I got error when compile system DSDT injected with hotpatch too, i think it normal, all the error line can be deleted except
Code: 
Store (SMBR (RDWD, BADR), Arg0)
            Local0
need change to
Code: 
Store (SMBR (RDWD, BADR, Arg0), Local0)
All function still work normally so i think it due to compiler !!
#3 yeah, i'll try to improve that
#4:
  • a. Done
  • b. Added! But my trackpad still work normally when push to C/K/O without disable that appleI2C kext!
  • c. Done
#5: CPUFriendProviver base in an modified plist by freqVectorsEdit.sh so it should do what freqVectorsEdit.sh done :D
 
saintno1997 said:
#1 I got error when compile system DSDT injected with hotpatch too, i think it normal, all the error line can be deleted except
Code: 
Store (SMBR (RDWD, BADR), Arg0)
            Local0
need change to
Code: 
Store (SMBR (RDWD, BADR, Arg0), Local0)
All function still work normally so i think it due to compiler !!
#3 yeah, i'll try to improve that
#4:
  • a. Done
  • b. Added! But my trackpad still work normally when push to C/K/O without disable that appleI2C kext!
  • c. Done
#5: CPUFriendProviver base in an modified plist by freqVectorsEdit.sh so it should do what freqVectorsEdit.sh done :D
Click to expand...
#1 (hotpatch DSDT compile errors): aha, there we go, good you did test .. ;) It's no use deleting the error lines since this is not a static DSDT. Even though all functions appear normally on the surface, when I revert back to static DSDT, first boot usually works, but from 2nd boot on kernel panic with instant restart. Same with power off completely before reboot. I already reproduced this misbehavior several times. Sometimes it helped to reapply the 303 BIOS which resets BIOS settings + redisable secure boot, but sometimes it didn't. MacOS would only boot fine without DSDT then. I then had to regain my DSDT via Clover (after removing existing DSDT.aml from C/A/patched) and repatch. On *.dsl compare I would see several differences in my 303 DSDT *before* messing with hotpatch and *after*. This should totally not be. Obviously the hotpatch DSDT does not fully match our Vivobook S15 DSDTs and "injects" wrong ACPI in a memory persistent way, "bending" it, resulting in kernel panic after reverting back to static.

This needs to be corrected. Unfortunately I am running out of time, having to deal with real life right now. I you still have a bit of time, all that needs to be done is grab the error list from MaciASL, disable 1st hotpatch in clover.config, reboot, MaciASL, compile, compare with list, not change(s) if any, and advance like this hotpatch by hotpatch, until the rogue one(s) is (are) isolated.

I sense this is significant to avoid hardware damage over time...

#4 b (CoolStar I2C patches): not pushed to C/K/O but /L/E .. ;) remember, Clover ONLY disables kexts to load from C/K/O when FakeSMC.kext is *also* installed to /L/E. Needless to say, then ALL kexts from C/K/O have to be installed to /L/E, not just FakeSMC and the trackpad kexts, to get to the login window, and beyond.

#5 (HWP Intel Speed Shift): shuhung's kext also stopped down-throtteling at 800 MHz. So far I have never seen the CPU package frequ. drop below 800 MHz with the 2 CPUFriend kexts, either. We might want to keep observing.

#2 (patched UsbInjectAll): BT discovery & connections still working even after several reboots, power off/ back on & sleep WITHOUT port limit removal patches, YES! Out of interest: what made you patch the kext, rather than create a custom SSDT? Was it easier/ simpler, or has advantages?

[EDIT]: sigh - it took much longer with your modded UsbInjectAll, but just now.. after wake-up from sleep, "Bluetooth: not available"...
so for now, back to port limit removal patch. If I want to get away from that, I'll have to create the custom SSDT... ordered a USB-C external hard disk enclosure so I can plug the USB-C port, too, for eliminating. Not a bad idea to have one, anyway.
 
Last edited:
saintno1997 said:
  • Patched UsbInjectAll for correct USB port and set WifiCard and Camera to build-in
Click to expand...
  • saintno, is it possible that - as you write - you indeed only set Wifi and Camera to internal but not Bluetooth? Even though both modules are on the same card, they have separate addresses under XHC. Why I'm asking see very bottom of my edited post...
 
Last edited:
bugsb said:
Yes thank you RehabMan, I have been following your guide. Compile errors with hotpatch are present regardless of disassembly procedures/ tools latest versions. With static patch DSDT, no Compile errors, again also regardless of disassembly procedures/tools. I am therefore back to static DSDT now.

These errors are completely new, never saw them before, so they positively come from 1 or more of the hotpatch entries. I do not know which tutorial saintno1997 used for creating the hotpatch entries.

Do you want to look at the files? I attached saintno1997's config.plist and my origin DSDT.aml from Clover & extracted .dsl via iasl -da -dl DSDT.aml, + extracted DSDT.aml via patchmatic & .dsl via iasl.
Click to expand...

Your mistake is "Just launch MaciASL"

Must always disassemble with SSDTs as context. With hotpatch, you should be disasembling patchmatic output with: iasl -da -dl DSDT.aml SSDT*.aml.
 
RehabMan said:
Your mistake is "Just launch MaciASL"

Must always disassemble with SSDTs as context. With hotpatch, you should be disassembling patchmatic output with: iasl -da -dl DSDT.aml SSDT*.aml.
Click to expand...
oh, you misunderstood or read to fast.. again, that's *exactly* what I did, followed your guide 100%. Launching MaciASL was just for checking if errors remain the same, which they do, that's all.

For you I this time I also included all SSDT amls, too, in attached zip, + all dsl via iasl -da -dl DSDT.aml SSDT*.aml.

Naturally, compile errors remain regardless if I open DSDT.dsl in MaciASL with or without SSDTs in the same folder next to DSDT.dsl. Not sure why you put emphasis on disassembling with SSDTs as context if these DSDT compile errors here are not effected by the SSDTs. I even removed all SSDTs from C/A/patched, reboot, extract, disassemble - same thing, compile errors. And kernel panics from this hotpatch are difficult to be imagination.

So Rehabman, can you give us a pointer from which hotpatch(es) the errors originate from? I bet you agree they need to be eliminated. Would be really awesome :) saintno's config.plist also in the attached zip
 

Attachments

  • patchmatic extract with config hotpatch incl. SSDTs.zip
    206.7 KB · Views: 54
bugsb said:
oh, you misunderstood or read to fast.. again, that's *exactly* what I did, followed your guide 100%. Launching MaciASL was just for checking if errors remain the same, which they do, that's all.

For you I this time I also included all SSDT amls, too, in attached zip, + all dsl via iasl -da -dl DSDT.aml SSDT*.aml.

Naturally, compile errors remain regardless if I open DSDT.dsl in MaciASL with or without SSDTs in the same folder next to DSDT.dsl. Not sure why you put emphasis on disassembling with SSDTs as context if these DSDT compile errors here are not effected by the SSDTs. I even removed all SSDTs from C/A/patched, reboot, extract, disassemble - same thing, compile errors. And kernel panics from this hotpatch are difficult to be imagination.

So Rehabman, can you give us a pointer from which hotpatch(es) the errors originate from? I bet you agree they need to be eliminated. Would be really awesome :) saintno's config.plist also in the attached zip
Click to expand...

It is not valid to use MaciASL standalone to check for errors.
By using MaciASL, you are not disassembling with SSDTs as context.
Must disassemble patchmatic output with: iasl -da -dl *.aml

If you find problems with the *.dsl files generated from patchmatic disassembly, it likely points to problems in your hotpatch, especially if those same problems do not exist in ACPI/origin disassembly.
 
RehabMan said:
It is not valid to use MaciASL standalone to check for errors.
By using MaciASL, you are not disassembling with SSDTs as context.
Must disassemble patchmatic output with: iasl -da -dl *.aml
Click to expand...
exactly. Again, procedure path:
cd ~/Desktop
mkdir extract
cd extract
patchmatic -extract
iasl -da -dl DSDT.aml SSDT*.aml
open DSDT.dsl with MaciASL --> compile errors
100% as per your guide
RehabMan said:
If you find problems with the *.dsl files generated from patchmatic disassembly, it likely points to problems in your hotpatch, especially if those same problems do not exist in ACPI/origin disassembly.
Click to expand...
exactly, that's what I've been saying for days and many posts now, thanks for finally confirming. Again, it's not my hotpatch but created by the thread starter here.

Did you take the time and actually look at the provided DSDT in your MaciASL?
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top