Adding info: issue is not present on Windows 10 on the same machine/hardware/steam version/game etc.

Hi @kisak-valve, well, mainly because I'm playing the game on Steam and using the Steam controller support for Nintendo Pro or Sony DS4 etc. It mostly seems like a game issue, but I said I'd try asking here first.

I've also now tried with the dkms-hid-nintendo driver and joycond, and I can see the issue using that also, but not as frequent.

I have raised this issue also with the dkms-hid-nintendo owner and they asked about rumble in game, so I tested disabling that in game (setting the Vibration Intensity to 0%) and while playing the Pro controller was OK, I could finish an entire game level.

I've tried the same using Steam (and also disabling rumble in Steam Controller configuration for the Pro controller) and it worked a bit better I guess, but the issue is still present while testing. It seems that for some reason, when using Steam, the Pro controller is more prone to this issue. But mostly for SOR4. Have tried other games also and they worked OK.

So it may be just the rumble function or something else also.

Any ideas, please?

Was this fixed ? I also have this issue. Tried different Bluetooth dongles.

I get the same issue with No Man's Sky. If it's not a Steam Input issue, it's a specific issue with how Proton interacts with Steam Input.

If i disable Steam controller support for a specific game in Steam big picture and instead run the game with built in controller support the disconnections stops.

Try running dolphin emulator, e.g Metroid Prime 2.

I don't think it's too game-specific. This also happens to me when playing The Elder Scrolls: Skyrim with Proton.
For what it's worth, this doesn't happen with other titles on Steam for macOS, if that helps the developers figure out how it happens.

I also encountered this problem. Disabling the Steam management of the Switch Controller fixed it, like others have said.

dkms-hid-nintendo had similar issues when rumble was enabled. It seems like the connection was spammed with rumble-state-updates, resulting in instability — but that's fixed now. The steam-for-linux implementation might have a similar problem? Looking at their commits could help.

I also encountered this problem. Disabling the Steam management of the Switch Controller fixed it, like others have said.

dkms-hid-nintendo had similar issues when rumble was enabled. It seems like the connection was spammed with rumble-state-updates, resulting in instability — but that's fixed now. The steam-for-linux implementation might have a similar problem? Looking at their commits could help.

This fixes it for me as well.

For me it was enough to just disable the rumble feature in Steam settings.

For me it was enough to just disable the rumble feature in Steam settings.

I'll try this tonight.

Edit: just disabling rumble fixes the random disconnects.

This has been an issue for me for months now compounded by the fact that Proton not respecting my controller options (turning off rumble, disabling the light on the controller)

Your system information
Steam Ver: Sep 17 2021 Package ver: 1631912732
Distro: Arch Kernel 5.14.8 KDE5

I also encountered this problem. Disabling the Steam management of the Switch Controller fixed it, like others have said.

dkms-hid-nintendo had similar issues when rumble was enabled. It seems like the connection was spammed with rumble-state-updates, resulting in instability — but that's fixed now. The steam-for-linux implementation might have a similar problem? Looking at their commits could help.

I've found that the hid-nintendo kernel driver still has some problems with rumble and disconnects even after that latest patch. I was able to play through a full track of Little Racers Street with rumble enabled (with only one controller connected) without problem, but trying to play Pocket Cars (with four controllers enabled), which seems to have a fair amount of controller issues anyway at their current point of early access and which seems to use rumble excessively, caused spurious disconnects of the controllers pretty often.

I'm starting to believe the underlying problem may be in the linux bluetooth stack.

I have no problems with disconnects with four controllers going as long as rumble is disabled.

The random disconnects also happen for me, but they happen basically anywhere, whether I'm in a game or not, and disabling rumble does indeed get rid of the disconnects entirely. I don't think the third party game label is actually relevant for this issue.

There is a battery connection problem on some controllers, that will disconnect the battery if the controller is vibrating, you can check if this is the case by smashing the controller on your hand and see if it’s disconnects.
If this is the case then open the controller and put some paper to make pressure on the connection.

There is a battery connection problem on some controllers

Just to be clear: This issue is real and does not occur with the same Switch Pro Controller when one is using a different bluetooth stack (f.e. on the Nintendo Switch, Windows, Android or using a bluetooth adapter for controllers like the 8BitDo USB Wireless Adapter).

Hi I’m sorry but that is incorrect, when using 8bit-do adapter I also have disconnections but it was solved but disable controller support in steam because somehow steam is interfering with the controller connection.

