Controller loses connection randomly

[ipkpjersi]

Describe the bug
When I use the Xbox One controller, it randomly loses connection. My Bluetooth headphones are fine and stay connected, it's just my Xbox One controller stops accepting inputs from me and then the Xbox button light starts blinking instead of staying solid and it keeps blinking until it reconnects again.

To Reproduce
Use Ubuntu 18.04 LTS with the Xfce DE with latest xpadneo on any game

Expected behavior
I expect using the Xbox One controller to stay connected like my Bluetooth headphones

If you require any additional details please let me know. I'm not sure if this is an issue with xpadneo, a Bluetooth hardware issue (I actually tried 3 different Bluetooth USB adapters), an issue with the Xbox One controller, or something else entirely.

[kakra]

Please list the model names of the dongles used. lsusb is helpful as a first step.

[ipkpjersi]

This has happened with every dongle I've used, and only happens with my Xbox One controller as my Bluetooth headphones never ever disconnect (at the moment I am using Sennheiser HD 4.50BTNC) but here is my entire output of all USB devices I am currently using, just in case any of them are conflicting:

https://pastie.io/dpdmvp.properties

I believe the device in question is Bus 003 Device 010: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

Here is the link to the device: https://www.amazon.com/dp/B00FCK307I/ref=pe_3034960_236394800_TE_dp_1

[kakra]

The question is if all your dongles use the same chipset...

[ipkpjersi]

I'm not sure how easy it is to find out the chipset of the other dongles but here's the other ones:
https://www.amazon.com/gp/product/B00VWEK4IG/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

https://www.amazon.com/gp/product/B0169O12UC/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

[kakra]

Simply plug all in at once and run lsusb. ;-)

[kakra]

These are the chipsets:

• ORICO BTA Series = CSR 8510
• Avantree DG-40S = CSR 8510
• StarTech Mini USB Bluetooth 2.1 Adapter = CSR BC0401PC08

So it's all "Cambridge Silicon Radio" which are - at least according to the reports here - are known to have connection losses with the controller.

[ipkpjersi]

Thank you for that information, that's really good to know.

Do you know of any known-working adapters? That would help me a ton and would essentially remove one of the two biggest issues I have with xpadneo.

