Is there any specific configuration required for USB passthrough authentication? I watched the video on HID-remapper’s YouTube channel, and it seems like it should just work, however I’ve encountered some issues.
My auth device is a Booter5 dongle from Cosmox/Haute42. When connected directly to the computer it successfully passes the auth tester.
However when connected through HID-remapper (from Mavercade, which I think is just a v5 board with 4 USB ports, like the one in the video above) it doesn’t pass authentication (screenshot in reply).
The LED on the dongle keeps blinking, indicating that it’s inactive. Of course if I plug HID-remapper into an actual PS5 it times out in 8 minutes.
I think that after many attempts there was one time when it started working (passing the tester, solid white LED on the dongle), but after unplugging and plugging back in I couldn’t reproduce this again. Tried reflashing to the latest firmware on Github - no change. Would appreciate any tips.
Yeah, GP2040-CE uses what we’d call a single Pico setup here. If it doesn’t work on the v5 board, the issue is likely with the hub chip that it uses (or, less likely, with the fact that it uses the second RP2040’s native USB interface - this typically gives us better compatibility, not worse, it’s the reason we use this setup in the first place).
I wanted to close the loop on this issue from a while back. Turns out it’s not a hardware incompatibility - the same board works with the dongle once the firmware is built against current TinyUSB master.
First, a disclosure - I used Claude to help me with analyzing the logs, reading code and executing the upgrade of the submodule, but I’ve tested everything manually to verify that the solution works.
Findings:
The dongle (identifies as “GP2040-CE (PS4)”, 0079:1893) connects and drops off the bus several times while it powers up. I measured 4 connects on every cold plug.
Behind the remapper’s hub the dongle never gets enumerated. After that, the remapper stops noticing anything on its other ports too: a keyboard plugged in afterwards isn’t detected, and unplugging one that was already connected isn’t noticed, until the remapper is power-cycled. Hot plug or power-up, any port.
TinyUSB 0.21.0 didn’t help. Current master (702e55db3) did: the dongle works after hot plugs and cold starts, other devices keep working alongside it, and auth passes every time. I don’t know which change fixed it. Likely candidates are the control transfer timeout and enumeration retry (#3862) and the hub status poll recovery (2c023b949, 0e449ae63).
What was changed to build hid-remapper against master:
Re-applied your TinyUSB fork’s patches: device SOF ISR, host SOF callback, interval override, report protocol for boot interfaces, and tuh_get_hub_addr_port() (now via tuh_bus_info_get()). The ep0 size patch isn’t needed anymore, because the new rp2040 hcd keeps a separate EP0 per device.
The new rp2040 hcd uses the SOF interrupt itself and disables it when idle, so it has to stay enabled for the host SOF callback.
Host class drivers’ open() now returns the number of descriptor bytes consumed, so xboxh_open and midih_open need a small wrapper.
usb_midi_host: tu_fifo_config() lost its item_size argument, and USBH_EPSIZE_BULK_MAX is now TUH_EPSIZE_BULK_MAX.
tinyusb_stuff.cc needs #include .
Just letting you know what worked for me. Happy to share the diff or test anything.
It’s been some time since I tried to get it running on newest versions of everything. I don’t normally update the library versions every release in part because I don’t want to break people’s existing setups and I don’t really have a way to test all the devices out there by myself.
But it seems now might be a good time to look into it again.
That’s understandable. While this ended up working perfectly for me, I can’t personally verify that there are no regressions for setups different than mine.
If do decide to update, I would avoid the 0.21.0 release itself. It has a couple problems that are only sorted out in master:
My dongle behind the v5’s hub still failed with 0.21.0. It took master to get it working.
So 0.22.0 will probably be the safer target, unless you’re comfortable going with pre-release code.
There’s one more thing that doesn’t affect v5, but might matter for the single Pico boards, and isn’t fixed upstream yet: with current TinyUSB, a device that drops off the bus in the first 150 ms after connecting is never picked up again on a Pico-PIO-USB port, even after a replug, until a reboot. 0.17 isn’t affected because it resets the port straight away. I hit it on GP2040-CE with the same dongle and reported it to TinyUSB, with the fix that worked for me. The fix is only 4 lines, but I don’t know if/when it will make it into tinyusb: Pico-PIO-USB host: a device that drops off the root port during attach debounce is never reported again · Issue #4271 · hathach/tinyusb · GitHub