There is a battery connection problem on some controllers, that will disconnect the battery if the controller is vibrating, you can check if this is the case by smashing the controller on your hand and see if it’s disconnects. If this is the case then open the controller and put some paper to make pressure on the connection.

I intensively use the controller on my Switch as well (from a 9 foot distance and without any disconnects) so this sounds like a software issue to me.

Still an issue. My journal errors also show Frame is too long (len 54, expected len 51), but I don't know what that means. It happens while playing Elden Ring, but I have to use desktop config for that game, so the game might be irrelevant.

same issue here on a brand new pro controller, on Arch (Kernel: 5.16.14-zen1-1-zen -- built in nintendo-hid).
While running yuzu, rumble on: controller keeps on disconnecting. rumble off: all fine

on journalctl, I find the following when it disconnects:
tlp[8764]: Warning: systemd-rfkill.service is not masked, radio device switching may not work as configured.
tlp[8764]: >>> Invoke 'systemctl mask systemd-rfkill.service' to correct this.
tlp[8764]: Warning: systemd-rfkill.socket is not masked, radio device switching may not work as configured.
tlp[8764]: >>> Invoke 'systemctl mask systemd-rfkill.socket' to correct this.
kernel: nintendo 0005:057E:2009.0012: unknown main item tag 0x0
kernel: nintendo 0005:057E:2009.0012: hidraw7: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on 00:1a:7d:da:71:15
kernel: nintendo 0005:057E:2009.0012: using factory cal for left stick
kernel: nintendo 0005:057E:2009.0012: using factory cal for right stick
kernel: nintendo 0005:057E:2009.0012: using factory cal for IMU
kernel: nintendo 0005:057E:2009.0012: controller MAC = BC:CE:25:38:F2:06
kernel: input: Nintendo Switch Pro Controller as /devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-4/5-4.1/5-4.1:1.0/bluetooth/hci0/hci0:75/0005:057E:2009.0012/input/input47
kernel: input: Nintendo Switch Pro Controller IMU as /devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-4/5-4.1/5-4.1:1.0/bluetooth/hci0/hci0:75/0005:057E:2009.0012/input/input48
tlp[8820]: Warning: systemd-rfkill.service is not masked, radio device switching may not work as configured.
tlp[8820]: >>> Invoke 'systemctl mask systemd-rfkill.service' to correct this.
tlp[8820]: Warning: systemd-rfkill.socket is not masked, radio device switching may not work as configured.
tlp[8820]: >>> Invoke 'systemctl mask systemd-rfkill.socket' to correct this.
upowerd[1379]: treated changed event as add on /sys/devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-4/5-4.1/5-4.1:1.0/bluetooth/hci0/hci0:75/0005:057E:2009.0012/power_supply/nintendo_switch_controller_battery_0005:057E:2009.0012
kernel: nintendo 0005:057E:2009.0012: compensating for 5 dropped IMU reports
kernel: nintendo 0005:057E:2009.0012: delta=92 avg_delta=14
kernel: nintendo 0005:057E:2009.0012: compensating for 7 dropped IMU reports
kernel: nintendo 0005:057E:2009.0012: delta=98 avg_delta=11
kernel: nintendo 0005:057E:2009.0012: compensating for 4 dropped IMU reports
kernel: nintendo 0005:057E:2009.0012: delta=65 avg_delta=11
kernel: nintendo 0005:057E:2009.0012: compensating for 4 dropped IMU reports
kernel: nintendo 0005:057E:2009.0012: delta=67 avg_delta=11
kernel: nintendo 0005:057E:2009.0012: compensating for 4 dropped IMU reports
kernel: nintendo 0005:057E:2009.0012: delta=60 avg_delta=11
tlp[9063]: Warning: systemd-rfkill.service is not masked, radio device switching may not work as configured.
tlp[9063]: >>> Invoke 'systemctl mask systemd-rfkill.service' to correct this.
tlp[9063]: Warning: systemd-rfkill.socket is not masked, radio device switching may not work as configured.
tlp[9063]: >>> Invoke 'systemctl mask systemd-rfkill.socket' to correct this.
kernel: nintendo 0005:057E:2009.0013: unknown main item tag 0x0
kernel: nintendo 0005:057E:2009.0013: hidraw7: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on 00:1a:7d:da:71:15
kernel: nintendo 0005:057E:2009.0013: using factory cal for left stick
kernel: nintendo 0005:057E:2009.0013: using factory cal for right stick
kernel: nintendo 0005:057E:2009.0013: using factory cal for IMU
kernel: nintendo 0005:057E:2009.0013: controller MAC = BC:CE:25:38:F2:06
kernel: input: Nintendo Switch Pro Controller as /devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-4/5-4.1/5-4.1:1.0/bluetooth/hci0/hci0:73/0005:057E:2009.0013/input/input49
kernel: input: Nintendo Switch Pro Controller IMU as /devices/pci0000:00/0000:00:08.1/0000:0c:00.3/usb5/5-4/5-4.1/5-4.1:1.0/bluetooth/hci0/hci0:73/0005:057E:2009.0013/input/input50
tlp[9269]: Warning: systemd-rfkill.service is not masked, radio device switching may not work as configured.

