Contribute
Register

USB Wake Issue

Status
Not open for further replies.
OK, so I see no reason why your USBPorts isn't loading alongside the other kexts in the kext bootloader folder, i.e. Lilu, WhateverGreen etc., the USBPorts.kext definitely isn't listed in either of those outputs.

When you created/Exported your new USBPorts.kext using Hackintool, was an SSDT-UIAC.aml also created/Exported? By that I mean one that has been edited to show the correct USB connector types for each port?

If yes, can you add the new SSDT-UIAC.aml to your /OC/ACPI folder and config.plist, or /CLOVER/ACPI/patched folder and keep USBInjectAll.kext in your kexts folder. Remove the USBPorts.kext and reboot your system.

Then see if the new SSDT works any better than the USBPorts.kext.
 
Yes, Hackintool created SSDT-UIAC.aml works same way as manually created SSDT-UIAC.aml. And no miracle as the content of the file is almost same.

Sleep works on second try and some rare times on first (when monitor manages shut itself and its USB-hub down before comp enters sleep).
 
The contents of the new SSDT-UIAC.aml should be the same as the new USBPorts.kext, i.e. activating the same USB ports with the corrected connector types. It should not be the same as the previous SSDT-UIAC.aml, which was set with the wrong connector types.

Can you post a copy of the new SSDT-UIAC.aml and the new USBPorts.kext, just so I can check if there is something untoward with the SSDT table.
 
There are no wrong connector types in my manually created SSDT-UIAC.aml, I have corrected them.

Attached is Hackintool created USBPorts.kext and SSDT-UIAC.aml
 

Attachments

  • USBPorts.kext.zip
    1.2 KB · Views: 34
  • SSDT-UIAC.aml
    754 bytes · Views: 41
There are no wrong connector types in my manually created SSDT-UIAC.aml, I have corrected them.

Attached is Hackintool created USBPorts.kext and SSDT-UIAC.aml

Hi again.

So is the underlying problem still the wake-from-sleep issue?

Is it still related to the monitor hub?

5x pages in and we should have been able to narrow the problem down by now ...

:)
 
Not wake from sleep. It's going to sleep. And yes, monitor hub seems to be the issue.
 
Ok, the SSDT and USBPorts.kext are doing the same job with the same port connector types.

Option 1. When you have tried to use the new USBPorts.kext, you haven't had either the SSDT-UIAC.aml or USBInjectAll.kext in your setup, correct?

Option 2. When you have tried to use the new SSDT-UIAC.aml, you have added USBInjectAll.kext to your setup and made sure that any USBPorts.kext (new or old) have been removed/deleted, correct?

Which USB ports from those you expect to be activated don't work when using the Option 1 or the Option 2 setup?

Through which USB port is the Monitor Hub connected?
Is the Monitor Hub USB2 or USB3?
 
1. Correct
2. Correct

With option one HS14 is not working (BT Hub). Option 2 all ports work (but sleep is not like desired).

Monitor hub is connected to HS06, USB2. But when trying any of USB3 ports, result was the same.

Edit/Sorry: Monitor Hub itself is USB2.
 
If you disconnect the monitor hub and connect another USB2 device to HS06 does it work as expected? What I am trying to clarify is if the issue is with HS06 or the Monitor Hub.

By the sounds of things you need to decide, which option you can live with.

It seems to me that you are not going to get a better solution with your system. You need to select either a non functioning HS14 or run a system with sleep not as desired.
 
If you disconnect the monitor hub and connect another USB2 device to HS06 does it work as expected? What I am trying to clarify is if the issue is with HS06 or the Monitor Hub.

By the sounds of things you need to decide, which option you can live with.

It seems to me that you are not going to get a better solution with your system. You need to select either a non functioning HS14 or run a system with sleep not as desired.

Hi both.

Digging deeper I think the problem is probably the monitor hub.

I was just thinking to myself - what would a real Mac make of the monitor?

That set me exploring the IOReg again. The monitor seems to use a Cypress unmanaged USB hub and I wonder if it is the lack of any control - OS-side or hardware-side - which is causing these problems? It's worth exploring the documentation and manufacturer's web-site for any information on Mac drivers.

As @Edhawk says, it may be a choice of living with the situation as it is and perhaps using a non-bluetooth mouse so you can disable that port?
 
Status
Not open for further replies.
Back
Top