Contribute
Register

[Guide] USB power property injection for Sierra (and later)

Here you go, problem reporting files included as required.
The problem is that I am unable to override IOUSBHostFamily.kext as per your #1 posting, with my SSDT-UIAC.aml file, into which I have added the code that you suggested in your guide one should, and I quote, to eliminate the possibility of confusion, what I am attempting to achieve:
Quote
I have added support in USBInjectAll.kext to inject these properties. And, at least in my testing, the properties injected by USBInjectAll.kext are succesful in overriding those from IOUSBHostFamily.kext.
Unquote

Greetings

Your attempt looks correct.
Probably the UsbMergeNub probe is running after USBInjectAll probe.
In my testing, USBInjectAll probe was running later...
But since the relative order is not defined by Apple, you may have different results.
Your choices:
- provide overrides by patching IOUSBHostFamily Info.plist
- use a different SMBIOS (one without default properties in IOUSBHostFamily) and override with USBX
 
Your attempt looks correct.
Probably the UsbMergeNub probe is running after USBInjectAll probe.
In my testing, USBInjectAll probe was running later...
But since the relative order is not defined by Apple, you may have different results.
Your choices:
- provide overrides by patching IOUSBHostFamily Info.plist
- use a different SMBIOS (one without default properties in IOUSBHostFamily) and override with USBX
Thanks for your feedback and explanation.
For the time being I decided to override my IOUSBHostFamily Info.plist manually.
The kext is easy to modify with my preferred charge currents and besides I have originally chosen SysDef 14.2 because my hardware is pretty close to what Apple used for their 14.2 machines. To me the longer term advantages in sticking with SysDef 14.2 outweigh going for something undefined in the kext. In addition Messages has been working like a dream for a long time. Changing my Sysdef to a "non-defined" version will necessitate redefining Message parameters as well. Maybe one day, further down the line I will reconsider .
Back to your post #1.
Compliments to you for covering everything in there in such detail. It indeed assisted me to be able to move from this topic without, hopefully having "bugged" you too often. The secret, as always is "RTFM" or applying that saying to your guides "RTFG"
Greetings
 
Back to your post #1.
Compliments to you for covering everything in there in such detail. It indeed assisted me to be able to move from this topic without, hopefully having "bugged" you too often. The secret, as always is "RTFM" or applying that saying to your guides "RTFG"
Greetings

Funny...
 
Funny... but true :)
In my previous post I forgot to mention that should Apple change the IOUSBHostFamily.kext in a future update I will not loose the "charging" capability at all because I am using SSDT-EC.aml to provide fake EC functionality in Clover > ACPI patched. All that will happen is that my available charge current will revert back to 1 amp as originally defined in the SyDef section in that kext. That should however be easily detectable by being alert to what ones hardware is actually delivering, because it will manifest itself in quite a significant increase in duration that it takes to charge an iPad. Consequently staying with SysDef 14.2 is no big deal, for me at least.
I merely added this statement for the benefit of others that maybe following this thread. I am uneasy to use forums only as a leecher. I feel that one should provide feedback as well when one believes it may also benefit others, something I believe is the case in this instance.
Greetings
 
Funny... but true :)
In my previous post I forgot to mention that should Apple change the IOUSBHostFamily.kext in a future update I will not loose the "charging" capability at all because I am using SSDT-EC.aml to provide fake EC functionality in Clover > ACPI patched. All that will happen is that my available charge current will revert back to 1 amp as originally defined in the SyDef section in that kext. That should however be easily detectable by being alert to what ones hardware is actually delivering, because it will manifest itself in quite a significant increase in duration that it takes to charge an iPad. Consequently staying with SysDef 14.2 is no big deal, for me at least.
I merely added this statement for the benefit of others that maybe following this thread. I am uneasy to use forums only as a leecher. I feel that one should provide feedback as well when one believes it may also benefit others, something I believe is the case in this instance.
Greetings

Cheers!
 
hi. is it possible that your guide doesn't work with imac18,3 sysdef?
 
Follow up:

When the battery is fairly empty charging seems to work with the computer being awake and at the max USB2 current of 1.6 amps. Charging then stops when the battery voltage reaches a level that is attainable by the insufficient current from the USB2 port. Constant current/voltage equilibrium. Once Sierra sleeps the Usb2 port delivers the 2 amps that the iPad requires, therefore charging resumes until constant current/voltage equilibrium
is reached again with the higher charge current, which is the condition when the battery is full and being charged with rated current.
Will continue to monitor this and report back should the need arise.
Greetings
Conducted some extensive charge characteristics experiments.
With RehabMan's mods applied, the iPad charge rate, when the battery level is 18% full, increases the battery charge level by 16% to 34% after 1 hour of charging.
The charge rate drops off quite drastically when the battery reaches the 80% charge level. Charging the battery for 1 hour when the battery is at 88% increases the battery charge level by a mere 3% to 91%.
Conclusion:
In my environment and with my iPad as the test object, the charge rate is only 1/6th. when the battery is fairly full (88%) compared to that when the battery charge level is pretty low (18%)
Greetings
 
Thanks RehabMan works great!

This is on a LGA 775 Motherboard, using MacPro3,1 no need for USBInjectAll or SSDT-UIAC, all USB ports working without any kind of injection, just injecting the SSDT-EC and SSDT-USBX!

If I use MacPro4,1, then I don't need the SSDT-USBX patch since it is listed in the Info.plist. I don't know why MacPro3,1 is excluded?
 

Attachments

  • Screen Shot 2017-07-08 at 1.19.27 AM.png
    Screen Shot 2017-07-08 at 1.19.27 AM.png
    234 KB · Views: 116
Last edited:
Thanks RehabMan works great!

This is on a LGA 775 Motherboard, using MacPro3,1 no need for USBInjectAll or SSDT-UIAC, all USB ports working without any kind of injection, just injecting the SSDT-EC and SSDT-USBX!

If I use MacPro4,1, then I don't need the SSDT-USBX patch since it is listed in the Info.plist. I don't know why MacPro3,1 is excluded?

MacPro3,1 is not included in Sierra because Sierra does not support MacPro3,1.
I suspect you're using a different board-id than MacPro3,1 or you're using -no-compat-check (?) or other patch to enable you to boot with MacPro3,1.
 
Back
Top