bluetooth unreliable on latest archlinux

[nicman23]

this is with the dkms module with both linux and linux-lts packages. It was previously stable with it (i have only every used the dkms module).

the modules complains for a time out. tested all of my commits, 2 different controllers (one pro, one joy r), downgrading bluez, removing imu

only report i get is:

nintendo 0005:057E:2009.000D: timeout waiting for input report
nintendo 0005:057E:2009.000E: unknown main item tag 0x0
nintendo 0005:057E:2009.000E: hidraw9: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on 00:19:86:00:00:47

___

upowerd[2007]: treating change event as add on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-4/1-4.3/1-4.3:1.0/bluetooth/hci0/hci0:11/0005:057E:2009.000E/power_supply/nintendo_switch_controller_battery_0005:057E:2009.000E
upowerd[2007]: did not recognise type Unknown, please report
upowerd[2007]: did not recognise type Unknown, please report

edit: it seems to be the rumble, reverting support for it makes the bluetooth connection stable again

[DanielOgorchock]

Weird, I'm running arch on a 5.6 kernel, and I'm not having this issue. I wonder if it depends on the bluetooth controller in use.

edit: It makes sense that things are less likely to look broken with rumble disabled. That's the only thing frequently sending commands from the PC to the controller. Another test would be (with rumble disabled) seeing if you can reliably turn the player LEDs on/off through the sysfs led interface, since this also requires sending subcommands to the controller.

[nicman23]

while true; do for i in 0005\:057E\:2009.0015\:*/brightness; do echo 0 > "${i}"; echo 255 > "${i}"; done & sleep 0.1; done

ctrl-c

wait

that is what i used to spam the interface. no disconnects when not touching the controller. however with joycond running and testing the analogs it disconnects quite quickly.

running without the daemon, i can spam the interface indefinitely, but as soon as all the jobs finish (wait exits) the controller disconnects!

also the disconnects -with the module compiled for rumble support- happened without any games running / without any reason for the rumble to fire

[psycho-driver]

I too have been having this problem since patching gentoo kernel 5.5.2-gentoo-r1 with your driver. 1 controller will stay connected for a while sometimes but eventually disconnects. It ranges from 45 seconds to 45 minutes. 2 controllers cause 1 to disconnect pretty quickly, usually within a minute or two.

I was using a dongle with the CSR8510 A10 chipset initially. Today I received a Plugable BCM20702A0 based dongle as well as an 8BitDo SN30 Pro to test with. My 2 Switch Pro controllers behaved exactly the same with the BCM chipset. The 8BitDo hasn't exhibited any connectivity problems so far.

I don't know why I didn't think to try this before, but I removed the hid-nintendo.ko module and just connected the switch pro controllers through the generic input driver, and they've been synced up for about 40 minutes now without issue.

Edit: Removed rumble support and they stay connected with either bluetooth dongle.
Edit2: Leds are working fine, I don't think it has anything to do with the led code unless it's causing a conflict when rumble is enabled.

[DanielOgorchock]

When rumble is enabled the driver sends rumble subcommands to the controller several times per second even if the rumble amplitude is zero (i.e. when no program is playing a force feedback effect). I suspect that this extra bluetooth traffic is resulting in the connection being much flakier.

It also makes sense that using the generic HID input driver will be less likely to disconnect. The controller works in a much simpler reporting mode with no analog joysticks or various other features. hid-nintendo places the controller in the full 60Hz reporting mode.

I'll do some further testing with my setup using bluetooth. Admittedly most of my testing has been using USB.

[bernharl]

Any update on this? I'm still getting constant disconnects. How do i turn of rumble on Arch Linux with the dkms driver?

[DanielOgorchock]

Please give this patch a try: 1c27248

It prevents constantly sending rumble subcommands when there is no ongoing rumble effect. This should drastically reduce the bluetooth traffic.

[bernharl]

Thanks for the quick reply.

Do I just replace hid_nintendo.c when building the dkms driver then? I'm pretty new to this, sorry!

[nicman23]

i updated the dkms driver, the patch seems good !

[nicman23]

it does still dcs if i spam fftest a bit, but when nothing is happening it is fine.

also if i change the effect type in fftest too fast, it eats the input

[bernharl]

It works perfectly for me now after installing the updated AUR package!

[joaorb64]

I also had disconnections before. Yesterday I played for some time with it and didn't have any kind of connection issues!

[nicman23]

is this patch from 085bb27 upstream?

[DanielOgorchock]

is this patch from 085bb27 upstream?

No you can completely disregard that patch. I rebased at some point, and that commit message happened to reference an unrelated issue with the same ID. I haven't made further changes to the Bluetooth reliability.

[sirdeiu]

Hi @DanielOgorchock

I'm seeing issues with the Nintendo Pro controller also, for the following:

openSUSE Tumbleweed with kernel: 5.10.9-1-default
KDE Plasma 5
hid-nintendo 3
joycond

While trying to play Streets of Rage 4, I keep having random disconnects from the Pro Controller, while it is connected via Bluetooth. I have tried it with two Bluetooth adapters (Intel Wifi AX200 and ASUS BT-400 (with firmware).

In game, Streets of Rage 4 has an option to disable rumble (Vibration intensity), setting that to 0% results in the controller working normally and being able to use it while playing.

With rumble enabled, while playing SOR4, the controller disconnected quite fast and randomly.

Reported initially here: https://github.com/nicman23/dkms-hid-nintendo/issues/28

[psycho-driver]

Yeah I have disabled rumble at compile time for now as it is still unstable for me and all 4 of my switch pro controllers.