8BitDo Ultimate 2.4GHz wifi working in linux

8BitDoUltimateWifi_Linux.MD

FROM https://www.reddit.com/r/Fedora/comments/zmvkdj/8bitdo_ultimate_bluetooth_controller_working_in/

---

I've bought this new controller from 8BitDo and wished to use on linux, to my sadness the controller didn't work out of the box, neither by cable, the 2.4G dongle or bluetooth.

So I've tried a number of solutions and this one from u/GodOfEmus over in the 8bitdo community was the one to work for me:

1. Create a new file /etc/udev/rules.d/99-8bitdo-xinput.rules
2. Paste this udev rule in there, then save and exit the file:

  ACTION=="add", ATTRS{idVendor}=="2dc8", ATTRS{idProduct}=="3106", RUN+="/sbin/modprobe xpad", RUN+="/bin/sh -c 'echo 2dc8 3106 > /sys/bus/usb/drivers/xpad/new_id'"

3. Run the following command in a terminal: sudo udevadm control --reload
4. Unplug and replug the controller if it was already plugged in, it might take a second if you have the bluetooth version

It will basically "cheat" the OS to see the controller as an generic xbox device, so sadly no bluetooth nor gyro control if you care about that, but the rumbling is working for me.

Link to the original post: https://www.reddit.com/r/8bitdo/comments/ykdsmv/ultimate_24_ghz_model_right_analog_not_working_in/

And link to the comment of u/GodOfEmus with the solution: https://www.reddit.com/r/8bitdo/comments/ykdsmv/comment/iv48s4k/?utm_source=share&utm_medium=web2x&context=3

Sharing this solution here to spread the word in our community

This worked for me with the "8BitDo Ultimate C 2.4G" on "Ubuntu 22.04.3 LTS". Thank you for writing this down as a Gist!

the buttons are switched

This works... kinda.

After the modification, if I turn on the controller (remove it from cradle), it will switch off after about 5-7 seconds. It's as if the OS isn't "keeping it alive." If I have something open that is actually POLLING the gamepad (like KDE's Game Controller configuration tool thing in settings) it seems to stay on, at least longer. It stayed on for about a minute in test. As soon as I close the config tool that's polling the controller, it automatically shuts off again.

The Windows driver must do some kind of "keepalive" packet once every few seconds to tell it to stay on. Linux isn't doing this because, it's being fooled to support a radio device I guess, and the controller isn't hearing anything from the PC.

thank you! this worked on my 8bitdo Ultimate C 2.4G on Orange Pi PC Plus running Lakka 4.3

Thanks a lot! This worked for my 8bitdo Ultimate C 2.4G on Ubuntu 22.04.3 LTS and 5.15.0-86-generic kernel

Apparently kernel 6.3 has built-in support.

Thank you so much!! Worked perfectly for my "8bitdo Ultimate C 2.4G" on Linux Mint 21.

@mercster I tend to agree

[66950.570410] usb 3-2: USB disconnect, device number 2
[66951.340575] usb 3-2: new full-speed USB device number 4 using xhci_hcd
[66951.513979] usb 3-2: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice= 1.14
[66951.513983] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[66951.513984] usb 3-2: Product: Ultimate Wireless Controller
[66951.513985] usb 3-2: Manufacturer: 8BitDo
[66951.513986] usb 3-2: SerialNumber: ed4534d817e4
[66952.510912] usb 3-2: USB disconnect, device number 4
[66953.780557] usb 3-2: new full-speed USB device number 5 using xhci_hcd
[66953.953982] usb 3-2: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 2.00
[66953.953986] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[66953.953987] usb 3-2: Product: Pro Controller
[66953.953988] usb 3-2: Manufacturer: Nintendo.Co.Ltd.
[66953.953989] usb 3-2: SerialNumber: 000000000001
[66953.983973] usb 3-2: can't set config #1, error -71
[66953.984046] usb 3-2: USB disconnect, device number 5
[66955.232545] usb 3-2: new full-speed USB device number 6 using xhci_hcd
[66955.405982] usb 3-2: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice= 1.14
[66955.405986] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[66955.405987] usb 3-2: Product: Ultimate Wireless Controller
[66955.405988] usb 3-2: Manufacturer: 8BitDo
[66955.405989] usb 3-2: SerialNumber: ed4534d817e4
[67274.943918] usb 3-2: USB disconnect, device number 6
[67275.713559] usb 3-2: new full-speed USB device number 7 using xhci_hcd
[67275.881304] usb 3-2: New USB device found, idVendor=2dc8, idProduct=3109, bcdDevice= 2.00
[67275.881308] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[67275.881309] usb 3-2: Product: Ultimate Wireless Controller
[67275.881310] usb 3-2: Manufacturer: 8BitDo
[67275.881311] usb 3-2: SerialNumber: ed4534d817e4
[67275.901453] hid-generic 0003:2DC8:3109.0022: hiddev0,hidraw0: USB HID v1.11 Device [8BitDo Ultimate Wireless Controller] on usb-0000:06:00.3-2/input0

That's what you get in dmesg when you remove the controller from the cradle, and then put it back again.

Interestingly - it seems the Nintendo Pro controller feature IS being advertised during the connection process.

Seems like

• The wireless dongle pretends to be an XBox controller "at rest"
• When the controller connects, it disconnects and pretends to be a new one
• Then if it doesn't receive some kind of ACK from the driver, it pretends to be the Switch controller
• Then when THAT doesn't happen it goes back to being an XBox controller
• Then when you put the controller back on the charger the adapter goes back to being another XBox controller

I don't know what you need to "say" to the wireless adapter to convince it that you're happy though.

Saw that there is now a Nintendo HID module for 5.16 kernels and up, so if you manually load the hid-nintendo driver, you get a bunch of extra output in the kernel log....

[  146.072107] usb 1-4: USB disconnect, device number 12
[  147.326989] usb 1-4: new full-speed USB device number 13 using xhci_hcd
[  147.478415] usb 1-4: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 2.00
[  147.478431] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  147.478439] usb 1-4: Product: Pro Controller
[  147.478445] usb 1-4: Manufacturer: Nintendo.Co.Ltd.
[  147.478450] usb 1-4: SerialNumber: 000000000001
[  147.484123] nintendo 0003:057E:2009.0004: hidraw0: USB HID v81.11 Joystick [Nintendo.Co.Ltd. Pro Controller] on usb-0000:00:14.0-4/input0
[  147.588145] nintendo 0003:057E:2009.0004: failed reading SPI flash; ret=-71
[  147.588163] nintendo 0003:057E:2009.0004: using factory cal for left stick
[  147.596202] nintendo 0003:057E:2009.0004: failed reading SPI flash; ret=-71
[  147.596220] nintendo 0003:057E:2009.0004: using factory cal for right stick
[  147.603654] nintendo 0003:057E:2009.0004: failed reading SPI flash; ret=-71
[  147.603671] nintendo 0003:057E:2009.0004: Failed to read left stick cal, using defaults; e=-71
[  147.611876] nintendo 0003:057E:2009.0004: failed reading SPI flash; ret=-71
[  147.611893] nintendo 0003:057E:2009.0004: Failed to read right stick cal, using defaults; e=-71
[  147.619677] nintendo 0003:057E:2009.0004: failed reading SPI flash; ret=-71
[  147.619699] nintendo 0003:057E:2009.0004: using factory cal for IMU
[  147.627751] nintendo 0003:057E:2009.0004: failed reading SPI flash; ret=-71
[  147.627769] nintendo 0003:057E:2009.0004: Failed to read IMU cal, using defaults; ret=-71
[  147.627776] nintendo 0003:057E:2009.0004: Unable to read IMU calibration data
[  147.635647] nintendo 0003:057E:2009.0004: Failed to set report mode; ret=-71
[  147.636036] nintendo 0003:057E:2009.0004: probe - fail = -71
[  147.636069] nintendo: probe of 0003:057E:2009.0004 failed with error -71
[  147.636874] usb 1-4: USB disconnect, device number 13

So if you add... maybe

# /etc/udev/rules.d/99-hid-nintendo.rules
ACTION=="add", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2009", RUN+="/sbin/modprobe hid-nintendo", RUN+="/bin/sh 'echo 057e 2009 > /sys/bus/hid/drivers/nintendo/new_id'"

... whatever stops the controller switching to another profile is what seems to be missing.

(all on controller and wireless dongle firmware 1.03)

@awilkins I have found that if Steam is running in the background (which, it almost always is on my system) it shuts up the logs and "just works" as expected. I'm happy with the Steam fix (it was a new Linux install and I hadn't actually configured Steam to run at boot at the time, which is why I saw this problem.)

