Pro Controller disconnects when connected via Bluetooth

[twoxa]

When using the Pro Controller in Bluetooth mode it will randomly disconnect after some time, it might last a few minutes or a few hours (usually its a couple of minutes), it seems random.
When using combined Joycons there is no issue, they work perfectly every time.
When using the Pro Controller in wired mode it works normally.
Tried pairing without joycond, with different Bluetooth adapters, nothing works.
Logs when the controller connects:

Jan 13 20:04:55 Archer kernel: Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Jan 13 20:04:55 Archer kernel: Bluetooth: HIDP socket layer initialized
Jan 13 20:04:55 Archer bluetoothd[1386]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info
Jan 13 20:04:55 Archer systemd[548]: Reached target Bluetooth.
Jan 13 20:04:58 Archer kernel: hid-generic 0005:057E:2009.0006: unknown main item tag 0x0
Jan 13 20:04:58 Archer kernel: input: Pro Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input33
Jan 13 20:04:58 Archer kernel: hid-generic 0005:057E:2009.0006: input,hidraw5: BLUETOOTH HID v0.01 Gamepad [Pro Controller] on 8c:88:2b:40:00:f1
Jan 13 20:04:58 Archer kernel: nintendo 0005:057E:2009.0006: unknown main item tag 0x0
Jan 13 20:04:58 Archer kernel: nintendo 0005:057E:2009.0006: hidraw5: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on 8c:88:2b:40:00:f1
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: using factory cal for left stick
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: using factory cal for right stick
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: using user cal for IMU
Jan 13 20:05:00 Archer kernel: nintendo 0005:057E:2009.0006: controller MAC = 64:B5:C6:44:80:8B
Jan 13 20:05:00 Archer kernel: input: Nintendo Switch Pro Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input34
Jan 13 20:05:00 Archer kernel: input: Nintendo Switch Pro Controller IMU as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input35
Jan 13 20:05:00 Archer joycond[436]: DEVNAME=event257 ACTION=add DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input34/event257
Jan 13 20:05:00 Archer joycond[436]: Creating new phys_ctlr for /dev/input/event257
Jan 13 20:05:00 Archer joycond[436]: Found Pro Controller
Jan 13 20:05:00 Archer joycond[436]: driver_name: Nintendo Switch Pro Controller
Jan 13 20:05:00 Archer joycond[436]: MAC: 64:B5:C6:44:80:8B
Jan 13 20:05:01 Archer joycond[436]: adding epoll_subscriber: fd=5
Jan 13 20:05:01 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 4 dropped IMU reports
Jan 13 20:05:01 Archer kernel: nintendo 0005:057E:2009.0006: delta=90 avg_delta=15

Logs when the controller disconnects:

Jan 13 20:06:29 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 4 dropped IMU reports
Jan 13 20:06:29 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=14
Jan 13 20:06:33 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:33 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=11
Jan 13 20:06:36 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:36 Archer kernel: nintendo 0005:057E:2009.0006: delta=79 avg_delta=11
Jan 13 20:06:41 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:41 Archer kernel: nintendo 0005:057E:2009.0006: delta=77 avg_delta=11
Jan 13 20:06:50 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:50 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=11
Jan 13 20:06:53 Archer kernel: nintendo 0005:057E:2009.0006: compensating for 5 dropped IMU reports
Jan 13 20:06:53 Archer kernel: nintendo 0005:057E:2009.0006: delta=78 avg_delta=11
Jan 13 20:06:58 Archer kernel: nintendo 0005:057E:2009.0006: timeout waiting for input report
Jan 13 20:06:58 Archer joycond[436]: Lone controller paired
Jan 13 20:06:58 Archer joycond[436]: DEVNAME=event257 ACTION=remove DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.4/1-5.1.4:1.0/bluetooth/hci0/hci0:1/0005:057E:2009.0006/input/input34/event257

[dogtopus]

