[NOT FOR QUESTIONS] Bluetooth connection stability broken

[kakra]

NOTE: Do not report here if you cannot reproduce a working state with a previous kernel version.

This is a information collection issue to pinpoint the kernel change that broke the Bluetooth stability with the controller. I'll ask anyone who wants to help to provide the following information:

Stay updated

Subscribe to this thread to stay updated about Bluetooth issues with Xbox controllers. Use the button on the right to subscribe, no need to leave a comment.

Observations

1. If you're seeing the problem mostly while rumble effects are playing, I strongly suggest to update the controller firmware first. You can do this by connecting the controller to a Windows box, running the Xbox app, and applying the update from within the app. Then go back to Linux. After re-connecting the controller to Linux, it may start in the wrong mapping mode. My latest code re-design should fix it but if it doesn't, maybe open a new bug report with all the details, then remove the controller from your Bluetooth settings and re-pair it (or if you want to help out, don't remove and re-pair it just yet and wait for my reply). If you don't have a Windows box, you can download an evaluation version of Windows 10, install it in a VM and use USB pass-thru to make the controller visible in the VM.
2. There's also a known problem that causes instabilities, input lag, or pairing/connection issues due to Bluetooth discovery continuously running in the background. To observe this yourself, run btmgmt to find that discovery is continuously active or switches off and back on almost immediately to run for around 10s each cycle. Then log out of your desktop environment to observe that this is no longer an issue, and now your controller may connect just fine and the connection is stable. The kdeconnectd daemon may be (directly or indirectly) involved here. Running pkill kdeconnectd may resolve the issue for you until the clients spawns it again (e.g., kdeconnectd/Plasma browser integration).
3. Bluetooth LE is relatively new and uses a different approach to support HID devices. The current implementation of bluez may not set latency properties properly, but as a work-around, you can set them manually. See below.
4. Bluetooth LE pairing may be problematic, depending on privacy settings and kernel version. Thus it's recommended to use the latest versions. If the controller pairs correctly, you should see a very reliable connection, in contrast to older Xbox controller models.

Prerequisites

1. You've not experienced the issue before updating the kernel
2. You can reproduce the issue with your currently running kernel
3. You are using the same USB dongle before and after the update and tried all the dongles you own
4. You are not using different distributions for each kernel
5. If possible, you've updated the controller to its latest firmware (see above).

Information collection

Please provide kernel versions as shown by uname -a if possible because distributions often implement their own patchlevel versioning.

1. Which distribution are you running?
2. Last known working kernel version
3. First known broken kernel version
4. Kernel timing setting: zgrep '^CONFIG_HZ' /proc/config.gz
5. Run lsusb and take note of the device number of your USB Bluetooth dongle
6. Run lsusb -v -s## | tee xpadneo-lsusb.txt where ## is the device number picked in the previous step, post the resulting file.
7. Disconnect your controller, run sudo btmon | tee xpadneo-btmon.txt and connect the controller, post the resulting file.

Thanks!

Kernel bug reports

1. https://bugzilla.kernel.org/show_bug.cgi?id=199843 - Xbox One S and other bluetooth devices fail to connect
2. https://bugzilla.kernel.org/show_bug.cgi?id=198919 - Xbox (One) Wireless Controller won't connect
3. https://bugzilla.kernel.org/show_bug.cgi?id=209745 - BLE devices fail to connect in privacy mode
4. https://lore.kernel.org/linux-bluetooth/CAC2ZOYuG_BBG0uisXkoTtroxwgvv+JO-yMFC2+bRQZjsvwK1qw@mail.gmail.com/T/#u - Bug report to linux-bluetooth with ERTM enabled and L2CAP patch applied

Bluez bug reports (maybe also kernel bug reports)

1. Xbox Elite 2 controller stops sending data during inquiries from nearby devices bluez/bluez#123 - Continuous discovery disrupts Xbox controller stability
2. [5.59] Xbox Series X/S Controller won't connect, enters connect/disconnect loop in pairing mode bluez/bluez#155 - Pairing issues with Bluetooth LE Xbox controllers
3. Xbox Series X|S controller HIDP input latency problem bluez/bluez#156 - High input latency / event loss with Bluetooth LE Xbox controllers

KDE Plasma bug reports

1. https://bugs.kde.org/show_bug.cgi?id=435444 - Continuous discovery running despite no Bluetooth wizard running
2. https://bugs.kde.org/show_bug.cgi?id=401983 - Unstable wireless connectivity while discovery is running (also affects wifi)

Changelog

This documents some of the changes found with some kernel updates.

Kernels 5.4.72, 5.8.16, 5.9.1, 5.10...

Contains some Bluetooth pairing fixes. Doesn't seem to affect XB1S. Some XBE2 users report the 20s connection delay gone but I cannot confirm that. Bluetooth commits:

Luiz Augusto von Dentz (5):
      Bluetooth: A2MP: Fix not initializing all members
      Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel
      Bluetooth: MGMT: Fix not checking if BT_HS is enabled
      Bluetooth: Consolidate encryption handling in hci_encrypt_cfm
      Bluetooth: Disconnect if E0 is used for Level 4

Some users reported a broken Bluetooth connection with these latest patches except for 5.9.1 or higher.

Kernels 5.9, 5.10

The kernel Bluetooth stack solved a bug for BLE devices in privacy mode: https://bugzilla.kernel.org/show_bug.cgi?id=209745, seen since 5.9, solved since 5.10.4, not sure if it has been backported yet but it usually gets fixed, too, in all kernel versions chronologically newer than 5.10.4 so 5.9.17 should be fine, too.

Update: The Privacy=device setting is actually not needed and should not be used - leave it at its default setting.

Continuous discovery caused by desktop environments

At least KDE Plasma seems to exhibit a behavior that causes it to continuously trying to discover nearby devices which in turn makes Bluetooth connections from Xbox controllers unstable and hardly possible to connect. The problem was discovered while investigating this report: bluez/bluez#123

The bug is not in KDE Bluedevil itself but rather another component which probably triggers it by listing the contents of the bluetooth:/ kio virtual directory: https://bugs.kde.org/show_bug.cgi?id=435444

If your controllers connect without problems and the connection is stable after logging out of your desktop environment, you're probably affected by this behavior. Different Xbox controller models act slightly different when affected by this behavior: Sometimes it pairs and connects just fine but input events get lost or laggy, sometimes the connecting or pairing may just take 30-60s but the input event transport itself is unaffected.

We currently know of only one way to work around this if KDE or kdeconnect is used: Kill kdeconnectd (pkill kdeconnectd) or install kdeconnectd without Bluetooth support.

HCI event ordering

There may be an issue with the ordering of HCI events exchanged between the Bluetooth stack and the gamepad:

1. Xbox One S gamepad fails to connect (auth failed after reading encryption key size) bluez/bluez#127 - diff of btmon log between a failed and a successful connect

Bluetooth LE issues

Latest Xbox controllers use Bluetooth LE. While the pairing and connecting is much more reliable IF it works, the Bluetooth stack of Linux still seems to see a lot of changes and fixes for it. If you're experiencing issues, ensure updating to the latest controller firmware, and also kernel and bluez version. Some manual tuning may still be needed to fix latency issues, see bluez/bluez#156 (comment).

Upstreaming efforts

Reported by @hadess in #44 (comment):

The pre-requisite Bluetooth patch has landed in bluetooth-next, and work on upstream can proceed.

[kakra]

Identified two possible problems for connection stability and initial connection: kdeconnectd is somehow involved as we see continuous Bluetooth discoveries going on, overwhelming the RF environment, resulting in the controller losing connection. Also, the initial connect may depend on proper ordering of some HCI events but this needs further investigation. I've updated the initial post on this issue.

[kakra]

Updated initial post regarding Bluetooth LE issues.

[1985a]

In my case, this is the solution
Xbox controller model 1914
In the main.conf Bluetooth file add the following

[General]
ControllerMode = Dual
JustWorkingRepairing = confirm

[LE]
MinConnectionInterval = 7
MaxConnectionInterval = 9
ConnectionLatency = 0

[kakra]

Some general updates on the topic since I was finally able to test the issue on a Windows system which had multiple Bluetooth dongles connected (that system is extensively used for VR, and the user connected all the Bluetooth dongles that came with the various accessories):

• Devices become really confused when multiple CSR 4.0 dongles are connected
• The PC has an internal Intel AX200 Bluetooth transceiver
• We had to remove all but one CSR 4.0 dongle, Windows doesn't seem to handle multiple dongles very well, the GUI doesn't expose a way to select which dongle to pair to
• We had to disable the internal AX200 Bluetooth device, none of the various Bluetooth devices could pair reliably to it
• With only one Bluetooth transceiver left and enabled, devices connected just fine and immediately

The tests included an XB1S controller which we updated to the latest firmware first. Connection with the internal AX200 Bluetooth was almost always impossible, the connection was unreliable, and most of the time it connected in some limbo state where Windows would say "connected" but the controller keeps flashing. This reminds me a lot of the behavior we can see in Linux. The other Bluetooth devices had similar issues: While they usually were able to connect, pairing and connected took a long time, some devices needed several tries before they worked. This results in the conclusion that the AX200 chipset is just borked and incompatible. Don't use it.

With only one CSR 4.0 dongle connected, all devices were able to pair and connect almost instantly. Even the XB1S controller connected instantly. This works a lot better than I'm used to it in Linux: In Linux, it CAN connect instantly, but often it takes several seconds. This results in the conclusion that there are still issues with the bluez daemon.

The kernel drivers for the chipsets may have an impact on that but I think most of the drivers are using btusb anyways, the driver should be in good shape, and only some new chipset revisions or cheap China clones may need btusb driver updates or quirk fixes. This leads to the conclusion that you want to use CSR chipsets most likely because those are supported very well and work with the gamepad. There's only the problem with a lot of CSR China clones on the market which you should try to avoid (but may not be possible because who knows).

[1985a]

I don't know if someone can see help with this but I felt the need to share it.
I'd like to say at the moment the kernel 5.18.15 and these devices, are working together so nice.

Before, I made several attempts in order to get this controller to work on BT mode, but it never any success.

This is my Bluetooth main conf file, that I'm using, and as I say, it's working like some kind of magic after updated the firmware.

PD: excuse me my bad English, it is not my mother language.

[General]
ControllerMode = dual
JustWorksRepairing = confirm
[BR]
[LE]
MinConnectionInterval=7
MaxConnectionInterval=9
ConnectionLatency=0
MinConnectionInterval=9
MaxConnectionInterval=12
[GATT]
[AVDTP]
[Policy]
[AdvMon]

[dnet890]

same issue, it does not work on Ubuntu 22.04