[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.

[envyniv]

1. Ubuntu 20.04
2. I'm not sure, but i think any 5.3 up to 5.4.0-31-generic?
3. current, ubuntu-patched?; 5.4.0-33-generic
4. xpadneo-lsusb.txt
5. xpadneo-btmon.txt
   hope i managed to help in some way. :)
   if i manage to find something else, i'll edit this/post another comment

[envyniv]

i know i shouldn't chat here, but am i the only one that seems to correlate this issue with the kernel update?

[kakra]

I think this will get some attention with the next version bump.

[wangyu6]

So ,will next version support xbox-one-s? ( it just couldn't connected pc(ubuntu-1804) through bluetooth)

[kakra]

So ,will next version support xbox-one-s? ( it just couldn't connected pc(ubuntu-1804) through bluetooth)

I don't want to be rude but this issue is solely about collecting information with regressions. Please look at the other issues, the one's linked above are a good starting point. Otherwise feel free to open a new issue report. I'll mark off-topic comments as off-topic now. Thanks in advance for understanding and your cooperation.

[kakra]

HEADS UP

Anyone affected may try #204 and report in #189 or #180. After the latest discoveries, this may prominently affect people with high-HZ kernel configurations (a 1000 Hz kernel seems to show the problem much more likely than a 100 Hz kernel, I'm using 300 Hz and didn't have many issues but many game-optimized kernels often opt-in for 1000 Hz, tho I think that's overkill, 300 Hz may look odd but fits best here as it cleanly divides by most common FPS rates (25 Hz, 30 Hz, 50 Hz, 60 Hz, 100 Hz) and should thus reduce jitter. If you're not an Ultra-High-FPS gamer (120+ FPS), I recommend using 300 Hz.

For checking your settings, follow the instructions at the top of this page.

[envyniv]

[mark this as off-topic]
after a month, I decided to retry connecting my controller to my computer. it now works. I have no idea what has changed. i didn't update the driver, I, pretty much, did not do anything. my guess is that the latest kernel patched the issue? I don't know anything about anything. So sorry i couldn't help.

[kakra]

There's also an issue with establishing an encrypted connection between the controller and the Linux Bluetooth stack. The first problem is (from my tests) often a missing link key. This can be fixed by retrying to remove the controller in bluetoothctl and then pairing it again, immediately followed by trust, repeat 1-3 times until the link key shows up in /var/lib/bluetooth/HOST-MAC/PEER-MAC/info. During pairing you may need to press buttons on the controller (or click the connect button again) to confirm, but that may also be just placebo - at least clicking the connect button sends data to the Bluetooth stack for some reason. Once the link key is there, it now longer constantly disconnects and reconnects due to a missing or non-matching link key. But still, the controller may take up to 60s for establishing the encryption. I don't know whats wrong but often the handshaking fails until it eventually works after 3-5 times. I wonder if the firmware tries multiple encryption methods until it finds one that works with Linux. It may well be related to the kernel or the bluez version after the initial link key issue was resolved.

Will mark as off-topic later.