Also, are they issues with the controller hardware, or is it an xpadneo-specific issue? In other words, would I also have this issue on Windows (not that I'm switching, just curious)?

[ugly95]

My experience has been totally different. I never lose connection with CSR Bluetooth adapters. I've tested a few that were both Broadcom and CSR dongles.

There were a lot reported here: https://atar-axis.github.io/xpadneo/#bt-dongles

With Broadcom chip USB dongles, I've found that the initial connection is good, but the range is poor, there can be a lot of lag, and I got frequent disconnects, usually with the controller stuck rumbling. I also found that I had poor range and audio lag with Bluetooth headphones.

With CSR chip USB dongles, I've found that getting the controller to connect is difficult. I usually have to run echo -e 'connect 5C:BA:37:D4:46:6A' | bluetoothctl at least once to get it to connect. But after a connection is established, it works flawlessly. I don't remember ever having a disconnect with a CSR chip USB dongle. I also have problems establishing a connection with my Bluetooth headphones.

[kakra]

My experience has been totally different. I never lose connection with CSR Bluetooth adapters. I've tested a few that were both Broadcom and CSR dongles.

There were a lot reported here: https://atar-axis.github.io/xpadneo/#bt-dongles

With Broadcom chip USB dongles, I've found that the initial connection is good, but the range is poor, there can be a lot of lag, and I got frequent disconnects, usually with the controller stuck rumbling. I also found that I had poor range and audio lag with Bluetooth headphones.

With CSR chip USB dongles, I've found that getting the controller to connect is difficult. I usually have to run echo -e 'connect 5C:BA:37:D4:46:6A' | bluetoothctl at least once to get it to connect. But after a connection is established, it works flawlessly. I don't remember ever having a disconnect with a CSR chip USB dongle. I also have problems establishing a connection with my Bluetooth headphones.

I can confirm that this seems not to be an issue of the chipset itself. I've now ordered a new BT dongle, this time made by TP-LINK instead of some no-name product. The specs said it should have a Qualcomm chipset but in the kernel it still identifies as CSR chip with the same USB ID as my previous no-name dongle. But the behavior of this dongle is a bit different: During init from the kernel it says [28690.646596] Bluetooth: hci0: unexpected event for opcode 0x0000 but nevertheless it works just fine. And what should I say? Not just fine but perfectly it seems: With the rumble test program I could reliably kill the connection previously, now it runs just fine for minutes and even multiple times repeated on the same connection (without power-cycling the controller). Maybe my previous dongle was some China fake chipset.

If anyone wants to try, here's the link: https://www.amazon.de/gp/product/B07NQ5YGDW/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1

OTOH, I now have similar initial connection problems as @ugly95.

[ipkpjersi]

I just realized, I have rumble (force feedback) disabled, so this issue may still actually be valid, I'm not sure.

I will test xpadneo tonight and see if #171 and #57 are both "okay" or if I am still experiencing those issues.

[kakra]

Feel free to re-open any of those if issues still persist and post the output of dmesg (just the recent lines not the whole log). But to me it clearly looks like a hardware issue with the dongle: I've tested two dongles (same chipset according to lsusb but one is probably a China fake or buggy version): One dongle has absolutely no intermittent connection issues but only an issue auto-connecting after turning the controller on. The other connects just fine but looses the connection especially on rumble commands.

My commit 8392d59 may mitigate the problem but chances are very low that it helps. My best tip is: Buy another dongle. My example shows that it doesn't need to be a different chipset, just a different maker/distributor.

[ipkpjersi]

The disconnect did happen again, and this time my headphones disconnected too (that doesn't normally happen, maybe 1 out of every 10 disconnects). I think it might be a hardware issue, but it's not like the Bluetooth adapter I'm using right now is cheap or anything, it's class 1 supposed to be good up to 50m:
https://www.amazon.com/dp/B00FCK307I/ref=pe_3034960_236394800_TE_dp_1

Here is my dmesg although I think only the last 10 lines are relevant:
https://gist.github.com/ipkpjersi/a3e21d8d1e5edc7711dd18661681f75e

[kakra]

Actually, I'm pretty sure by now that all that fuzz about "50m", "EDR" etc are just marketing bla bla. In the end, most have the CSR chipset inside and are nano adapters. So it's probably a chipset spec, and I'm not sure if that really works with a nano design. My first adapter I bought was announced to have 100m range outside and 10m inside of buildings. But that's just not true. It's maybe more like 3m if a wall blocks the signal. And even then, it's no longer a reliable connection, mostly just enough to not disassociate.

Your dmesg output indicates that you booted the device with an older version of xpadneo first, and later reconnected with a newer version.

The line [ 689.683053] xpadneo 0005:045E:02FD.0009: pretending XB1S Windows wireless mode (changed PID from 0x02FD to 0x02E0) is from the new driver version. It indicates your controller is connected in Linux mode (ID 0x02FD) and the driver pretends it to be 0x02E0 now (applications will see that ID when looking at the input layer). This is needed to get the guide button working again in all applications. You wrote you'd have another controller?

There's no sign of the output report for rumbling failing - otherwise you'd see a message failed to send FF report. But the kernel doesn't even notice the connection breaking down. You could run wireshark in parallel and open the BT monitor from there. It will show some layer 2 messages of the bluetooth protocol which the driver cannot see.

When the controller seemingly disconnects: Does rumble still play or does it stop immediately? Do input events still work at least for a few more seconds when rumble stops working correctly?

The difference between the old and the new driver version is that output and input reports for the controller are no longer interlocked: The driver can still receive input reports should they occur while the output reports for rumble could become stuck or delayed. Previously, input would queue up and no longer processed while the driver tried to send rumble reports. But there's probably still some synchronization at the BT layer.

Maybe try a different BT dongle. The one I linked works fine for me during use besides from the initial connection problem. It's the same chipset I already had just a different brand/label:

# lsusb
[...]
Bus 002 Device 013: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
                       ^^^^:^^^^

So there seems to be more to it than just this chipset.

Another chance would be trying a different chipset. I wanted to try a Qualcomm chip but wasn't able to easily find one. That's from the guys who usually also make chips for Android devices so I was seeing a good chance there.

I think we cannot do much here... If anything, it would need adjustments in the kernel source for the BT chipset drivers. It's complicated code, should be done by the guys who made the drivers and know their business. You may look here to see if you find any recent changes to the BT driver you are using, maybe they mention fixes or changes and you'd just update the kernel. You're probably using the btusb driver (that's a generic driver made for most chipsets in the wild):

https://github.com/torvalds/linux/commits/master/drivers/bluetooth

[ipkpjersi]

Thank you for such a detailed post.

I agree there's probably not much that can be done, I did order one of the Bluetooth dongle you linked so I'll try that out and see how that goes.

I don't have rumble (force feedback?) on at any point so I don't think it's related? Or maybe rumble is something different and I'm not understanding?

I figure Linux and Bluetooth and even just modern technology is so finnicky in general it's amazing any of this stuff works. lol

I'm not too upset about this, just wanted to see if there's anything that can be done about it, and there probably isn't which is okay. I'm not using a controller for anything that demands 100% performance no disconnects ever so it's fine if disconnects happen like once or twice a gaming session.

I'm more concerned about the regression with #57 but I know you already have a great fix in mind for that :)

[kakra]

Rumble is a subset of the force feedback support baked into the kernel: Rumble is just spinning weights with motors (as you'd find in your gamepad) while force feedback allows for much more: You could pull with a force against the user input (like for driving wheels or the good old force feedback joysticks that would apply a force against your joystick movements). Gamepads don't have anything like that, they just have their rumbling motors, usually a strong one and a weak one. And Xbox One S and later have two more: One per each trigger to rumble that trigger. None of these motors applies any force against your inputs, they just shake your hands and fingers. ;-)

And yes, looking at the btusb driver and seeing how many different chipsets (even from vastly different brands) it supports with a single codebase is amazing and scary at the same time. ;-) In the end, the chipsets seem to be very similar in how you program them, with a few minor differences and a lot of quirks. These quirks are probably the problem here.

