Connect a controller over USB

USB drops end-to-end latency to 4–7 ms — versus 14–25 ms over Bluetooth, and as bad as 35 ms on a congested 2.4 GHz dongle. If you're recording into a DAW or playing live, plug in. Wireless is fine for sketching; cable is mandatory for anything time-critical.

Use a data cable, not a charge cable

This trips up more new users than any other step. The cable that came with your phone is often charge-only — no D+/D- data lines. The controller will light up but the host won't see it as an HID device.

The cable in the controller's original box is always a data cable. Use that one. If you're cable-shopping, look for "USB 2.0 data sync" on the listing.

Cable cheat sheet

Not all USB-C cables are created equal. Here's what works, what doesn't, and the rough cost band so you can avoid the $3 charge-only impostors.

Verify detection at the OS level

Before blaming the app, check the OS sees the controller as an HID device:

# macOS
ioreg -p IOUSB -l | grep -i -A 2 -e "DualSense" -e "Xbox" -e "controller"

# Linux
lsusb | grep -i -e Sony -e Microsoft -e Nintendo

# Windows (PowerShell)
Get-PnpDevice -Class HIDClass | Where-Object FriendlyName -like "*Wireless Controller*"

If the OS doesn't see it, the cable or port is the problem. Try a different USB port — front-of-case ports on desktops are often unpowered USB 2.0 and flakier than rear ports.

Drill deeper — read the raw HID descriptor

If the controller enumerates but the app still can't read it, the next step is dumping the HID descriptor. This tells you whether the controller is exposing the report descriptor we expect.

# Linux — full HID descriptor dump (need libhidapi-utils)
sudo usbhid-dump -d 054c:0ce6 -es

# macOS — list all HID devices with usage page 0x01 (generic desktop)
hidutil list --matching '{"UsagePage":1}'

# Windows — list HID instances with the controller's hardware ID
Get-PnpDevice -Class HIDClass | Where-Object InstanceId -like "*VID_054C*"

The app picks it up automatically

Detection time inside Universal Controller MIDI is ~200 ms after the OS enumerates the device. The status badge in the top bar flips from No controller to a coloured chip with the controller name.

If the chip stays red, click it to open the diagnostics panel — it'll tell you whether the device is being grabbed by another process (Steam Input, DS4Windows) or whether permissions are missing.

What if it doesn't work?

USB issues split cleanly into cable, port, or process. Walk these in order:

• Controller lights up but OS sees nothing — charge-only cable. Swap for the in-box cable or a verified data cable from the table above.
• Detection drops every few seconds — USB hub bandwidth saturation. Plug the controller directly into the host, not through a hub shared with a webcam or audio interface.
• App sees the controller but no input arrives — Steam Input or DS4Windows has exclusive access. Quit them. On macOS, also check Game Controller framework hasn't taken over (kill controllerd if it has).
• Front-panel USB-C unreliable on desktop — case header wired at USB 2.0 speeds with bad shielding. Use a rear motherboard port.
• Linux: controller enumerates as root-only — udev rule missing. See Linux install for the rule snippet, then sudo udevadm trigger.

What's next

Prefer wireless? See connect over Bluetooth. Want to test it's all working? Verify everything works.