USB Driver Changed Again - PB6

[Fordski]

I think the next step is to carefully determine which ports actually need to be enabled on XHC (HSxx, SSPx) and exclude all those that are not needed with a port injector kext.

I'm a little confused on this one. Would only the SSP ports need to be enabled on XHC as they are the USB3 ports and the only ones that need to be on XHC? I built my injector that way as I thought all the USB 2 ports could be redirected to EHC. I have more than 15 usable ports (14 USB 2 (including the 6 shared with the USB 3 connectors) and 6 USB 3) so I need to move some USB 2 ports to EHC, so I thought why not just move all of them?

 

[matt77303]

The patch we use on laptops is available here: https://github.com/RehabMan/Laptop-DSDT-Patch

There are two versions one for _PRW that uses GPE 0x0D, and another for GPE 0x6D.

Your DSDT uses GPE 0x0D for the _PRW on USB controllers, so apply "USB3 _PRW(0x0D) and Rename XHC to XHC1"

Note: The rename XHC->XHC1 is disabled in the patch, so no worries there. But you'll see it will replace the _PRW objects in GLAN, EHC1, EHC2, XHC, and HDEF.

That works, only downside is not being able to wake the hack with the mouse, but i can live with that.

Matt

 

[matt77303]

That works, only downside is not being able to wake the hack with the mouse, but i can live with that.

Matt

edit: I'm currently running the DSDT from post 231, any change you could make me a patch for whatever you did in case i need to make a new DSDT for any reason? Could you also include that USB3 _PRW(0x0D) and Rename XHC to XHC1 so its just a one click thing if i create a new DSDT.

Thanks

Matt

 

[RehabMan]

I'm a little confused on this one. Would only the SSP ports need to be enabled on XHC as they are the USB3 ports and the only ones that need to be on XHC? I built my injector that way as I thought all the USB 2 ports could be redirected to EHC. I have more than 15 usable ports (14 USB 2 (including the 6 shared with the USB 3 connectors) and 6 USB 3) so I need to move some USB 2 ports to EHC, so I thought why not just move all of them?

It may depend on the board... I think the XHC controller can have both USB3 ports and USB2 ports connected to it.

It also depends on USB2 port routing on XHC. If USB2 ports on the USB3 ports (or even standalone USB2 ports connected to XHC) are routed to EHC (eg. via XHCIMux), then the associated HSxx ports would not be used. But if USB2 routing was not enabled (eg. not using XHCIMux), then the associated HSxx ports would be used.

 

[RehabMan]

edit: I'm currently running the DSDT from post 231, any change you could make me a patch for whatever you did in case i need to make a new DSDT for any reason? Could you also include that USB3 _PRW(0x0D) and Rename XHC to XHC1 so its just a one click thing if i create a new DSDT.

Thanks

Matt

Post the DSDT you're using and the native DSDT. I can compare them.

 

[Fordski]

It may depend on the board... I think the XHC controller can have both USB3 ports and USB2 ports connected to it.

It also depends on USB2 port routing on XHC. If USB2 ports on the USB3 ports (or even standalone USB2 ports connected to XHC) are routed to EHC (eg. via XHCIMux), then the associated HSxx ports would not be used. But if USB2 routing was not enabled (eg. not using XHCIMux), then the associated HSxx ports would be used.

Go it. Thanks. Yes I have seen the HSxx ports activated on XHC for USB 2 ports in ioreg without the fakepciid etc kexts installed.

So if I had 15 or less USB ports I could enable them all on XHC with the port injector and not use the FakePCIID and FakePCIID_XHCIMux kexts. However because I have more than 15 ports I need to route the USB 2 ports to EHC and therefore I only need to enable USB 3 (SSPxx) ports in my port injector for XHC as enabling HSxx ports for USB 2 would not do anything as they would be routed to EHC anyways. Is that correct?

Rehabman I really appreciate your time and effort in educating us on how all this works! 3 months ago I didn't even know what a Hackintosh was and now I'm editing DSDTs...(well, applying your edits)... Thank you!

 

[RehabMan]

Go it. Thanks. Yes I have seen the HSxx ports activated on XHC for USB 2 ports in ioreg without the fakepciid etc kexts installed.

Just to clarify, without USB2 port routing, the USB2 component of a USB3 port on XHC will always be handled by XHC as one of the HSXX nodes (naming depends on DSDT and use of port injector). Also, a standalone USB2 port (no USB3 component) could be attached to the XHC controller (I think).

So if I had 15 or less USB ports I could enable them all on XHC with the port injector and not use the FakePCIID and FakePCIID_XHCIMux kexts.

Yes. Keep in mind that each USB3 port is actually two ports in one.

And... it would depend on how the "USB ports" (as you referred to them) are connected. It is possible for the OEM to decide to connect USB2 ports directly to EHC1 or EHC2 instead of the XHC controller.

However because I have more than 15 ports I need to route the USB 2 ports to EHC and therefore I only need to enable USB 3 (SSPxx) ports in my port injector for XHC as enabling HSxx ports for USB 2 would not do anything as they would be routed to EHC anyways. Is that correct?

With more than 15 ports on a single controller (accounting for USB3 ports on XHC being two ports), you would need to move some to EHC with XHCIMux and then insure you have the correct port injector/DSDT edits for EHC.

Rehabman I really appreciate your time and effort in educating us on how all this works! 3 months ago I didn't even know what a Hackintosh was and now I'm editing DSDTs...(well, applying your edits)... Thank you!

Thanks... I'm still trying to wrap my head around how I'm going to write this up in a guide...

I have an unfair advantage in that I've read the chipset datasheet, the ACPI spec, know about IOKit matching and kext development, and have experimented a fair bit with the new USB stack. Hard to explain to others that don't have that same background.

Note: In the 10-series (or 100-series if that's what Intel wants to call it), they got rid of EHC entirely... So, in the future everything will be on the XHC controller.

 

[ammulder]

Thanks... I'm still trying to wrap my head around how I'm going to write this up in a guide...

I have an unfair advantage in that I've read the chipset datasheet, the ACPI spec, know about IOKit matching and kext development, and have experimented a fair bit with the new USB stack. Hard to explain to others that don't have that same background.

It seems almost unimaginable to walk people through all this. Just based on watching the number of interactions you have with each person before their issues are resolved.

Do you think there's any hope that Clover could eventually automate some of these adjustments? Like, count your USB ports and decide how to allocate them to EHC/XHC and patch SSDT or DSDT on the fly?

 

[RehabMan]

It seems almost unimaginable to walk people through all this. Just based on watching the number of interactions you have with each person before their issues are resolved.

I think all I can do is take a "toolbox" approach.... sort of "these are the problems"... "these are the tools you might use to create a solution"...

Do you think there's any hope that Clover could eventually automate some of these adjustments? Like, count your USB ports and decide how to allocate them to EHC/XHC and patch SSDT or DSDT on the fly?

Unfortunately with inaccuracies in DSDT, the only way to do it is to create a port injector and test. There is nothing in the hardware that indicates which ports should be enabled. Which is why the ACPI spec (as it relates to USB controllers) was created.

No doubt problems with existing DSDT on real Macs is why Apple created the port injector capability.

 

[ammulder]

OK, what about a small UI? (I say as a software developer

If a user said "I actually have 6 USB3 ports and 2 USB2 ports" or whatever, could a tool then look at whatever IOReg is reading and compare what you say you have with what the system is presently reporting and decide on the correct adjustments to make? Or is it still going to come down to "try 'this' and see if your USB devices work at high or low speed and after sleep/wake and if not try 'that' instead"?