Pro Controller disconnects when connected via Bluetooth #33
Comments
|
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:
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:
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? |
|
I forgot to mention: 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? |
|
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: 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. |
|
@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:
On my desktop I have these USB controllers:
I imagine the Intel laptop has other controllers but I can't get those right now. The USB Bluetooth dongles tested:
The laptop integrated Bluetooth radios:
All Bluetooth certified except the cheap chinese one. The OS is Manjaro KDE, but I also tested this on Arch.
@nicman23 I would like to help. I can test with multiple controllers and easily trigger the disconnection after a few seconds. |
|
|
|
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. |
|
@Labaman Yeah, it's certainly not a hardware problem. I've tested with 5 different bluetooth radios with 2 different Pro Controllers. |
|
So is there any hope of improving the situation? |
|
Since we can easily reproduce the bug, we could provide debug help to @nicman23, but he's been absent for a while. 😞 |
|
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. |
|
@Labaman And is the perceived rumble intensity on Yuzu the same between Windows and Linux? |
|
@nfp0 yep. |
|
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: I think it might go deeper than steam input or hid_nintendo |
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. |
@a-priestley Where are you getting this error message? I've checked the logs from |
journalctl prints it out. |
|
The Switch Pro controller.
On Thursday, July 27, 2023 at 01:30:17 PM CDT, nfp0 ***@***.***> wrote:
Steam pro controller support now works with wireless and bluetooth + rumble without d/cs.
@psycho-driver Are you talking about the Steam controller or the Switch Pro controller?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@psycho-driver It definitely had problems before, yes. If you do a search online, there's lots of people complaining about the Pro Controller disconnecting on the Steam Deck. You think it's fixed now? I remember someone mentioning here that Steam uses SDL, so shouldn't the fix be visible here in the SDL repository? |
|
Just going to add my experiences here. I've observed my (nearly brand new) controller working perfectly on macOS and a real Switch without problems, so I know it is good hardware. On Linux, indeed it will disconnect within a few minutes usually, sometimes multiple times in a row. I am not sure of using multiple controllers, or especially Switch controllers, makes a difference, I only have the one Switch controller and often several Wii U controllers connected. I don't think I've noticed a difference when having Wii U controllers connected via BT, so perhaps it is the driver running two Switch protocols at once which is problematic? I wouldn't entirely discount the Switch controller hw as problematic, though. I haven't had any problems with bluetooth controllers on Linux for years. I've had success with PlayStation 3-5 controllers, Wiimotes, Wii U Pro Controllers, Xbox Series, etc. Of all my BT controllers, the Switch is the only one which is problematic. And it isn't just Linux which suffers with supporting this device. Here is an issue from BlueRetro, an open source controller firmware which allows hardware to be built that facilitates using modern Bluetooth controllers on retro game consoles. I ran into this issue using a Power-A GameCube style controller for Switch, Bluetooth using the Switch protocol. Their software also has major issues with supporting this hardware, and it doesn't have rumble either. I suspect they have problems with rumble and so opted to disable it. I'm not entirely sure what software BlueRetro uses, but it's a much smaller program than the Linix kernel, and if they share some components with Linux, that would probably be a good place to start looking for this problem. Perhaps there is also something about the Switch's bt protocol that is obfuscated somehow? I would not put it past Nintendo to intentionally design an anti open software controller in this day and age... |
|
@TriVoxel Interesting. I'll subscribe to that issue to see what they changed if it gets fixed. |
|
I have a Pro Controller (with original firmware as I don't have a switch to update it) and it also suffers of the same disconnection issues that are described here when using rumble. Later I bought a [GuliKit KingKong 2 Controller])https://www.gulikit.com/productinfo/828615.html) and although it exposed itself using the switch protocol and uses also this driver in Linux, no disconnection occurs. So I guess something "special" has to be in the controller itself... |
|
I've been digging into these bluetooth issues more, and I may have stumbled across a way to improve reliability without allowing rumble quality to suffer. I'd appreciate if anyone else is able to give this a try to see if it improves things for them. First, to properly test, it's required to modify the hid-nintendo driver slightly. These changes will revert the driver to a state where it attempts to match USB rumble performance for bluetooth controllers:
Now I have been testing 2 bluetooth-related tweaks. The first one I'm not so sure if it actually matters, but it shouldn't hurt. I thought I saw more disconnects without it, but that may have been pure chance. Edit the bluez main configuration file: /etc/bluetooth/main.conf You'll see two lines related to min/max sniff intervals. Uncomment them, and set them to the below values: Frankly, I'm not sure if these make any real difference when factoring in the next step using hcitool... Be sure to restart bluez (systemctl restart bluetooth) and then reconnect your usb dongle. Now, after you connect your controller, and the hid-nintendo driver probes, check dmesg output to see your controller's MAC address. Now for the step which I can tell definitely improves reliability. Make sure that you have hcitool installed. We're going to use it to disable BT sniff mode with the controller. I'm not sure how drastically this will impact battery life, since from what I understand this will basically keep bluetooth constantly in active mode. Observe the current link policy used with the connected controller: You should see this: Now, disable SNIFF functionality like so: Now, running Note that the link policy needs to be set again each time the controller is reconnected. I do still get disconnects when using both joycons. I think a single usb bt adapter just isn't good enough typically to handle multiple connected controllers while using rumble. I think a good compromise may be to expose those in-kernel driver rate limit definitions as module params. That way they can default to something conservative, but someone using a single controller per BT adapter can tweak them to be more performant. Please let me know if anyone else is able to reproduce my results. If it's consistent, we can figure out a way to try applying the link policy tweak automatically (maybe udev rules, as part of joycond, or maybe even a bluez plugin). I suppose we also would need to figure out the battery life impact. EDIT: EDIT 2: |
|
@DanielOgorchock since i don't know how to modify the driver, i tried the change in bluez maind config file. And i still got disconects. Some observations that might be usefull to you: 1- I'm using the original joycons Let me know if there's any other thing i can do. |
|
@DanielOgorchock Good to see you back on this issue! 🙂 @benjamimgois If the disconnections occur much more frequently on the right joycon, could this be related to the joycon's NFC or IR features? The Pro Controller also has NFC functionality. |
|
@DanielOgorchock I'm sorry, but even after following your instructions, I got disconnects after 1 or 2 minutes. For convenience (and because I don't know any other way to test it), I'm using this repo as a base, with the The code changes you suggested indeed make the rumble quality excelent, but changing the link policy and BlueZ config didn't seem to help. I still have the feeling the problem is in the Bluetooth stack because of what I mentioned (about there not being a connection time-out) a few post back here. Shouldn't we open an issue with the BlueZ folk? Or perhaps is an issue open already? |
I haven't thought about that... it's a good point. Any idea how nfc is handle on the kernel ? I'm not sure the problem is with the bluetooth stack, since i use a xbox-series controller over bluetooth and the connection is perfect. I tracked the guy that reverse enginered the joycon protocol, maybe he might be able to help in this issue. There's also a software that emulated the switch controller over bluetooth. I don't have the expertise to analyse this, but maybe someone here can. |
|
The 8BitDo Pro controller, and the GuliKit pro controller have no connection issues in Switch Bluetooth mode. Neither have NFC. I think the Power A GameCube wireless controller might not have the disconnection issues either, at least not in relation to rumble. Anyone needing an NFC reader would be better off getting a dedicated device. |
|
Gulikit KingKong 2 (NS08) doesn't have NFC and I can assure it perfectly works in switch mode via bluetooth using vibration. You can even play mario kart in Yuzu without a disconnection. It would be interesting knowing if the GuliKit KingKong 2 Pro (NS09) has disconnections as it seems to support NFC (it lists amibo support -> https://www.gulikit.com/productinfo/737791.html) |
I don't think NFC is ever enabled by this driver.
Sure, all other controllers work fine, but I find it strange that the Bluetooth stack detects the disconnection instantaneously with no timeout, contrary to what happens when you press the sync button to turn the controller off, where the controller simply silences itself completely with no disconnect message, causing a timeout after 10 or so seconds.
I've sent him an email a few months ago to try and get him to help on this issue, but got no answer. 🙁 @DanielOgorchock I've enabled debug mode on BlueZ and captured the output of the disconnection. |
|
I've always had Joycon disconnects when playing on Yuzu, Ring Fit Adventure (a game that heavily uses rumble). Since disconnecting the joycon mid-emulation meant that the ring connection would be broken until game restart, this made it unplayable, so I switched to Windows, where I never got disconnects, until I had some other driver issues there. Then I switched to playing on Steam Deck, where the game kinda ran ok. Surprisingly, I never had joycon disconnects there? Though, very rarely, I would lose connection with the ring, so it could be likely that the joycon disconnected and reconnected while I wasn't looking, since on the SD it will reconnect 75% of the time without needing to repair the controllers, something that I never managed to do on my desktop. But recently, the SD got a massive update, that introduced a new issue (that was fixed months ago on my desktop) where the entire system will crash when connecting a second joycon. So I went back to my desktop to see if things improved, and sadly I got a right joycon disconnect about 10 minutes after game start. It is as @benjamimgois said, the right joycon will almost always disconnect first, and its battery will be drained much faster than the left one (this also happened on the SD). |
|
I'm currently using NXBT to simulate a Pro Controller from the computer side and I'm snooping on the Switch <-> Pro Controller conversation to see if I understand what the driver does different than the console to cause the disconnections.
I also had this problem, where I always needed to put the controllers in pair mode to be able to reconnect even though they were paired already. |
|
I'm back with some curious observations. As I said, I've setup NXBT and observed what the Switch does different than hid_nintendo. I've analyzed the traffic on Wireshark. I've tried a few things with no luck, but found some more interesting stuff I haven't tried anything against because I'm not sure how to do it, as I'm not well versed in C. First, here's the sequence of subcommands sent by the Switch console: And here's hid_nintendo's sequence: Of note is the fact that the Switch console:
I think it would be worthwhile trying to replicate this sequence. I'm attaching here the full Switch console Wireshark capture: There should be a few non-silent rumble commands in there, as I've tried causing rumble in-game, but I don't see them anywhere in the capture. I'm not sure why. Maybe the game did not generate the rumble I was expecting. I have to try it again. Now, I wish I had a way to sniff the traffic between a real Pro Con and the Switch console, instead of having to use NXBT. NXBT has a few issues and I'm not sure if the Switch is sending rumble commands to the simulated controller, other than the silent ones. Other interesting things I found out but haven't tried anything about them:
@DanielOgorchock Can you please take a look at the above ones? I'm not sure how to deal with those. Things I've tried:
|
Thanks, this is really helpful. If I have some time soon I'll experiment with NXBT as well. I didn't realize it existed. What I'm really interested in is how the switch console reacts when its rumble packets are lost or discarded in transmit. I'm also curious if the switch configures the BT controller somehow to never send more than 1 packet per period (e.g. never more than one packet per 15ms). I think a potential source of the disconnect problem could be that the BT controller itself is buffering pending rumble TX packets from hid-nintendo, and if the link has some issues, it may be sending multiple at once (hence the occasional tiny deltas). |
@DanielOgorchock I did another capture with NXBT but unfortunately I don't think the Switch console is sending any rumble commands other than the silent ones every 4 seconds. There's also another alternative we can use to simulate a Pro Controller: Joycontrol
That's interesting. Could there be any setting on BlueZ that disables buffering? |
|
@DanielOgorchock I've managed to get Joycontrol to connect once and successfully captured the Switch console rumble conversation! 😃 The Wireshark capture: Sorry, couldn't capture the initial controller setup this time. The game sending the rumble is Super Mario Bros Wonder. My observations:
Even if we don't find a way to control the Bluetooth buffering, I think it would be worthwhile to mimic these conditions, namely the periodic silent rumbles, and see if the controller behaves any better. |
|
Hi everyone! My experience: Reproduce:
I was informed that Switch Controller support already is in the latest linux kernel. However before that I did try to install dkms-hid-nintendo manually a couple of times. This was redundant and I uninstalled them ever since. |
|
@Trippixyz I'm sorry but that seems to be a completely different issue than this one. |
|
@nfp0 Whoops now I see. In that case I'll consider opening up a new issue for that! |
|
Hi @Trippixyz did you get a solution on that issue. I have the same issue and while searching for a solution, I stumbled upon this thread. |
|
Did this issue (the Switch Pro Controller rumble disconnects) ever get fixed? I thought I saw a patch commit to the 6.4 version of the kernel so I was hoping it was fixed (and would eventually hit SteamOS which is what I'm gaming on), but then I saw reports of people saying it was NOT fixed, even on kernel 6.8 |
|
@thebeardedchild It was "fixed" in the sense that it does not disconnect anymore (at least for me), but to achieve that, the rumble quality had to be degraded considerably. On some games I can feel heavy latency on the rumble effect. |
|
@thebeardedchild It's weird, because I had the disconnection issue until I connected the pro controller to my switch, then disconnected again and then paired with my linux machine. It has been working well since. |
|
I haven't connected my pro controller to the switch for while, but possibly there is a firmware update for the pro controller that fixes things. Worth a try :) |
|
Hey guys, i haven't used my joycons in a while. But i just decided to make some tests yesterday and i realised that the disconnect problem doesn't happen to a pair of chinese joycon copycat. It's a very low quality joycon when compared to nintendo original one, but it's recognized by the kernel as a standard joycon device. Everything works, rumble and gyro with no disconnects what so ever |
|
I have an issue that resembles this one, although might be separate. When connecting my pro controller over Bluetooth (by holding down the pairing button, pressing Search in Blueman, and double-clicking Pro Controller), it connects fine, after a little bit of light flashing. Input works both with and without Steam running. However, after what seems to be exactly 30 seconds of being connected (I timed it a few times), all the lights turn off and it disconnects. This occurs without rumble being used at all. dmesg log: btmgmt tells me my Bluetooth adapter is on v5.3, but the store page for my laptop claims it's v4.2, which is odd. However! This only occurs when my Bluetooth headset is also connected. Disconnecting it fixes the issue entirely, and the messages about dropped IMU reports and joycon_enforce_subcmd_rate also (mostly) disappear from the log. Rumble does not seem to trigger the issue. This could be related to a paragraph on this page: https://en-americas-support.nintendo.com/app/answers/detail/a_id/27784/~/unable-to-pair-or-sync-nintendo-switch-pro-controller
It's possible that my Bluetooth adapter is just not capable of handling multiple devices in this way, but the precise 30-second disconnect time feels strange for that kind of thing, especially since the controller works fine before the disconnect. Pairing the gamepad first, then waiting a while, then pairing the headset also seems to work. I don't know how relevant this information is, and perhaps this should be its own issue report, but maybe it'll be useful. |
|
@GTcreyon Yes, that is likely a different issue unrelated to this DKMS. I would check on BlueZ's issues. |
and others
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:
Logs when the controller disconnects:
The text was updated successfully, but these errors were encountered: