Solved 8BitDo Pro 2 USB troubles

Seems like it's wrongly detected as Nintendo Pro at a point.


Code:
ugen0.3: <Nintendo.Co.Ltd. Pro Controller> at usbus0
uhid2 numa-domain 0 on uhub2
uhid2: <Nintendo.Co.Ltd. Pro Controller, class 0/0, rev 2.00/2.00, addr 13> on usbus0
ugen0.3: <Nintendo.Co.Ltd. Pro Controller> at usbus0 (disconnected)
uhid2: at uhub2, port 3, addr 13 (disconnected)
uhid2: detached
ugen0.3: <8BitDo 8BitDo Pro 2> at usbus0
uhid2 numa-domain 0 on uhub2
uhid2: <8BitDo 8BitDo Pro 2, rev 2.00/1.14, addr 14> on usbus0

The LEDs that indicate joystick number only briefly switch from all blinking to appropriate LED being lit only (#2 in my case). I guess after "Nintendo" disconnects the joystick's USB interface goes back to uninitialized.

Any quick fix for this one?
(and yes, gamepad really doesn't work, jstest-sdl detects it but doesn't get any input)
 
There is a switch on the backside labeled "S A D X". S is a Switch Pro controller emulation (hence the reported name), X is an Xbox 360 emulation (the only mode working out-of-the-box on FreeBSD, I believe), what other two modes are doing I don't quite remember. The controller doesn't disconnect or sleep when wired.
For decent experience you'll want to rebuild SDL with the HIDAPI option, since the built-in FreeBSD Xbox 360 support is kind of meh.
 
Last edited:
I've read the usbhid/hgame manpage but didn't gather the default is off. After enabling the sysctl;

Code:
ugen0.3: <Nintendo.Co.Ltd. Pro Controller> at usbus0
usbhid0 numa-domain 0 on uhub2
usbhid0: <Nintendo.Co.Ltd. Pro Controller, class 0/0, rev 2.00/2.00, addr 19> on usbus0
hidbus0: <HID bus> numa-domain 0 on usbhid0
hgame0: <Nintendo.Co.Ltd. Pro Controller Joystick> numa-domain 0 on hidbus0
ugen0.3: <Nintendo.Co.Ltd. Pro Controller> at usbus0 (disconnected)
usbhid0: at uhub2, port 3, addr 19 (disconnected)
hgame0: detached
hidbus0: detached
usbhid0: detached
ugen0.3: <8BitDo 8BitDo Pro 2> at usbus0
usbhid0 numa-domain 0 on uhub2
usbhid0: <8BitDo 8BitDo Pro 2, rev 2.00/1.14, addr 20> on usbus0
hidbus0: <HID bus> numa-domain 0 on usbhid0
jstest-sdl and joytran now detect no devices. Should I have a difference in /dev/input/event nodes if gamepad is disconnected? Because there isn't one. I don't want to map my controller to keyboard via antimicro or via X events or whatever, I want SDL to use it as directly as possible.

There is a switch on the backside labeled "S A D X". S is a Switch Pro controller emulation (hence the reported name), X is an Xbox 360 emulation (the only mode working out-of-the-box on FreeBSD, I believe), what other two modes are doing I don't quite remember. The controlled disconnect or sleep when wired.
For decent experience you'll want to rebuild SDL with the HIDAPI option, since the built-in FreeBSD Xbox 360 support is kind of meh.

I don't have any switches unless you're referring to the insides of the controller.
All I'm concerned about is lag between input and game, anything apart basic SNES layout doesn't concern me, such as track input, analogs or whatever modern controllers bring in.
 
Nope,

1693865453112.png



https://forums.freebsd.org/threads/ppsspp-controller-issues.84154/post-556682 <- are these the missing steps, e.g. devfs permissions?
 
The B button thing did it, so holding the B button while connecting the USB initializes the joystick to nr.1.
hgame is now bound and there is an additional /dev/input/event node.

joytran/jstest-sdl still report nothing
mesen doesn't work
retroarch doesn't work (hid driver, but neither udev or sdl)

Going to reinstall sdl with hid support now and report back.
By the way, wasn't situation way better in the past? I had no troubles connecting a gamepad and playing emulators, built a few FreeBSD+ZSNES 'embeded' boxes out of old PC hardware to play on the TV, maybe 10 years ago, also with FreeBSD 11/12 I used DS4 normally without any hassles. Did SDL drop something meanwhile?
 
It is definitely devfs issue because joytran sees it as root. However I've also recompiled SDL meanwhile
 
Back
Top