What kind of Bluetooth controller are you using? Judging from the OUI I'm guessing it's one of those cheap USB dongles (probably with very short internal antenna). Could just be signal quality issue then? What does blueman say about the link quality?

[twoxa]

I don't think it's a signal issue because then why would the Joycons work normally (they also use Bluetooth with the same adapter), also tried it with the adapter right next to the controller still disconnects. Tried it on a different computer also running Linux with its internal Bluetooth adapter, still disconnects.

[aeghn]

Thank you for your efforts for this feature!

Same question here.

The pro controller with vibration will disconnect after a few minutes of connection, while it works fine on Windows (same machine) and on my NS.

The bluetooth adapter is: Intel AX200

I am using Archlinux with linux 5.16.12-arch1-1. The logs are as follows:

journalctl -u bluetooth:

Mar 05 17:12:44 chindpc bluetoothd[25826]: Adv Monitor app :1.369 disconnected from D-Bus
Mar 05 17:12:44 chindpc bluetoothd[25826]: Path / reserved for Adv Monitor app :1.370
Mar 05 17:12:44 chindpc bluetoothd[25826]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info
Mar 05 17:12:44 chindpc bluetoothd[25826]: Adv Monitor app :1.370 disconnected from D-Bus

btmon

> HCI Event: Disconnect Complete (0x05) plen 4         #73275 [hci0] 557.690726
        Status: Success (0x00)
        Handle: 512
        Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Device Disconnected (0x000c) plen 8    {0x0001} [hci0] 557.690733
        BR/EDR Address: xx:xx:xx:xx:xx:xx (Nintendo Co.,Ltd)
        Reason: Connection terminated by local host (0x02)
> HCI Event: Number of Completed Pack.. (0x13) plen 5  #73276 [hci0] 557.693726
        Num handles: 1
        Handle: 256
        Count: 1

...

< HCI Command: Disconnect (0x01|0x0006) plen 3         #73569 [hci0] 560.522601
        Handle: 512
        Reason: Authentication Failure (0x05)

...

> HCI Event: Remote Name Req Complete (0x07) plen 255  #73585 [hci0] 560.681756
        Status: Remote User Terminated Connection (0x13)
        Address: xx:xx:xx:xx:xx:xx (Nintendo Co.,Ltd)
        Name:
> HCI Event: Disconnect Complete (0x05) plen 4         #73586 [hci0] 560.682761
        Status: Success (0x00)
        Handle: 512
        Reason: Connection Terminated By Local Host (0x16)
> HCI Event: Number of Completed Pack.. (0x13) plen 5  #73587 [hci0] 560.683760
        Num handles: 1
        Handle: 256
        Count: 1

If the information provided is not enough, I will gladly continue to provide it.

[nfp0]

I have tried my Pro Controllers with 5 different Bluetooth radios and they all presented the same behavior: When used with games that have rumble, they disconnect (specially if more than 1 controller is connected).

I have tried the following Bluetooth radios:

• ID 1131:1004 Integrated System Solution Corp. Bluetooth Device
• ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
• ID 2357:0604 TP-Link TP-Link UB500 Adapter
• ID 0bda:4852 Realtek Semiconductor Corp. Bluetooth Radio
• ID 8087:0a2b Intel Corp. Bluetooth wireless interface

All of them are officially certified Bluetooth products, with the exception of the 1st one.

I tested by playing the N64 Super Smash Bros on RetroArch with 2 Pro Controllers and I consistently get a disconnect usually in less than 5 minutes. Sometimes in just a few seconds.

Using the controllers with rumble through Steam on Windows does not cause a disconnection. That, together with the fact that all 5 radios show the same behavior makes me believe this is not an hardware issue.

@DanielOgorchock @nicman23 I would really like to help you debug this issue. Is there any way for me to help?
Any logs I can provide?

[nfp0]

