VirtualHere Server: Linux ARM64 4.8.8
VirtualHere Client: Windows 6.0.2
Hardware:
Raspberry Pi 4B
4x 8BitDo Ultimate 2 Wireless Controller
Receiver dynamically changes:
2dc8:3109 -> 2dc8:310b -> sometimes 057e:2009
When this happens:
SURPRISE UNBOUND
Error 22 discarding urb / abort endpoint
The onReset workaround fixes the original:
Error -1 resetting device / BIND_ERROR but does not fix the SURPRISE UNBOUND.
This appears identical to: "8bitdo Ultimate 2 controller USB dongle keeps disconnecting"
node/4656
The Windows test build received an 8BitDo dynamic-state workaround.
Is the same workaround available in the Linux ARM64 server?
.
Can you right click on the dongle and select Custom Event Handler... and paste in
onSetConfiguration=then press OK and try again
Thanks for the quick reply !…
Thanks for the quick reply !
I tried onSetConfiguration= for the last couples days it made it worst
Ultimate 2 Bluetooth FW 2.00
2.4 GHz receiver
Raspberry Pi 4 / Debian 13 / kernel 6.18.34
3109 → 310b when controller connects.
Current configuration:
AutoAttachToKernel=0
onReset.2dc8.3109=
onReset.2dc8.310b=
onSetConfiguration (removed)
Observed:
- Without polling, 310b eventually disconnects / SURPRISE UNBOUND.
- Allowing USB RESET on 310b makes it worse.
- Keeping /dev/input/eventX open locally on Linux keeps 310b stable.
- With VirtualHere, continuously calling XInputGetState() on Windows also appears to keep the controller stable.
Could the Linux ARM64 server/client handling for this 8BitDo receiver keep the interrupt/input endpoint polled, or use the same dynamic-device workaround that exists in the Windows server, so an external XInput keepalive is not required?
.
I dont understand why the xinput keepalive is required. It might be some requirement in their firmware to avoid switching and keeping the connection stable.