I've had similar issues with both xbox one bluetooth controllers and switch pro controllers (on Linux). Xbox controllers do weird things and the Switch pro disconnects every other minute. The common solution in both cases.....

Disable vibration/rumble in Steam. MGSV with a Xbox One controller it would act like the left trigger was being held down. Playing COD MWR, constant disconnects. Both fixed by disabling rumble.

Edit: nah that was wrong, while disabling rumble did solve some problems with an Xbox One controller, the Switch Pro controller still sucks, I spoke too soon.

I experienced this issue a while back which is why I got rid of my ProCons. I can confirm this issue is real and it sucks. If I ever get another Switch Controller, I'll be sure to test with rumble off. I never realized it was the rumble.

I experienced this issue a while back which is why I got rid of my ProCons. I can confirm this issue is real and it sucks. If I ever get another Switch Controller, I'll be sure to test with rumble off. I never realized it was the rumble.

I should have updated the comment sooner, disabling rumble didn't really fix it, maybe it made it a bit less screwed up. After a while of playing it came back and was still too annoying to use the Pro controller

The issue seems to impact on games having both native in-game support for controller and mixing it with steam controller support. What works for me in these scenarios is to disable controller support in Steam and use the native in-game controller support.

I think this is possibly more of a Linux driver issue than anything else. My bet is there's some issue in the Bluetooth stack that breaks the connection. Haven't had such issues with Xbox One controllers or any other Bluetooth peripherals.

Linking this for relevance: https://github.com/DanielOgorchock/linux/issues/33.

Having this same issue as of February 2023 with latest beta update.

Have you tried updating the controller through a switch ?

With Firmware version 15.0.1 on the Nintendo Switch console, connecting the Pro controller to the console, updated the firmware. Then connected the Pro controller on Linux, the rumble disconnect issue seems to be gone and the Pro controller is much more reliable (no disconnects).

Relevant bits:
Distro: Debian bookworm
Kernel: 6.1.8-x64v1-xanmod1
Bluez: 5.66-1
Adapter: Intel AX200, BT 5.2

Tried with Broforce (GOG), lots of continuous rumbling, and with Steam games.

Updating the controller through a Switch on 15.0.1 does not seem to fix the issue. Still having this issue on games heavily relying on rumble.

Check if controller battery is not tight enough on the connectors inside, causing battery disconnect on rumble. If no battery issue the Try the 8bitdo wireless usb adapter.

Check if controller battery is not tight enough on the connectors inside

@ravinsweden This happens exclusively on Linux and does not happen through Steam. It also happens on various of my Pro controllers, so it's not a controller issue.

I am seeing the PRO controller disconnect randomly when using it together with my Headphones connected to the same Bluetooth adapter. If I connect the Pro controller to the Intel AX200 adapter and then my Headphone to another adapter (ASUSBT400) it works as described in my previous comment, where there is no disconnect.

This happens with the hid_nintendo, hid_nx and just with Steam's hid driver. What I really like is the battery life the controller has, compared to XBOX or DS4/Dualsense.

I have a fully updated controller, brand new. It has 0 disconnects with rumble on macOS even in long play sessions. On Linux, it often lags really badly when rumbling, majorly delaying input. Then, it will completely disconnect. This issue is not exclusive to Steam. It happened in Cemu (Wii U emulator), and Yuzu (Switch emulator) as well as Dolphin (GameCube/Wii emulator). It seems there is something wrong with the Linux driver.

Now that there's been a little more insight about the issue, I have some questions:

• If this is not the best place to report it, where should we report it instead?
• How can we debug this?

This bug can also be caused by this issue

In that case, it is caused by having multiple bluetooth devices at the same time.

@Samuelfaure Doesn't this also happen with a single device connected? Although I believe having more than 1 controller connected makes the disconnect happen faster.