If you don't use rumble at all, you should be able to run the controller just fine on a rock solid connection with the correct (unquirky) dongle. I could play for 10+ hours without disconnects and rumble on after swapping my dongle for a new one, about 3m away from the dongle (or 10 feet, not sure from where you are). My new dongle just requires me to manually click "connect" in the desktop Bluetooth connection applet even though I trusted the Xbox controller for auto-connects. It's a low price to pay for having a stable connection throughout the game session.

Actually, the rumble protocol is quite light-weight: It sends one small packet (64 bits) every 50ms at most, your inputs to the controller create a vast amount more traffic. So rumble is something that hardly requires 100% performance. I've documented that in https://github.com/atar-axis/xpadneo/blob/master/docs/reports/xb1s_battery_event.md and https://github.com/atar-axis/xpadneo/blob/master/docs/descriptors/xb1s_linux.md.

[ipkpjersi]

So I tested this more with the new adapter you recommended and sadly it does still happen, I had it happen twice more (0 times yesterday, twice today).

I think it might be related to me being on an older (LTS) kernel: Linux 4.15.0-101-generic x86_64

I could possibly install a newer Linux 5-based kernel but I'm not too fussed about it. It's not that big of an issue. Just out of curiosity, what kernel are you running with that adapter?

[kakra]

I'm running the 5.4 LTS series kernel with an additional patch for the Bluetooth connection:
https://github.com/kakra/linux/commits/rebase-5.4/xpadneo

The Bluetooth patch of interest is kakra/linux@c8b24d8, there's also some more patches to exclude xpadneo devices from hid-microsoft, so I don't have to unbind the device with udev rules.

[ipkpjersi]

Ah, that (probably) makes more sense why you are having a better Bluetooth experience than me lol

Thanks for letting me know, I might look into that kernel some time.

[kakra]

@ipkpjersi Would be interesting to see if that patch makes any difference for you. Which distribution are you using? It may be relatively easily possible to slipstream the patch into your kernel package. For Gentoo, it's as easy as putting the patch in /etc/portage/patches/sys-kernel/gentoo-sources and re-emerging the kernel. For other distributions, you usually need to add the deb-src repository and install the kernel source package (or for rpm installing the source package), then go to the source directory, put the patch there and add it to the build script, then rebuild the package and install it.

[kakra]

Maybe related to #189