DanielOgorchock
Pro Controller disconnects when connected via Bluetooth
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
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?
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.
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.
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?
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 https://github.com/nicman23/dkms-hid-nintendo/issues/33 for awareness?
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.
@twoxa Arch user here too. Interesting finds. I'll see if I arrive at the same pattern as you.
@nfp0 sorry i currently do not have any switch controllers to test with. btw what is your system specs and usb controller
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?
~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: https://github.com/DanielOgorchock/joycond/issues/104.~
I submitted a bug on Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216218.
@SuperSamus Interesting!
RetroArch allows to choose the intensity of the vibration. I'll test it at max and minimum vibration intensity and report back if there is a pattern or not.
I have the same problem. @SuperSamus You're right, I checked with Yuzu - there you can control the intensity of vibration, as well as turn it off. In games where vibration is used often (e.g. Super Mario Oddesey) - the controller is turned off within a few minutes after the start of the game. In games where vibration is used infrequently (such as Legend Of Zelda BOTW), the controller can run for up to several hours without turning it off. If you completely disable vibration in the control settings, the controller does not turn off during the game at all. And similarly, with a wired connection, the controller does not turn off regardless of whether vibration is on or not. It's not a hardware problem - the problem is reproduced on 2 different controllers. And not a problem with bluetooth - I also have an Xbox One controller that does not turn off with vibration on.
@Labaman Yeah, it's certainly not a hardware problem. I've tested with 5 different bluetooth radios with 2 different Pro Controllers. Same problem happens in any of them.
Since we can easily reproduce the bug, we could provide debug help to @nicman23, but he's been absent for a while. :disappointed:
Does there appear to be any correlation with the strength of the rumble? Does higher rumble intensity seem to cause disconnects more frequently than light rumble events?
If so, I can try decreasing the driver's maximum amplitude. I wonder if there's a power supply brownout occurring when connected via bluetooth that doesn't occur over USB (since the controllers can draw power from USB instead of battery in the latter case)
@DanielOgorchock I'm afraid not. Well, or the effect is insignificant. I tested on Yuzu + Super Mario Oddesey with vibration intensity 100%, 50%, 40% and 30% - the controller still disconnects. I did not notice any noticeable difference in the frequency of controller disconnects. The most interesting thing is that on Windows with the same controller on the same Bluetooth adapter - a similar problem is not observed.
@Labaman And is the perceived rumble intensity on Yuzu the same between Windows and Linux?
@nfp0 yep. @DanielOgorchock It is highly unlikely that it is related to the USB power supply, with a wired connection: Did the following test: connected an external charger to the Pro Contronller - same result - controller disconnects when vibration is on.
I think it may also have to do with gyro. After turning rumble and haptic feedback off, it still happens. But it seems to correlate with gyro use. I really think it is the bluetooth stack though, and not hid_nintendo, because I can blacklist the module, passing the responsibility to steam, and it still occurs. Every time it does, I get:
Bluetooth: Frame is too long (len 54, expected len 51)
I think it might go deeper than steam input or hid_nintendo
I really think it is the bluetooth stack though, and not hid_nintendo, because I can blacklist the module, passing the responsibility to steam, and it still occurs.
Interesting... If that's the case then it should not be hid_nintendo. I'm gonna try and test the same way you did.
I really think it is the bluetooth stack though, and not hid_nintendo, because I can blacklist the module, passing the responsibility to steam, and it still occurs.
Interesting... If that's the case then it should not be hid_nintendo. I'm gonna try and test the same way you did.
I don't think I blacklisted the module properly. It was still being loaded with the kernel, but after (I think) solving that, rumble off + haptics off in Steam, I'm not having the issue any longer. Gyro seems to be fine. This is a really inconsistent issue though in my experience so I can't be sure about any of this.
Bluetooth: Frame is too long (len 54, expected len 51)
@a-priestley Where are you getting this error message? I've checked the logs from bluetooth.service but I don't see it anywhere when the controller disconnects.
Bluetooth: Frame is too long (len 54, expected len 51)@a-priestley Where are you getting this error message? I've checked the logs from
bluetooth.servicebut I don't see it anywhere when the controller disconnects.
journalctl prints it out.
journalctl prints it out.
@a-priestley Really? I've been using journalctl -u bluetooth.service -b after the disconnect happens and I don't see that message anywhere. Am I targeting the correct service?
@nfp0 well I'm not querying userland. The exact command I'm issuing is sudo journalctl -p 3 -xb
You could target Bluetooth if you wanted but that set of arguments should be specific enough for it to show up unobscured
@a-priestley Even with that command, I don't get the error. You did not get that error while using it through Steam, did you? I've raised -p to 4 and I get these warnings instead:
kernel: nintendo 0005:057E:2009.0027: timeout waiting for input report
tlp[38355]: Warning: systemd-rfkill.service is not masked, radio device switching may not work as configured.
tlp[38355]: >>> Invoke 'systemctl mask systemd-rfkill.service' to correct this.
tlp[38355]: Warning: systemd-rfkill.socket is not masked, radio device switching may not work as configured.
tlp[38355]: >>> Invoke 'systemctl mask systemd-rfkill.socket' to correct this.
kernel: ata1.00: supports DRM functions and may not be fully accessible
kernel: ata1.00: supports DRM functions and may not be fully accessible
org_kde_powerdevil[11683]: QObject::disconnect: Unexpected nullptr parameter
org_kde_powerdevil[11683]: QObject::disconnect: Unexpected nullptr parameter
These are just warnings though. I wonder why I'm not getting the same error as you.
Furthermore: I re-tested this and it seems to happen even more frequently now (I can always reproduce it in under 60 seconds of use), but now the controllers don't disconnect at the same time, as they did previously. They seem to disconnect at random times, as long as rumble is enabled.
The controllers never disconnect if I completely disable rumble, which leads me to believe this is exclusively triggered by rumble and not related to gyro. But I noticed that if I have rumble enabled, but at 0% strength on RetroArch, they still disconnect, even though they don't physically vibrate. Perhaps because the rumble signals are still being sent?
Maybe we could take and test some values from other drivers like BetterJoy or DS4Windows (Joy, Pro)? For example (from a quick skim), the rumble queue from BetterJoy is size 15 (as opposed to hid-nintendo's 8).
@nfp0 I'm not sure where the discrepency is. I am using a usb bluetooth adapter that's connected to a hub, so that might be it. I'll see if I can test out a direct I/O connection when I get home.