Device not responsive unless plugged in after hid-remapper boots (Feather, PC host)

[NReilingh]

I just set up a new build using the Adafruit Feather RP2040 USB Host device and the r2024-12-05 release. Almost everything works, except if I have my device already plugged in to the Feather when it is powered on (by being plugged in to my PC or pressing the Reset button on the Feather), the device is apparently not recognized by hid-remapper until it is replugged.

I can test with two machines at the moment, and this behavior is not present when the Feather is connected on my Mac. When connected to my Windows PC (a Lenovo mini PC), on any of its five USB ports, and no other USB devices connected, the behavior is observed.

After rebooting the feather (before re-plugging the keyboard), and trying to send inputs from the keyboard, I do not see any activity on the Feather's red LED that I usually see when it is relaying inputs. I also do not see any evidence of the keyboard itself being powered on -- that is, if I leave num lock on, I do not see the indicator on the keyboard light up until I replug the keyboard to the Feather.

My hardware configuration is a Lenovo SK8845 (keyboard + trackpad/trackpoint device) -> Adafruit Feather -> Lenovo ThinkCentre M73 Tiny (10AY001RUS).

I just noticed I'm running a 10-year-old BIOS on the M73 so I will install updates and report back if that resolves the issue.

[NReilingh]

Nope, no change after updating the PC's BIOS.

Very curious about what this could be. I would not have expected the upstream device to have an effect on the behavior of hid-remapper.

[jfedor2]

I'm not sure what's going on, but I have seen something similar with hubs. Some hubs will work when plugged into HID Remapper regardless of the order of plugging things in, but some will only work if plugged in in specific order. It hasn't occurred to me at the time that it might also depend on the host so I might have to do some more testing.

With the Feather specifically, we have the option of controlling the power that goes to the device that is plugged in so we might be able to add a delay before the device powers up, which might or might not help.

[NReilingh]

I did have some initial hesitations about this device since I had suspected it uses an internal hub, but I didn't confirm this sooner after having read about hid-remapper's support for hubs. I just checked in macOS System Information to confirm and it does indeed present as a hub:

Based on how I observe the problematic behavior, staging the USB host powerup sounds very plausible to me as something worth testing. Given that this device is bus-powered, I would expect that this would be functionally equivalent to plugging in the device immediately after the Feather boots, which is one of the existing workarounds. Still seems like a puzzle as to why this works without any trouble on my Mac, though. Could there be some behavior in hid-remapper that varies based on the host OS?

Nice project, by the way :) What little I've seen so far strikes me as a terrific accomplishment!

[jfedor2]

This might be related to how we are syncing the SOF packets we're sending on the device side to the ones we're receiving on the host side (which is a thing we do on the single Pico HID Remapper variant).

The difference between hosts might be the time between when the power goes on and when it starts sending the SOF packets. If there's a nontrivial delay then we might be trying to enumerate on the device side, but not sending SOF packets, which might cause it to fail.

I need to look into it.

[jfedor2]

I did some quick testing and on a hub that uses the FE1.1s chip, disabling the SOF synchronization seems to help (the hub now works regardless of the order of plugging things in).

I will think on how to fix this properly, but you can try this test build and see if it helps in your case ("artifact" link at the bottom):

https://github.com/jfedor2/hid-remapper/actions/runs/12773746848

[valdotdev]

I was actually experiencing this the very first time I used HID remapper but the problem was trivial at the time since re-plugging the device wasn't that time-consuming. But then I saw this issue and thought this might wear out the USB ports over time and got a bit concerned. What's more is that I'm also using a pretty standard USB hub (from Ugreen) and plugged into a KVM like here (built into my monitor).

I'll try out the build for a few days and see what happens.

EDIT: So far so good after doing multiple cold boots. But my problem with the KVM is still there (unresponsive when switching and if my monitor us off and I turn it back on my mouse is unresponsive)

[NReilingh]

@jfedor2 Thanks -- that build indeed fixed the issue I was experiencing.

[scatterthought]

The test build also worked for me with a hub that had this issue, using a Waveshare RP2040-Zero on Windows 11. Thanks!

[spitsw]

Encountered this issue with a cheap aliexpress USB hub and Single PICO variant.

USB hub: 0x7211
Vendor ID: 0x0a05

The test build worked for me.