This does happen with only one controller. Unfortunately, I think this may be a problem with the bluetooth driver for Switch controllers in Linux, because I've had this happen in other games/emulators, and on multiple Switch ProCon firmware versions. Steam just seems to run into this problem more often and consistently than the other emulators, perhaps because it sends more rumble signals? At any rate, this issue really needs to be resolved. I hope Valve can help patch it.

Oh, and this might further validate my feelings toward this being a driver issue: It doesn't happen very often, but even when wired, I sometimes have the controller disconnect and screw up games for no reason, probably because of the rumble.

@TriVoxel This is the relevant issue on the Switch Pro kernel driver for Linux: https://github.com/DanielOgorchock/linux/issues/33
It would be nice for further discussion to take place there, as this does not seem to be a Valve-specific issue.

There is already a long discussion about this issue there. There are also suspicions that this might be a deeper problem on BlueZ itself.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/7631#issuecomment-1680864636

Updated my switch controllers to latest firmware and no longer have disconnecting issues. Try this.

Med vänlig hälsning,

Robin Bard

Updated my switch controllers to latest firmware and no longer have disconnecting issues. Try this.

@ravinsweden That might be because, some months back, the Linux driver got updated and this issue got "fixed". The controllers don't disconnect but the vibration quality had to be severely reduced. I don't consider it a proper fix.

How's the vibration quality and latency overall for you?

@ravinsweden I tested with up-to-date firmware months back, and today. I tried to update the controller firmware on my Switch, and it was already up to date. You may have recieved an update in Linux that bandaid fixed it, but it still seems to be broken.

November of 2023, SteamOS 3.5.7. Switch Pro and XBOX Series X Controller , still same issue.

This still seems to be an issue. Just tried it today with Tomb Raider (2013), rumble enabled, and it still disconnects every minute or so.

I finally gave up on mine.  Just sold the last two of my four switch pro controllers earlier tonight.  Ironically generic switch pro controllers almost all seem to work fine.  I have an 8bitdo ultimate bluetooth and 3 ultimate C for switch controllers now.  Much better experience.

I was able to find a temporary solution which will require joycond to be installed in userspace. Tested with Steam and Ryujinx for 2 days now with no issues on a Pro Controller. I ordered a pair of new joy cons for testing next week and will update but so far very good. Played Smash Bros Ultimate for more than 24+ hours with no issues.

Somehow, changing the Bluetooth adapter name to "Nintendo" fixes the issue. You can see the discussion starting from https://github.com/DanielOgorchock/linux/issues/33#issuecomment-2790843365.

Here’s a completely independent project which had their connectivity issues resolved by naming the Bluetooth adapter to “Nintendo” https://github.com/darthcloud/BlueRetro/issues/146#issuecomment-2811454347

BlueRetro is an open source hardware mod which allows connecting Bluetooth HID devices to retro consoles, translating the Bluetooth protocols to native console protocols. It supports several legacy consoles and controllers at this point.

Here’s my conspiracy theory:

It would seem to me that the problem is any controller using Nintendo’s firmware probably checks for a connection to a licensed or official “Nintendo” device and sabotages the connection if it is not “official”. They probably allowed FOSS driver developers to communicate with their device just enough to create a working driver, but have the communications break down within their controller firmware to gaslight us into blaming the driver.

I would not put it past Nintendo to do this, as they were probably unhappy about people using genuine Nintendo hardware for emulation, essentially for free thanks to open source. They probably felt like they had to “protect” their hardware from unsanctioned use by unlicensed 3rd parties because they clearly put a lot of R&D into the combination of motion controls, HD rumble, ergonomics, and battery life. They couldn’t just let anyone interface with their hardware if there was money to be made!! Essentially, I’m betting this is a form of DRM.

I’m sure Microsoft and Apple license a driver made or endorsed by Nintendo, and it probably either renames the Bluetooth device somehow, or has some kind of metadata it sends to verify the license. I wonder if it would be possible to check for that, perhaps from Windows or Mac? If it is as simple as sending a license to the controller, perhaps we could forge a license instead of renaming the adapter to Nintendo?

For anyone interested, this post and following discussion contains the details why it fixes the problem: https://github.com/DanielOgorchock/linux/issues/33#issuecomment-2849798054
No Nintendo conspiracy to entertain us. It wouldn't make much sense anyway, as it only happens with rumble enabled.

I myself never had disconnect issues when using the Pro Controller through Steam, but I had lots of disconnects when using the Linux driver, so I was wondering how did Valve work around the problem.
I thought it was because they use less frequent rumble packets. But the reports in this issue here tells me maybe it wasn't enough to fully work around the problem after all.