Contribute
Register

[Guide] Creating a Custom SSDT for USBInjectAll.kext

Ok... so close. I successfully identified all the ports and thought I had the SSDT ready to go, but when I rebooted... no Bluetooth (which is on HS13). I tried both 255 and 2 as the USB Connector. In both cases, on reboot, HS13 showed nothing connected. The screen grab is before the SSDT, the attached files are the dsl I used to create the aml that I put in Clover/ACPI/patched.View attachment 283697

Wilco. I'll have the requested info on Friday. Thank you.
 
Hi... I've been trying to learn as much about these SSDTs as I can before I actually submit a problem report (I want to try a little bit harder to fix the problem myself before begging again for help). I do have a couple of questions:

},
"HP16", Package() // bluetooth
{
//"UsbConnector", 255,
"portType", 2,
"port", Buffer() { 6, 0, 0, 0 },
},

In the above code, to what is the last sequence of numbers ( in red and blue) in reference? More specifically, what is the blue number? Is that corresponding port position in the unpatched IO registry using USBInjectAll.kext? Would entering an incorrect value here (e.g., saying HP16 was number 5 in the IOreg when it's actually number 6) prevent the port from working?

Also, I noticed that while the "portType", 2, line is present for this internal port (my own Bluetooth is on HS13), it is not present for any of the physical USB ports in the SSDT files I've been reviewing. Is this a requirement/recommendation for better identifying internal ports? And what is the difference between "USBConnector" and "portType"?

And, finally:

"8086_a12f", Package()
{
"port-count", Buffer() { 26, 0, 0, 0 },
"ports", Package()
{

I'm assuming the number in red (26) refers to the number of ports injected by the USBInjectAll.kext with the raise port limit patch applied? If that is the case, and I used this patch to raise my own limit, should that number be 24 (as opposed to 26, understanding that this patch goes away once the SSDT is confirmed as working)?
 
In the above code, to what is the last sequence of numbers ( in red and blue) in reference? More specifically, what is the blue number?

That is the port address.
It is NOT to be changed (all port addresses in SSDT-UIAC-ALL are correct).

Also, I noticed that while the "portType", 2, line is present for this internal port (my own Bluetooth is on HS13), it is not present for any of the physical USB ports in the SSDT files I've been reviewing. Is this a requirement/recommendation for better identifying internal ports? And what is the difference between "USBConnector" and "portType"?

portType=2 is used for hub ports connected to internal devices.
portType=0 is used for normal hub ports (eg. externals).
There are other portType values used by Apple, but due to lack of information, we don't know their exact purpose.

UsbConnector is for controller ports.
portType is for hub ports.

And, finally:

"8086_a12f", Package()
{
"port-count", Buffer() { 26, 0, 0, 0 },
"ports", Package()
{

I'm assuming the number in red (26) refers to the number of ports injected by the USBInjectAll.kext with the raise port limit patch applied? If that is the case, and I used this patch to raise my own limit, should that number be 24 (as opposed to 26, understanding that this patch goes away once the SSDT is confirmed as working)?

That is the maximum port address for the controller.
It is NOT to be changed (all "port-count" values are correct in SSDT-UIAC-ALL).
 
That is the port address.
It is NOT to be changed (all port addresses in SSDT-UIAC-ALL are correct).



portType=2 is used for hub ports connected to internal devices.
portType=0 is used for normal hub ports (eg. externals).
There are other portType values used by Apple, but due to lack of information, we don't know their exact purpose.

UsbConnector is for controller ports.
portType is for hub ports.



That is the maximum port address for the controller.
It is NOT to be changed (all "port-count" values are correct in SSDT-UIAC-ALL).

Thank you. That does help me understand a little better.
 
I am thrilled to report that I carefully went back through the SSDT, re-saved it, placed it in Clover/ACPI/patched, restarted, and everything appears to be fine... including Bluetooth. Only the ports identified during discovery are showing up in IOreg. I'm about to go in and remove the port limit patch... but one thing on which I'm still fuzzy: my monitor (and my printer/scanner) have USB ports that are being identified as hubs. Nothing is plugged into the printer/scanner, but a couple of things are plugged into my monitor. Do I need to do anything with them? They're on HS04 and HS05.

Screen Shot 2017-10-13 at 9.02.35 AM.png
 
I am thrilled to report that I carefully went back through the SSDT, re-saved it, placed it in Clover/ACPI/patched, restarted, and everything appears to be fine... including Bluetooth. Only the ports identified during discovery are showing up in IOreg. I'm about to go in and remove the port limit patch... but one thing on which I'm still fuzzy: my monitor (and my printer/scanner) have USB ports that are being identified as hubs. Nothing is plugged into the printer/scanner, but a couple of things are plugged into my monitor. Do I need to do anything with them? They're on HS04 and HS05.

View attachment 285395

Not possible to verify anything without "Problem Reporting" files as per post #1.
Please read it.
 
Not possible to verify anything without "Problem Reporting" files as per post #1.
Please read it.

Thanks. I actually did read it. So far, no problems... it was more of general question. If I have problems, however, I'll follow that process to the letter. Thanks again.
 
Thanks. I actually did read it. So far, no problems... it was more of general question. If I have problems, however, I'll follow that process to the letter. Thanks again.

Not possible for me to answer your question regarding HS04/HS05 without seeing the ioreg.
The image you provided is not focused on the right data.
 
Not possible for me to answer your question regarding HS04/HS05 without seeing the ioreg.
The image you provided is not focused on the right data.

Ah. I understand. God willing, everything is okay, but the IOreg is attached.
 

Attachments

  • Bill’s iMac.zip
    760.4 KB · Views: 64
Ah. I understand. God willing, everything is okay, but the IOreg is attached.

HS04 and HS05 are marked UsbConnector=3. It means they should have an associated SSxx port for each.
If these hubs in the monitor are USB2 only, then the ioreg makes sense.
But if the hubs are USB3 hubs, then something is wrong (because otherwise, we would see the hubs on each SSxx port associated with HS04/HS05).
 
Back
Top