I forgot to mention:
When using the 2 Pro controllers and a 3rd non-Nintendo controller all connected to the same Bluetooth, only the Pro controllers disconnect after a while, while the 3rd controller, keeps connected and functioning.
Furthermore, the 2 Pro Controllers, usually disconnect at the same time or within a few seconds of each other.

This gives weight to the theory that there must be something wrong in the code and not in the hardware. I wish I knew how to debug this, though.

Should I also post this info on nicman23/dkms-hid-nintendo#33 for awareness?

[twoxa]

It is getting weirder, now the pro controller connects and if it doesn't disconnect in the first 2 minutes then it'll work until I turn it off manually. It usually takes about 3-5 times before it connects for good (so the way I use it now is: connect wait a minute or two see if it doesn't disconnect in that time its good and i can use it for how ever long I want, if it does disconnect then try again until it stays connected for those 1-2 minutes). It works but i have to keep trying to connect until the connection "sticks", not sure if its related but, I did change some settings in /etc/bluetooth/main.conf:

FastConnectable = true
JustWorksRepairing = always
ReconnectAttempts=3
ReconnectIntervals=1,1,2,3,5,8,13,21,34,55
AutoEnable=true

Forgot to mention I am also using Arch Linux on both the machines I tested it on, so it might be an Arch specific issue.

[nfp0]

@twoxa Arch user here too.
Interesting finds. I'll see if I arrive at the same pattern as you.

[nicman23]

@nfp0 sorry i currently do not have any switch controllers to test with. btw what is your system specs and usb controller

[nfp0]

I have tested this on 3 different systems:

• A desktop with an AMD Ryzen 7 3700X (with 3 different USB Bluetooth dongles, listed below)
• A Lenovo Miix 520 laptop with an Intel i5-8250U (integrated Intel Bluetooth)
• A Lenovo P14s laptop with an AMD Ryzen 7 PRO 5850U (integrated Realtek Bluetooth)

On my desktop I have these USB controllers:

• 06:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset USB 3.1 XHCI Controller (rev 01)
• 0f:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller

I imagine the Intel laptop has other controllers but I can't get those right now.

The USB Bluetooth dongles tested:

• Old cheap chinese dongle -> ID 1131:1004 Integrated System Solution Corp. Bluetooth Device
• TP-Link UB4A -> ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
• TP-Link UB500 -> ID 2357:0604 TP-Link TP-Link UB500 Adapter

The laptop integrated Bluetooth radios:

• Lenovo Miix 520 -> ID 8087:0a2b Intel Corp. Bluetooth wireless interface
• Lenovo P14s -> ID 0bda:4852 Realtek Semiconductor Corp. Bluetooth Radio

All Bluetooth certified except the cheap chinese one.

The OS is Manjaro KDE, but I also tested this on Arch.
I always get the exact same problem with the same behavior, regardless of system or Bluetooth dongle: a simultaneous disconnection of all HID-Nintendo managed controllers when using rumble after a few seconds or minutes. Non-HID-Nintendo controllers remain working perfectly.
That's quite a lot of different hardware this fails on, and this does not happen on Windows when using rumble through Steam.

sorry i currently do not have any switch controllers to test with

@nicman23 I would like to help. I can test with multiple controllers and easily trigger the disconnection after a few seconds.
How can I provide you with information to try and fix this? Any kind of logging or debugging?

[SuperSamus]

I don't know if it's just me, but it seems that games with a strong rumble intensity tend to disconnect more frequently.
For example, Rocket League rumbles the controller basically all the time, but it's low intensity. I played it quite a lot of hours, and I only ever got one disconnection.
Another game, Wondersong, almost never uses rumble, but when it does, it's of high intensity, and I got quite a lot of disconnections on that game (and only in the parts where there is that rumble). There is one section of the game where rumble is instead done all the time, with the same high intensity, and the controller couldn't stay connected one minute in that section.

Does my experience match yours?

EDIT: Maybe it's related: DanielOgorchock/joycond#104.