I had similar problems with the 8BitDo USB Wireless Adapter 2 and the SN30 Pro Bluetooth gamepad (haven't used the dongle with any other gamepad):

https://forums.freebsd.org/threads/8bitdo-usb-wireless-adapter-2-disconnects-instantly.87212

It worked after I updated the firmware of the dongle and the gamepad to the latest version via 8BitDo's Upgrade tool:

https://support.8bitdo.com/firmware-updater.html

This is worth a try if you haven't updated the firmware of the dongle yet. I hope this helps.

Best regards,
Stefan

Comment 2 Alexander Ziaee 2025-11-13 21:33:28 UTC

Thanks Stefan!

I have both the Switch Pro controller updated, and the dongle. Can you tell me a little more about the setup? Using DInput mode? What kind of perms for devfs.rules, or are you doing something different. Using webcamd?

Comment 3 Alexander Ziaee 2025-11-13 21:33:35 UTC

Thanks Stefan!

I have both the Switch Pro controller updated, and the dongle. Can you tell me a little more about the setup? Using DInput mode? What kind of perms for devfs.rules, or are you doing something different. Using webcamd?

Comment 4 Vladimir Kondratyev 2025-11-13 22:25:13 UTC

Created attachment 265403 [details]
set_evdev_cdevs_to_root:games_660_mode_for_gamepads.patch

Try this patch instead of editing devfs.rules. Just add youself to the games group to get access to gamepads/joystics as non-root user.

(In reply to Alexander Ziaee from comment #2)

I'm on 14.3-RELEASE-p5 and have the following lines in /boot/loader.conf so the specialized gamepad drivers hgame(4), ps4dshock(4) or xb360gp(4) take precedence over the generic USB HID drivers:

  usbhid_load="YES"
  hw.usb.usbhid.enable=1

I don't use webcamd(8). But more on this later.

I currently don't use devfs.rules for setting the right permissions. I set them manually after plugging in a gamepad/dongle, just out of habit. I really should automate this...

  # chmod 666 /dev/input/event13
  # chmod 666 /dev/usb/0.5.*

where /dev/input/event13 and /dev/usb/0.5.{0-3} are almost always the devices created when connecting the gamepad/dongle. Although it is often enough to only set the correct permissions on the /dev/input/* devices, be aware that some programs/libraries have the ability to access the gamepad via the /dev/usb/* devices, e.g. SDL2/3 with their HIDAPI input drivers. In this case, the /dev/input/* devices aren't even necessary for the gamepad to work. But this is depending on the application of course. I advise to set the permissions on both, /dev/input/* and /dev/usb/*, regardless.

In order to test if FreeBSD and the gamepad/dongle are successfully in a working state, I just cat the corresponding /dev/input/* device as root, this circumvents any problems related to permissions just for testing:

  # cat /dev/input/event13

You should see emitted byte sequences on your console/terminal emulator while pressing buttons or pushing analog sticks on your gamepad. If that's the case, then your gamepad/dongle is working on FreeBSD on the driver level.

Now, this is the dmesg output when I plug in the 8BitDo Adapter 2 on a runnig system (gamepad is off/not paired with the dongle):
`
[52261.660284] ugen0.5: <8BitDo 8BitDo Receiver> at usbus0
[52261.661142] usbhid5 on uhub1
[52261.661162] usbhid5: <8BitDo 8BitDo Receiver, class 0/0, rev 1.10/2.00, addr 11> on usbus0
[52261.661461] hidbus5: <HID bus> on usbhid5
[52261.662238] hgame0: <8BitDo 8BitDo Receiver Gamepad> on hidbus5
[52262.058955] ugen0.5: <8BitDo 8BitDo Receiver> at usbus0 (disconnected)
[52262.058991] usbhid5: at uhub1, port 3, addr 11 (disconnected)
[52262.059098] hgame0: detached
[52262.068148] hidbus5: detached
[52262.068197] usbhid5: detached
[52262.523268] ugen0.5: <Nintendo Co., Ltd. Pro Controller> at usbus0
[52262.524067] usbhid5 on uhub1
[52262.524095] usbhid5: <Nintendo Co., Ltd. Pro Controller, class 0/0, rev 2.00/2.10, addr 12> on usbus0
[52262.524355] hidbus5: <HID bus> on usbhid5
[52262.525247] hgame0: <Nintendo Co., Ltd. Pro Controller Joystick> on hidbus5
[52263.121693] ugen0.5: <Nintendo Co., Ltd. Pro Controller> at usbus0 (disconnected)
[52263.121730] usbhid5: at uhub1, port 3, addr 12 (disconnected)
[52263.121822] hgame0: detached
[52263.130149] hidbus5: detached
[52263.130204] usbhid5: detached
[52263.585149] ugen0.5: <8BitDo IDLE> at usbus0
[52263.585708] usbhid5 on uhub1
[52263.585728] usbhid5: <8BitDo IDLE, class 0/0, rev 1.10/2.00, addr 13> on usbus0
[52263.585973] hidbus5: <HID bus> on usbhid5
`
`
# usbconfig -v -d 0.5
ugen0.5: <IDLE 8BitDo> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)
ugen0.5.0: usbhid5: <8BitDo IDLE, class 0/0, rev 1.10/2.00, addr 13>

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0110
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0040
  idVendor = 0x2dc8
  idProduct = 0x3107
  bcdDevice = 0x0200
  iManufacturer = 0x0001  <8BitDo>
  iProduct = 0x0002  <IDLE>
  iSerialNumber = 0x0003  <E417D819D497>
  bNumConfigurations = 0x0001


 Configuration index 0

    bLength = 0x0009
    bDescriptorType = 0x0002
    wTotalLength = 0x0029
    bNumInterfaces = 0x0001
    bConfigurationValue = 0x0001
    iConfiguration = 0x0000  <no string>
    bmAttributes = 0x0080
    bMaxPower = 0x00fa

    Interface 0
      bLength = 0x0009
      bDescriptorType = 0x0004
      bInterfaceNumber = 0x0000
      bAlternateSetting = 0x0000
      bNumEndpoints = 0x0002
      bInterfaceClass = 0x0003  <HID device>
      bInterfaceSubClass = 0x0000
      bInterfaceProtocol = 0x0000
      iInterface = 0x0000  <no string>

      Additional Descriptor

      bLength = 0x09
      bDescriptorType = 0x21
      bDescriptorSubType = 0x10
       RAW dump:
       0x00 | 0x09, 0x21, 0x10, 0x01, 0x00, 0x01, 0x22, 0x25,
       0x08 | 0x00

     Endpoint 0
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040
        bInterval = 0x0008
        bRefresh = 0x0000
        bSynchAddress = 0x0000

     Endpoint 1
        bLength = 0x0007
        bDescriptorType = 0x0005
        bEndpointAddress = 0x0002  <OUT>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040
        bInterval = 0x0008
        bRefresh = 0x0000
        bSynchAddress = 0x0000
`

Now, as you know, gamepads often have different input modes, e.g. "DInput" and "XInput". My SN30 Pro gamepad has two additional modes: "MacOS" and "Switch". When I use this gamepad wired without the dongle, only the DInput and MacOS modes work directly with the hgame(4) driver. For the Switch mode hgame(4) attaches, but the gamepad doesn't work, cat /dev/input/event13 stays silent. I think I once tested the Switch mode with webcamd(8) and it did work (had to remove the lines from /boot/loader.conf, or else hgame(4) would attach). For the XInput mode hgame(4) doesn't attach and I have to use webcamd(8).

Now, as it turns out, the 8BitDo Adapter 2 dongle can also be in different modes! If you search the internet you might find a PDF manual for this dongle which actually explains this (AFAIK the manuals on 8BitDo's homepage lack this info...).

This obviously works with 8BitDo's gamepads like my SN30 Pro, but I don't know if it works with gamepads from other brands:

While your gamepad is already active and paired with the dongle, you can hold the Select button and one of the directional buttons (up, right, down, left) for several seconds and the dongle will switch to another mode.

This is the dmesg output when switching modes:

Dongle in XInput mode (Select + up):
`
[52589.918118] ugen0.5: <8BitDo 8BitDo Receiver> at usbus0
[52589.918378] usbhid5 on uhub1
[52589.918397] usbhid5: <8BitDo 8BitDo Receiver, rev 2.00/1.00, addr 15> on usbus0
[52589.918715] hidbus5: <HID bus> on usbhid5
`

Dongle in MacOS mode (Select + right):
`
[53192.429904] ugen0.5: <8BitDo 8BitDo Receiver> at usbus0
[53192.431244] usbhid5 on uhub1
[53192.431269] usbhid5: <8BitDo 8BitDo Receiver, class 0/0, rev 2.00/1.00, addr 18> on usbus0
[53192.431578] hidbus5: <HID bus> on usbhid5
[53192.433235] hgame0: <8BitDo 8BitDo Receiver Gamepad> on hidbus5
`

Dongle in some "unknown" mode (Select + down):
`
53078.865612] ugen0.5: <Sony Interactive Entertainment Controller> at usbus0
[53078.866256] usbhid5 on uhub1
[53078.866280] usbhid5: <Sony Interactive Entertainment Controller, class 0/0, rev 1.10/1.00, addr 17> on usbus0
[53078.866602] hidbus5: <HID bus> on usbhid5
[53078.867134] hgame0: <Sony Interactive Entertainment Controller Gamepad> on hidbus5
[53078.867690] usbhid6 on uhub1
[53078.867711] usbhid6: <Sony Interactive Entertainment Controller, class 0/0, rev 1.10/1.00, addr 17> on usbus0
[53078.867962] hidbus6: <HID bus> on usbhid6
[53078.868522] hcons2: <Sony Interactive Entertainment Controller Consumer Control> on hidbus6
[53078.868923] hsctrl2: <Sony Interactive Entertainment Controller System Control> on hidbus6
`

Dongle in DInput mode (Select + left):
`
[52771.980952] ugen0.5: <8BitDo 8BitDo Receiver> at usbus0
[52771.981650] usbhid5 on uhub1
[52771.981670] usbhid5: <8BitDo 8BitDo Receiver, class 0/0, rev 1.10/2.00, addr 16> on usbus0
[52771.981927] hidbus5: <HID bus> on usbhid5
[52771.982705] hgame0: <8BitDo 8BitDo Receiver Gamepad> on hidbus5
`

Similar to the behaviour in wired usage, the gamepad works with the dongle when the dongle is in DInput or MacOS mode. The weird "unknown" mode works partially, some buttons and the analog sticks aren't recognized. And the XInput mode doesn't work at all, even using webcamd(8) is useless in this mode.


Maybe you can try to set the dongle to different modes and see if this makes a difference.

Don't hesitate to ask for more info if needed!

(In reply to Stefan Schlosser from comment #5)

> Now, as you know, gamepads often have different input modes, e.g. "DInput" and "XInput". My SN30 Pro gamepad has two additional modes: "MacOS" and "Switch".

Looking at my Pro 2 and its manual, the modes are: S - Switch (should be suitable for the actual console), A - Apple (seems to be DualShock 4 emulation for whatever reason, probably not complete enough to claim it as such), D - Android (?), X - Windows (Xbox360).

On FreeBSD you always want the X one.

> For the XInput mode hgame(4) doesn't attach and I have to use webcamd(8).

As far as I'm concerned there are only 2 drivers: xb360gp and ps4dshock. I'm not sure what's the exact intention behind hgame, but it doesn't seem to be directly suitable for driving anything in particular.

(In reply to Alex S from comment #6)

> On FreeBSD you always want the X one.

(Assuming you don't intend to use the built-in gyroscope in those controllers.)

(In reply to Alex S from comment #6)

> As far as I'm concerned there are only 2 drivers: xb360gp and ps4dshock. I'm not
> sure what's the exact intention behind hgame, but it doesn't seem to be directly
> suitable for driving anything in particular.
I think hgame is a generic driver intented for any gamepad which isn't recognized as a either a PS4 Dualshock or XBox360 controller. So far it works well with my SN30 Pro.

This makes me curious: is your Pro 2 gamepad actually detected as a XBox360 controller and does xb360gp attach to it if you set it to the XInput mode?

(In reply to Stefan Schlosser from comment #8)

> So far it works well with my SN30 Pro.

It only "works well" if you don't pay attention to the default button/axis mapping. Install evtest and look at it yourself.

> This makes me curious: is your Pro 2 gamepad actually detected as a XBox360 controller and does xb360gp attach to it if you set it to the XInput mode?

It does. Although I vastly prefer SDL's bundled drivers to xb360gp.

(In reply to Alex S from comment #9)

> It does.
Very interesting. While hgame and ps4shock are loading and attaching automatically, I had to load xb360gp manually for it to attach to my gamepad in XInput mode. Now I can use my SN30 Pro with xb360gp instead of webcamd in wired XInput mode. Nice!

The 8BitDo Adapter 2 in XInput mode is now also recognized and xb360gp attaches, but it still doesn't work through /dev/input/*. It is working with the SDL drivers though, correct permissions on /dev/usb/* provided.

> Although I vastly prefer SDL's bundled drivers to xb360gp.
What are the advantages of SDL's drivers?

> It only "works well" if you don't pay attention to the default button/axis mapping.
> Install evtest and look at it yourself.
Thanks for recommending x11/evtest. I tested it with xb360gp in XInput mode and with hgame in DInput mode. The mapping is correct with xbox360gp while it's all over the place with hgame.
But I didn't encounter ill effects with hgame for my use cases, I have to do application-specific mappings regardless, e.g. in emulators/ares. So, hgame still works "well enough" for me :-)

(In reply to Stefan Schlosser from comment #10)

> It is working with the SDL drivers though, correct permissions on /dev/usb/* provided.

games/devd-controller-rules was committed a few days ago.

> What are the advantages of SDL's drivers?

SDL has more drivers, the mapping is always correct,
force feedback works, additional features like
gyro/accelerometer are generally expected to work.

The kernel drivers are still useful for a few apps that use evdev
directly (can't think of any examples at the moment) and Linux games
running under Linuxulator (where hidraw used by hidapi SDL drivers
is currently broken).