PSA: X56 "ghost inputs" are caused by USB hubs, (probably) not your hardware.
I've been trying to diagnose the ghost button inputs on my Logitech X56, mostly happening on the throttle side, since I picked it up a couple of weeks ago. Did all the usual stuff you read about this HOTAS, powered hub, different cables, etc. I was genuinely about to start pricing out a replacement. Bottom line is, the X56 does not play well with USB hub's, at all.
Important nuance I got wrong at first, so I'll lead with it: it is not "docks bad, direct good." My Thunderbolt dock is completely clean. What matters is whether there's an actual USB hub between the device and the machine.
I'm on a Mac so there's zero Logitech software, which is what kicked this whole thing off. Ended up writing a CLI to talk to it over HID, then a monitor to log the raw input reports so I could see what was actually happening.
What the ghost inputs actually are
It's single-poll frame corruption. One 8ms USB frame comes through garbage and the next one is fine. Specifically:
- Whole BYTES of the report flipping to 0xFF, so you get 8 consecutive buttons "pressed" for 8ms
- Axis values jumping half their range in one poll and snapping back on the next. 460 out of 1023, in 8ms. Nobody moves a lever that fast
- Rotaries I wasn't touching showing big excursions and instantly returning
The byte alignment is the giveaway. Switches don't fail in groups of exactly 8, and a pot physically cannot set button bits. Once I caught an axis and three buttons corrupting in the same frame and recovering in the same frame, mechanical was off the table.
The data
Same throttle, same 60 second test, same routine (sweep idle -> max -> idle repeatedly). "Glitches per range" is normalized by how far I actually moved the lever, otherwise you're just measuring how much you fidgeted that minute.
Clean:
- USB A->C adapter into a built-in port - 0.00 per range, biggest single-poll jump 18. Three runs, 42 ranges of travel, not one corruption event
- Thunderbolt dock with its own xHCI controller - 0.00 per range, biggest jump 22, 18 ranges of travel
Broken:
- Dock built on 3 cascaded single-TT hubs - 0.90 per range, biggest jump 262
- Powered hub, throttle the ONLY thing plugged into it - 0.11 per range, biggest jump 460. The 0.11 is too low, my detector was undercounting on that run. The 460 jump is the real story
- Realtek RTS5411, multi-TT, single hop - 0.50 per range, biggest jump 389
For reference a genuinely fast lever movement tops out around 18-22 units per poll. Anything in the hundreds isn't physics.
Stuff I ruled out
- LEDs. I read repeated concerns about how the lighting was drawing enough current to cause this. Ran a controlled A/B, on vs off, alternating with a settling gap. No effect. Got more glitches with them off in one round, which is just noise, but it pretty much killed that theory
- Bus contention. The powered hub run had literally nothing else plugged into it
- Cascade depth. The Realtek was a single hop
- Single-TT vs multi-TT. This is the one that surprised me. My hub-based dock is 3x cascaded Genesys GL852, all single-TT (
bDeviceProtocol = 1), so I figured a multi-TT hub was the fix. Tested one. Still broken. So it is NOT transaction translator count, which was my entire working theory going in - Power. My clean runs included a PD passthrough charging the Mac at 85W over the same USB-C connector carrying the throttle data. Zero glitches. Meanwhile the Realtek hub corrupted frames with no power running through it at all
Why a Thunderbolt dock is fine but a USB hub isn't
This is the bit that took me longest to work out. A proper Thunderbolt dock presents its own xHCI controller over PCIe. Its USB-A ports are native root ports of that controller, electrically the same as ports on your machine. A USB hub is a completely different animal, and plenty of things marketed as "docks" are just hubs in a nicer shell. Two of the "hubs" I tested were a Steam Deck dock and an Anker usb-C dock.
My guess at the mechanism (someone who actually knows USB, please correct me)
The X56 is a full speed 12 Mbps device. Any USB 2.0 hub has to carry full speed traffic using split transactions, SSPLIT/CSPLIT, brokered by that hub's transaction translator. A root port doesn't use split transactions at all.
So my read is the X56 firmware is marginal at split transaction handling and it doesn't matter how good your hub is. Device-side problem that only ever shows up behind a hub.
That would also explain how "mine's been flawless for five years" and "mine ghosts constantly" can both be true, depending purely on how people have it plugged in.
How to check what you've actually got
Don't trust the product page, check the tree.
- Mac:
ioreg -p IOUSB -w 0- if your stick shows up directly under something likeAppleT6000USBXHCIorAppleUSBXHCIFL1100, you're on a root port. If there's aUSB2.1 Hubin the chain above it, you're behind a hub - Linux:
lsusb -t - Windows: USB Device Tree Viewer (free), or Device Manager set to "View by connection"
Mine currently reads Root -> AppleUSBXHCIFL1100 -> X-56 Throttle, no hub, clean. My keyboard and mouse read Root -> AppleT6000USBXHCI -> USB2.1 Hub -> USB2.1 Hub -> Keychron, two hubs deep.
Which brings up something worth checking: my keyboard and mouse are the same speed class as the throttle and have been behind that same single-TT chain the whole time. If you get the occasional dropped or doubled keystroke, might be related. I never would have thought to blame the dock for that.
Caveats
n=1, one throttle, macOS. Tooling is Mac specific but the finding should be platform independent since it's happening at the USB layer. Haven't tested the stick half yet.
If anyone on Windows or Linux wants to try this, I'd be curious. Especially if you have a USB hub that doesn't do this, because that would blow a hole in the theory.
Happy to stick the CLI on GitHub if there's interest. Swift/IOKit, does LED control plus the axis monitor that generated all these numbers.