https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290984
--- Comment #5 from Stefan Schlosser <[email protected]> --- (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! -- You are receiving this mail because: You are the assignee for the bug.
