Wireless USB keyboard range diminished using Big Sur vs. Windows. Thoughts?

[rawkus]

Hello all!
I have a stable Big Sur 11.4 Beta build that I had to remap the USB ports when switching from a Radeon VII to a 6900 XT, as the 6900 XT has a USB C port. Well, everything is working just peachy, other than my Logitech keyboard has to sit physically closer to the wireless USB transmitter/receiver when using OS X. When I am using my Windows 10 build, I have no such issues.

Is it possible that OS X is limiting USB power via voltage and/or amperage? It almost seems like the transmitter/receiver is under volted. Any feedback is appreciated.

• Intel I9 9900k
• Gigabyte AORUS Z390 PRO
• AMD RX 6900 XT

 

[Edhawk]

A few questions to flesh out your issues:

1. Are you using an SSDT-USBX.aml for USB power?
2. Does your USBPorts.kext contain the (correct/same) USB power settings?
3. Is there a clash between the SSDT and kext USB power settings?
4. What other USB rename patches or settings are you using?
5. Assuming you are using OpenCore, have you disabled the XhciPortLimit quirk?
6. Are any of your other USB devices showing a lack of power, i.e. any errors showing when you connect an external drive in a USB enclosure.
7. Are you using a USB extension cable?
8. Have you checked the USB dongle for damage? I assume it was removed and reinserted when you swapped the graphics cards.

Provide copies of any USB related SSDT's and your USBPorts.kext or USBMap.kext, so we can see what you are using.

A Copy of your OC folder, with the SN, MLB, ROM and UUID redacted from the config.plist would not go amiss.

 

[Edhawk]

I haven't watched or used the guide you linked but I can see you have issues in your USBPorts.kext:

1. The virtual USB2 ports HS03, HS04, HS05, HS07, HS08, HS09 and HS10 on your physical USB3 ports are all set with the connector type '0', which is wrong. This is the connector type for a physical USB2 port (Black), not a virtual USB2 port.
2. If the virtual USB2 port is served from a physical USB3 port (Blue or Red) then it needs to be set as connector type '3'
3. You have a USB Type-C port on the rear and an internal Header. Neither of these seem to have been included in your USB Configuration.
4. Your Rear I/O plate is a little unusal for a new motherboard, in that it has 4 x USB2 physical ports. If new boards have any physical USB2 ports then they usually have a max of 2 x USB2 ports. Still only a maximum of 4 of the 7 ports set with the Connector Type '0' can be correct, and then only if you included all 4 USB2 ports in the Configuration you created.

Z390 AORUS PRO Rear I/O plate

Your motherboard has the following USB headers:

• 2 x USB2 (4 x USB2 ports)
• 1 X USB3 (2 x USB2 & 2 x USB3)
• 1 X USB Type-C (serving Case Type-C port?)

These are highlighted on the motherboard image below.

Z390 AORUS PRO Motherboard Header ports

So you need to re-examine your USBPorts.kext as it is not set correctly for your system.

• Some of the USB2 connectors should probably be set as USB3.
• Possibly some of the USB3 connectors should be set as Type-C

Hope this helps.

 

[rawkus]

This is all very helpful! I will make adjustments and report back.

I intentionally didn't include the USB-C as I never use the ports and didn't see a need in keeping them in my configuration. Would this be cause for concern?

I also intentionally don't have any of the physical USB 2.0 ports included in my config.

I will adjust the virtual 2.0 to USB 3.0.

Thanks again so much!

 

[rawkus]

Updated per your suggestions. Seemingly still have an issue. I'll test drive for a while but already the mouse is hit or miss. Luckily, I can run the mouse in Bluetooth mode and that seems to be working smoothly. While it is a viable workaround, I'd love to get to the bottom of this inconsistency.

 

[Edhawk]

Not using the USB-C ports and header is not an issue. Same goes for the 4 USB2 ports.

So based on the above I am assuming you have your Bluetooth connected to HS11, the internal port. All the other ports are served by either physical USB3 ports on the case or rear I/O plate.

Do you have any front case USB2 ports? If yes, these should be set as connector type 255 not USB2, if they are served by the other Internal USB2 Header.

The new USBPorts.kext looks correct. Can you post a screenshot of the Hackintool > USB tab, showing your current setup. You may need to Clear and Refresh the USB tab to get it to show just the ports that are being activated by the kext.

The SSDT-EC-USBX.aml and the USBPorts.kext both contain USB Power settings, they are written in different formats but are set the same. The kext shows the power settings in HEX (2100 & 5100), the SSDT shows the same power settings in Decimal (0x0834 & 0x13EC). So there shouldn't be a clash between the SSDT and kext regarding the USB power.

