Strange behaviour for addressable RGB headers

[panosru]

I have a strange behaviour with ARGB headers when using either USB Toolbox from Windows or by exporting USB Ports from Hackingtool. I'm not sure if that only affects ASRock motherboards, I have this strange behaviour with both ASRock Z790 Livemixer and my current ASRock Z790 Nova WiFi. When I power on my Hackintosh from S5 state (power down), the ARGB headers are not working, nor does the Polychrome from BIOS and Windows detect them. It's like the chipset controller for ARGB gets unresponsive somehow. This happens ONLY if I load a USB mapping KEXT that was produced either from USB Toolbox or Hackingtool or if you load XHCI-unsupported KEXT. The only way to restore the ARGB headers is to clear BIOS CMOS. Then, once you boot via the EFI into macOS, the issue will be present on the next power cycle. The issue is not present if you boot from the OC EFI to Windows. If I make my USB mapping KEXT (USBMap.kext), the issue is gone.

 

I have attached both the USB mapping kexts files here. The USBMap.kext is the one that works and the USBPorts.kext is the one produced by Hackingtool. I wonder why by simply removing some properties from the PLIST the issue is gone and how important are the properties that I removed (if they are important at all).

 

I also noticed that with USB inject all kext and XHCI-unsupported, OpenRGB could detect the RGB headers of my motherboard, with USBPorts.kext (produced by Hackingtool) it hangs while searching for devices and with my USBMap.kext file it just crashes when you click on rescan devices. It would be cool to have it work again, but not vital.

 

Thank you!

USBMap.kext.zip USBPorts.kext.zip

[panosru]

So, after a lot of trying, I managed to find out to which USB port the internal ARGB of the motherboard were assigned. By removing the port from the USB mapping, the ARGB controllers work fine. If you are fortunate enough, you may find right away on which USB port the LED controller is assigned to:

 

If you are not so lucky (I wasn't), you have to try each port one by one and after too many reboots, eventually, you'll pinpoint which port is to blame and not include it in your port mapping. After I identified the port responsible for the LED controller, I tried all the available USB mapping tools, and just by excluding this port, they all worked fine. Under Windows, if you use the USBToolbox, usually the LED controller port will be marked as "undefined".