However, thinking about it now... I have another device (a flight yoke for flight simulators) that has a similar issue; while it doesn't disconnect after 10 seconds or whatever, it has the constant disconnect/reconnect in log. I found the solution somewhere that I can't remember, so I can't give credit to the original poster, but this is the post I made (and mailed to myself for good measure) about why it works and what to do. You'll have to adapt this for the USB vendor/device IDs for the 8bitdo controller (vendor/dev ID for the yoke is 294B:1900 in the below fix), but try it and let me know if it works.

--

ATTENTION: I have solved the Honeycomb Alpha Yoke constantly connecting/disconnecting in Ubuntu 20.04.

Well, that would be too generous to myself. I used my troubleshooting skills to identify a similar problem in other hardware, and deduce that the solution to that problem works for the Alpha Yoke.

The problem is that the Alpha Yoke has a quirk that requires it to be constantly polled. I just tried finding the source page I got this info from, but I can't find it at the moment. In no way do I want to represent that I used my hardware/kernel knowledge to solve this problem. I'm just good with troubleshooting using the Internet.

To get to the chase, the problem can be solved with two steps:

1. As superuser ("root"), edit the /etc/default/grub text file. We are going to add a kernel boot parameter.

2. On the GRUB_CMDLINE_LINUX_DEFAULT variable, you will probably see something like "quiet splash". We need to add something INSIDE the quotation marks; this is a boot parameter telling the kernel to treat this device a little differently so that it does not constantly connect over and over again. You want to add usbhid.quirks=0x294B:0x1900:0x00000400

So the line for me looks like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbhid.quirks=0x294B:0x1900:0x00000400"

3. Save the file (again this must be done as root.)

4. At the command line again, run this command: sudo update-grub

This inserts the edit you made into the boot files of your computer. Now reboot. You should see that the Honeycomb Alpha Yoke no longer constantly connects/disconnects.

I will continue looking for the source of this info so I can give credit where it is due; it was regarding an unrelated computer mouse that, nonetheless, had the same connect/disconnect issue. I took an educated guess that the usbhid.quirks value needed to be set, and I was correct. Also note that the 0x294B:0x1900 part of the argument SHOULD be the same for all Alpha yokes, but if this does not work for you, let me know and I will help you find the correct address for your system.

@awilkins what does that do and where do you need to put that code?

@catrock31 The where is in the first line comment ; it's a udev rule. On Linux, these are triggered by devices being added to the system - so in this case, it detects the Switch Pro controller "aspect" of the controller (you can see this turn up in the middle of my logs), and loads the hid-nintendo Switch Pro controller driver.

RUN+="/sbin/modprobe hid-nintendo"

And then it sends the controller ID to the driver (here I am just copying what the original poster wrote).

RUN+="/bin/sh 'echo 057e 2009 > /sys/bus/hid/drivers/nintendo/new_id'"

If it worked - you might have to pick a rule depending on which controller you wanted.

Sadly, it doesn't work. Here's the rule from the top post - loads the XBox driver, registers the pad.... then the controller switches itself off. Something must be needed to keep it awake.

[ 1211.121953] usb 3-2: new full-speed USB device number 9 using xhci_hcd
[ 1211.295474] usb 3-2: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice= 1.14
[ 1211.295479] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1211.295481] usb 3-2: Product: Ultimate Wireless Controller
[ 1211.295483] usb 3-2: Manufacturer: 8BitDo
[ 1211.295484] usb 3-2: SerialNumber: 9c1257d817e4
[ 1211.315613] input: Generic X-Box pad as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:06:00.3/usb3/3-2/3-2:1.0/input/input30
[ 1211.317741] usb 3-2: USB disconnect, device number 9
[ 1211.317847] xpad 3-2:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19

Here's what you get when you hook it up on the wire.