USBPorts.kext Power settings

SSDT-EC-USBX.aml USB power settings

While in Hackintool I would check that each port you have activated is showing correctly with both a USB2 and USB3 pen drive. Just to double/triple/quadruple check they are correct!

If you provide a copy of your DSDT.aml I can create a custom SSDT-EC.aml which doesn't contain the USB power settings, to eliminate any chance of this being the cause of your current issues. Alternatively you can download and use Corpnewt's SSDTTime script and create it yourself.

Custom SSDT's created for just your system are in my opinion much better than the generic 'one size fits all' SSDT's provided by Dortania or the OC developers. They are fine for use as a starter but should be replaced with custom SSDT's when possible. Using your own DSDT to create the SSDT's means they only contain the entries necessary for your system to work. Unlike the other generic SSDT's which contain dozens of EC or PLUG entries. Or in some cases the wrong entries.

 

[rawkus]

-HS11 is connected to my Bluetooth, correct.

-My case only has two USB 3.0 ports. It's a Riotoro CR1088 for to confirm I'm not missing something obvious.

-Hackintool screenshoot:

-I double checked all USB ports with 2.0 and 3.0 and everything seems right. I checked with both USB drives and the powered USB hub for sanity.

-How does one get you the DSDT.aml? In the meantime, I am researching SSDTTime.

-Finally, I did a quick test with my keyboard. Using Windows, with the dongle plugged into my powered USB hub, I can get approx. 10-15 feet away and the keyboard works perfectly fine. Using Windows, with the dongle plugged into the front USB ports on the case, I can get about 3 feet away with the keyboard working consistently. With OSX and the dongle plugged into the powered USB hub, I have to have the keyboard within 1 foot to work consistently. With OSX and the dongle plugged into the front case port, it's about 1 foot to work consistently. Kind of mind blowing! I ordered a USB voltmeter/ammeter to see what the physical readings are because it's so dramatic!

Lastly, I can't say how much I appreciate the time and effort you are putting in to helping me!

 

[Edhawk]

The USBPorts.kext output in Hackintool looks fine based on how you have configured your ports.

Regarding obtaining a copy of your DSDT.aml when using OpenCore, follow these steps:

1. Open the Hackintool application.
2. Navigate to the Utilities tab in Hackintool.
3. Select the 'Dump ACPI' icon (fourth from the right below the main window)
4. A Finder pane will open, so you can create a new folder (on your desktop or somewhere it is easy to find), Save the tables in the new folder.
5. Compress and attach the folder.

 

[rawkus]

Done and done. Thanks!

 

[Edhawk]

I have attached a copy of the Results folder created by Corpnewt's SSDTTime python script using your DSDT.aml as the base. These are the fixes that can be selected in SSDTTime from macOS:

1. FixHPET - Patch Out IRQ Conflicts​

2. FakeEC - OS-Aware Fake EC​

3. FakeEC Laptop - Only Builds Fake EC - Leaves Existing Untouched​

4. PluginType - Sets plugin-type = 1 on First ProcessorObj​

5. PMC - Enables Native NVRAM on True 300-Series Boards​

6. AWAC - Context-Aware AWAC Disable and RTC Fake​

7. USB Reset - Reset USB controllers to allow hardware mapping​

Your system didn't need option 3 or 6 from this list.

The Results folder contains the following custom SSDT's and patches that may be useful with your system:

• SSDT-EC.aml
• SSDT-HPET.aml
• SSDT-PLUG.aml
• SSDT-PMC.aml
• SSDT-USB-Reset.aml
• patches_OC.plist - (3 x essential SSDT-HPET rename patches)

Your current OC ACPI folder contains these SSDT's:

• SSDT-EC-USBX.aml - Delete and replace with SSDT-EC.aml (USB power dealt with in USBPorts.kext)
• SSDT-PLUG.aml - SSDT identical to one generated by SSDTTime, so can be retained or replaced.
• SSDT-PMC.aml - Delete and replace with new SSDT-PMC.aml as current is different to one generated by SSDTTime.

I would see how your system works with just these changes for now, as the OC guide says your 300-Series system doesn't need to use the SSDT-HPET.aml or the associated rename patches. But they may be added later if you want to see what difference, if any the SSDT-HPET.aml and patches make to your system.

One thing to remember about the OC guides is that they are set to cover as many bases for a clean install on a given system/CPU series. They do not go into any depth regarding system custom fixes, which most if not all systems require, which usually take place after the OS has been installed. So just because the OC guide doesn't mention them or say they are needed, doesn't mean that a custom fix won't be required after the installation process has completed.