Can I ask something ?
After proper ssdt-usb we should remove usbinjectall.kext or leave it?
I have rewritten that sentence in the guide. Hope you like it.
Can I ask something ?
After proper ssdt-usb we should remove usbinjectall.kext or leave it?
I found this in your original guide, which is exactly what I was saying above:
You can use USBInjectAll.kext to inject all ports possible for your USB controllers. With all ports injected, you can determine which ones are already used. There is also a patch available that can increase the port limit. Use only short term for determining which ports need to go into your port injector. Make sure you read the README for USBInjectAll.kext.
Whether it's used in your new guide is irrelevant. We clearly agree on this point, but you refuse to admit it.
That's fine, though. Your opinion about the patch doesn't change the fact the patch actually works, and the bootflag method is unnecessary while the patch is implemented. I bet you and FredWst are enemies!
Content of previous versions of the guide is not relevant.
I changed the guide to not depend on the patch because:
- got tired of chasing down (or creating it by disassembly analysis) the patch for each version
- got tired of people applying the wrong patch (eg. wrong version for the version of the system)
- got tired of people not placing the patch correctly in config.plist (I've seen it all)
- got tired of people stopping (not implementing SSDT-UIAC) after they realize the patch fixed their immediate problem (leading to other problems later)
Port limit patch: "good riddance."
Was that list of issues you caught the only things that you identified as a problem? Care to check the debug folder I sent last night, please? I want to confirm I fixed the problems you listed as well as take care of any others that still do. Thanks again.
- now your ioreg shows two EC objects (this is obvious stuff... sticks out like a sore thumb when you look at ioreg). No doubt due to renaming EC0 *and* adding SSDT-EC. Those two things are mutually exclusive. You only use SSDT-EC if you don't already have a serviceable EC device.
- SATA-unsupported.kext still not installed
- kexts still not installed properly (expect to see FakeSMC.kext or VirtualSMC.kext and other kexts you need in kextcache output)
- why is AppleHDA.kext patched? (and you have realtekALC.kext?). Onboard audio not working anyway.... Typically, we are using AppleALC.kext now.
- HDAS should be renamed HDEF
- Plex Tuner still installed, still hooking onto USB stuff
- legacy XHC power properties not injected (use config.plist/Devices/USB/Inject=true)
I'm confused by this as usually there is an actual kext. In this case, I only have the info.plist. I realize kexts contain this, but is it as simple as creating the contents folder (with .plist) and naming the folder SATA-unsupported.kext?
The current Mojave Install doesn't have any mention of the FakeSMC kexts, etc. I was under the impression this is no longer required.
This was a result of what I selected in Multibeast based on the audio card I have. 1220a I believe.
Without trying to upset anyone, any chance of explaining how you did it without boot flags. I have a Skylake H170-DS3H and I can't get it to work at all. It's down to my lack of knowledge/skills more than anything I'm sure, so a really simple idiot guide would be great. I'm sure I'm not the only one who would appreciate it.Few questions and comments to help solving these issues...
I was getting unexpected results when following the guide. I removed it and will resubmit debug folder when everything is done.
I'm confused by this as usually there is an actual kext. In this case, I only have the info.plist. I realize kexts contain this, but is it as simple as creating the contents folder (with .plist) and naming the folder SATA-unsupported.kext?
The current Mojave Install doesn't have any mention of the FakeSMC kexts, etc. I was under the impression this is no longer required.
This was a result of what I selected in Multibeast based on the audio card I have. 1220a I believe.
Done.
Done.