[ 1380.432980] usb 1-2.1: new full-speed USB device number 15 using xhci_hcd
[ 1380.548716] usb 1-2.1: New USB device found, idVendor=057e, idProduct=2009, bcdDevice= 2.00
[ 1380.548722] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1380.548724] usb 1-2.1: Product: Pro Controller
[ 1380.548726] usb 1-2.1: Manufacturer: Nintendo.Co.Ltd.
[ 1380.548727] usb 1-2.1: SerialNumber: 000000000001
[ 1380.624856] input: Nintendo.Co.Ltd. Pro Controller as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:06:00.1/usb1/1-2/1-2.1/1-2.1:1.0/0003:057E:2009.0017/input/input31
[ 1380.625054] hid-generic 0003:057E:2009.0017: input,hidraw4: USB HID v1.11 Joystick [Nintendo.Co.Ltd. Pro Controller] on usb-0000:06:00.1-2.1/input0
[ 1383.789155] usb 1-2.1: USB disconnect, device number 15
[ 1384.080884] usb 1-2.1: new full-speed USB device number 16 using xhci_hcd
[ 1384.198314] usb 1-2.1: New USB device found, idVendor=2dc8, idProduct=3106, bcdDevice= 1.14
[ 1384.198319] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1384.198322] usb 1-2.1: Product: 8BitDo Ultimate Controller
[ 1384.198323] usb 1-2.1: Manufacturer: 8BitDo
[ 1384.198324] usb 1-2.1: SerialNumber: cf33ecd817e4
[ 1384.267836] input: Generic X-Box pad as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:06:00.1/usb1/1-2/1-2.1/1-2.1:1.0/input/input32

Again, both devices are announced, but the controller rapidly switches to the XBox mode. The controller sticks around though, instead of shutting off.

Not all the buttons register - the back paddles and two extra buttons in the middle don't show up.

The wifi mode works fine for me ; as long as I have Steam running when the controller comes online.

Tellingly, there's a little twitch on the vibration motor - I get this when I remove the controller from the dock on Windows as well. There must be some traffic that needs to go back to the controller to tell it that it's been registered, that triggers the twitch. If I have jstest-gtk open when I close Steam, the controller stays alive - until I close jstest-gtk - then it goes offline again.

Given that the controller seems to offer up the Switch Pro mode as an option - regardless of whether it's on wifi or wired USB - it would also seem that if you can "grab" this controller profile instead, you could use it.

@awilkins Did you try adding that USB quirk value to grub?

Thanks a lot! This worked for me. If the udev rule isn't working for you try changing the idProduct. 3106 did not work for me but 3016 did. Not sure why. dmesg showed several different idProduct numbers and 3106 was one of them.

Hello, can you explain step by step how to "Create a new file /etc/udev/rules.d/99-8bitdo-xinput.rules"? Thx.

Hello, can you explain step by step how to "Create a new file /etc/udev/rules.d/99-8bitdo-xinput.rules"? Thx.

# To create it
sudo touch /etc/udev/rules.d/99-8bitdo-xinput.rules
# To edit it (you can also use vim, gedit, whatever) 
sudo nano /etc/udev/rules.d/99-8bitdo-xinput.rules 

you just got me up and running, thanks!

Now I'm trying to see if there is a way to wake my pc with the 2.4Ghz USB on controller boot...

update to that wake venture, I got it working with these two articles (I had an issue with rc.local on debian 12 so the second article is for that):

USB Wake:
https://www.makeuseof.com/wake-your-linux-pc-from-suspend-using-usb-devices/

Enable rc.local:
https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-systemd

Thank you, worked on my Powkiddy x55 running JELOS!

The original instructions work for me on Fedora 39, thank youi!! I was wondering if there was a way to get the paddles on the back working?

The original instructions work for me on Fedora 39, thank youi!! I was wondering if there was a way to get the paddles on the back working?

To the best of my understanding the paddles are programmed at the firmware level have to be assigned to another button or macro in the 8BitDo software. I loaded up the tool in a Windows VM, did USB passthrough with the controller, and wrote the firmware with the new assignments there. Once I saved it they worked back in my linux machine when connected as set.

Wow, that's very interesting!
Which mode are you using it in? The controller reports itself as 8BitDo Pro 2 Wired Controller in jstest with only 10 buttons
How does yours report itself?

EDIT: I just tried what @ammuench mentioned, set what I wanted to the paddles in a Windows VM, and now the paddles work as expected, as do the profiles / profile switching. Amazing stuff, thank you so much!

JFYI: it works out of the box on latest Linux Mint 21.3 with 6.5 kernel. Also it works out of the box on Steam Deck.

This was a big help, thanks!

Works out of the box in Fedora 40 now! I just bought the controller, plugged the 2.4GHz dongle in and it just works! also works via cable. Tho I only tested X input mode