Xbox One Series X|S Controller bluetooth Connection Loop or Disconnects when controller exits pair mode (timeout)

[carterDWatts]

Using bluetoothctl the Xbox one X controller either enters a connect/disconnect loop or connects and even shows in jstest but disconnects when the controller leaves pairing move from a timeout. When the second of those two happens it vibrates when it says it is cconnected but the light does not stop fast blinking until it times out and disconnects. In jstest the controller shows on /dev/input/js0 but does not actually send any button presses. The controller works on android and is the most recent version, updated on Win 10.

I have already set disable_ertm to Y and have ControllerMode set to dual and tried with Privacy set to device in /etc/bluetooth/main.conf.

The output of btmgmt info showing that I have le and br/edr set:

 Index list with 1 item

  hci0: Primary controller

	addr F8:E4:E3:23:8D:6C version 11 manufacturer 2 class 0x3c010c

	supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy configuration static-addr phy-configuration wide-band-speech 

	current settings: powered bondable ssp br/edr le secure-conn 
	name carter-g14

	short name 

 hci0: Configuration options

	supported options: public-address 

	missing options: 

When I run sudo dmesg | grep Bluetooth | grep Firmware I get
Bluetooth: hci0: Firmware revision 0.0 build 118 week 15 2021 which I have confirmed with another person to be working for connecting the controller on the same model laptop (asus g14).

Dmesg immedeatly after connecting:

  [ 2907.604776] xpadneo 0005:045E:0B13.0034: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x02E0)
  [ 2907.604785] xpadneo 0005:045E:0B13.0034: working around wrong SDL2 mappings (changed version from 0x00000505 to 0x00000903)
  [ 2907.604789] xpadneo 0005:045E:0B13.0034: report descriptor size: 283 bytes
  [ 2907.604792] xpadneo 0005:045E:0B13.0034: fixing up Rx axis
  [ 2907.604794] xpadneo 0005:045E:0B13.0034: fixing up Ry axis
  [ 2907.604796] xpadneo 0005:045E:0B13.0034: fixing up Z axis  
  [ 2907.604797] xpadneo 0005:045E:0B13.0034: fixing up Rz axis  
  [ 2907.604799] xpadneo 0005:045E:0B13.0034: fixing up button mapping
  [ 2907.605043] xpadneo 0005:045E:0B13.0034: enabling compliance with Linux Gamepad Specification
  [ 2907.605596] xpadneo 0005:045E:0B13.0034: input,hidraw8: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on f8:e4:e3:23:8d:6c
  [ 2907.605607] xpadneo 0005:045E:0B13.0034: controller quirks: 0x00000050
  [ 2908.597030] xpadneo 0005:045E:0B13.0034: Xbox Wireless Controller [44:16:22:cb:bc:28] connected

Bluetoothctl once connected and once controllertimes out:

[Xbox Wireless Controller]# connect $XBOXC_MAC
Attempting to connect to 44:16:22:CB:BC:28
Connection successful
[CHG] Device 44:16:22:CB:BC:28 ServicesResolved: no
[CHG] Device 44:16:22:CB:BC:28 Connected: no

[kakra]

Which kernel version?

[carterDWatts]

uname -r

5.12.8-arch1-1

[kakra]

Okay, 5.12 no longer needs the ERTM work-around. Can you check that ERTM is actually enabled as it should be (aka disable_ertm=N? Messing with the other settings should not be needed.

Also, I'm seeing something similar currently with kernel 5.10 LTS. To connect the gamepad, I have to force it back into pairing mode (by holding the connect button), then issue a manual connect from user space. If you are using KDE, you may need to uninstall kdeconnect as it interferes with the Bluetooth RF environment due to a bug when interacting with KIO.

If it works when going the manual connect mode, you are probably seeing bluez/bluez#127.

If it works after uninstalling kdeconnect, you are probably seeing bluez/bluez#123.

If you want to test the gamepad after connection, evtest is the first test that should be run because it is the lowest layer upon which all other interfaces build their APIs (except SDL2 in raw mode but that's a different and long story).

[carterDWatts]

With disable_ertm=N I have the same issues. On reboot it gets set back to Y though, could that be an issue? I do not use KDE and evtest shows some output but nothing will pop up after the line that says Testing ... (interrupt to exit). When connected over usb evtest works correctly.

To connect I have forced it back into pairing mode and connected using pair <MAC> and connect <MAC> and I end up losing connection (that cant transmit data) once the controller exits pairing mode. What do you mean by issue a manual connect from user space?

[kakra]

If the controller paired already, do not use pair command again, just connect when you force the controller into pairing mode. Running info $XBOXC_MAC should allow you to verify pairing status, it should show Paired: yes.

ERTM is probably set back on reboot because there's a config file somewhere in /etc which does it, probably /etc/modprobe.d.

[Termuellinator]

I have the same issue - doesn't connect without pairing mode and is in a connect/disconnect loop when in pairing mode.
disable_ERTM was on Y, setting it to N didn't make a difference, Privacy was off (changed it to device now, didn't reboot yet though), LE is supported and mode is set to dual.
I haven't uninstalled kdeconnect yet, but killing kdeconnectd (as should be enough according to bliez#123?) didn't make any difference.

I'm on manjaro testing running 5.12.8

edit: just tried another (realtek RTL8761B) bluetooth-adapter instead of the Intel Corp. Wireless-AC 3168 Bluetooth my mainboard offers - same result :/
edit2: and same behaviour with Kernel 5.10.41

[carterDWatts]

I only run pair again after running remove on it. When I run info it says it is paired and connected but the controller still flashes as it is still in pairing mode. When thee controller times out of pairing mode bluetoothctl shows it has disconnected. At no point during it being paired (before the controller times out and disconnects) does evtest show it working. After it disconnects itself I am not able to connect. I can only "connect" when the controller is in pairing mode.

[kakra]

@carterDWatts

I can only "connect" when the controller is in pairing mode.

Yes, this is what I currently have to do, too: Force the already paired controller into pairing mode, then send a connect command from the PC. But then it connects just fine and the connection is stable. I'll look into the Bluetooth kernel patches during the next kernel release cycle to see if there are any patches that may affect this behavior. Unfortunately, it doesn't look like Bluetooth patches are back-ported to older or LTS kernels very often, usually only some critical bug fixes or supporting some new Bluetooth adapters on specific request.

@Termuellinator

but killing kdeconnectd

The problem with just killing it is that it may just respawn too easily. If you don't want to uninstall it, you could try making the daemon chmod -x before killing it.

[Termuellinator]

The problem with just killing it is that it may just respawn too easily. If you don't want to uninstall it, you could try making the daemon chmod -x before killing it.

i checked, it didn't respawn but i had to start it manually again after the test :)

To be clear: for me, the controller only connects in pairing mode (but automatically so), but enters a connect-disconnect-loop. If i exit pairing mode again, it is disconnected again. Unpairing it and manually pairing/connecting in pairing mode yields the exact same result. At no point (besides using a usb-cable) is the controller usable :/

[kakra]

Please run sudo btmon | tee btmon.log, then try connecting the controller, attach the log file.

[Termuellinator]

btmon.log

thats a log when i activate the pairing mode on the already paired controller and it enters the connect/disconnect loop.

btmon_from_start.log

Just in case that this is more useful, this is one where i removed the controller in bluetoothctl, then pair, trust, connect while controller is in pairing mode.

let me know if any other log variant might be useful, too :)

[kakra]

Okay, this is a BLE controller variant, probably the new one with the Share button. To properly investigate this, I need such a gamepad myself and thanks to ko-fi, I already ordered it. Should be delivered within the next 6 weeks, the order information has been just updated today.

But it differs from the model of the original reporter, so I cannot figure out yet if it is the same problem. What I can say already: Unfortunately, we cannot fix this in xpadneo, but I'll try my best to come up with a work-around and trying kernel Bluetooth patches.

[Termuellinator]

Yes, it's a new Series X/S type with a share button (i thought thats what "one X" in the title is refering to?). Had an "old" xbox one wireless before (sadly RMA'd without replacement but refund instead) that worked well. Connected with a usb-cable, it works well, too (not sure if xpadneo is used in that case?).
Lets hope yours gets delivered soon, then! :)

[kakra]

i thought thats what "one X" in the title is refering to?

Hmm, maybe. I'm not sure. I should add some checkboxes to the issue template to identify the exact model. The first Bluetooth version of the controller was the Xbox One S controller. The new should have "Series X|S" in the name. The original report doesn't match either of these.

Connected with a usb-cable, it works well, too (not sure if xpadneo is used in that case?).

No, most probably xpad is used then, and that creates an input device itself. xpadneo is a HID driver and depends on the kernel to create a HID device for us. I'm currently planning on the idea to make a USB device driver which exposes the controller USB connection as a HID device, then xpadneo would do the HID part. Since USB and the GIP dongle use an almost identical protocol, adding support for the GIP dongle later would be easy then and you'd no longer need to rely on the buggy Bluetooth implementation of the gamepad (if you own such a dongle).

OTOH, the gamepad works just fine on Android via Bluetooth (and it was probably designed only with Android Bluetooth in mind), and it works mostly fine with Windows Bluetooth (it shows some of the same bugs and Linux there but usually it connects just fine). So I think there's something important missing in the Linux Bluetooth stack. Android uses the same Bluetooth kernel drivers but a different Bluetooth user-space stack (not bluez but fluoride) so the needed fixes are most probably missing in bluez (except for some chip quirks that may exist in some Bluetooth kernel drivers).

[RuiGuilherme]

I have the same issue... Connected with a usb-cable, it works well.

Model Number: 1914
Model: Xbox X/S Carbon Black

$ uname -a

Linux ArchLinux 5.12.10-arch1-1 #1 SMP PREEMPT Thu, 10 Jun 2021 16:34:50 +0000 x86_64 GNU/Linux

$ journalctl -f

jun 14 00:27:05 ArchLinux bluetoothd[498]: profiles/deviceinfo/deviceinfo.c:read_pnpid_cb() Error reading PNP_ID value: Request attribute has encountered an unlikely error
jun 14 00:27:05 ArchLinux bluetoothd[498]: profiles/deviceinfo/dis.c:read_pnpid_cb() Error reading PNP_ID value: Request attribute has encountered an unlikely error
jun 14 00:27:05 ArchLinux bluetoothd[498]: profiles/input/hog-lib.c:info_read_cb() HID Information read failed: Request attribute has encountered an unlikely error
jun 14 00:27:05 ArchLinux bluetoothd[498]: profiles/input/hog-lib.c:report_map_read_cb() Report Map read failed: Request attribute has encountered an unlikely error
jun 14 00:27:05 ArchLinux bluetoothd[498]: profiles/input/hog-lib.c:report_reference_cb() Read Report Reference descriptor failed: Request attribute has encountered an unlikely error
jun 14 00:27:05 ArchLinux bluetoothd[498]: profiles/input/hog-lib.c:report_reference_cb() Read Report Reference descriptor failed: Request attribute has encountered an unlikely error

# bluetooth

# pair 44:16:22:C5:68:4A
    Attempting to pair with 44:16:22:C5:68:4A
    [CHG] Device 44:16:22:C5:68:4A Connected: yes
    Failed to pair: org.bluez.Error.AuthenticationFailed
    [CHG] Device 44:16:22:C5:68:4A Connected: no

# btmgmt

[] Accept pairing with 44:16:22:C5:68:4A (yes/no) >>  yes
    User Confirm Reply successful
    hci0 44:16:22:C5:68:4A type LE Public connected eir_len 14
    hci0 44:16:22:C5:68:4A User Confirm 339245 hint 1
    hci0 44:16:22:C5:68:4A auth failed with status 0x05 (Authentication Failed)
    hci0 44:16:22:C5:68:4A type LE Public disconnected with reason 2
    hci0 44:16:22:C5:68:4A type BR/EDR connect failed (status 0x04, Connect Failed)
    hci0 44:16:22:C5:68:4A type BR/EDR connect failed (status 0x04, Connect Failed)

$ btmgmt info

Index list with 1 item
hci0:   Primary controller
        addr 7C:B2:7D:E1:C1:01 version 10 manufacturer 2 class 0x3c010c
        supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy configuration static-addr phy-configuration wide-band-speech 
        current settings: powered connectable discoverable bondable ssp br/edr le secure-conn privacy 
        name ArchLinux
        short name 
hci0:   Configuration options
        supported options: public-address 
        missing options:

Bluez just does not connect, with or without xpadneo... Xbox controller works fine on Windows and Android.

[kakra]

@RuiGuilherme Unfortunately, xpadneo cannot control the Bluetooth connection, it won't see the device unless bluez has successfully paired/connected it. That's why it doesn't matter if you use or don't use xpadneo. The problem should be reported to the bluez project if you're using kernel 5.12 or above, because with previous kernel versions, the xpadneo installation disabled ERTM which deviates from the default bluez settings.

[kakra]

Today, the controller finally arrived. Thanks to all my supporters on ko-fi.

On the first try, the controller seemed to connect just fine and rumbled, but it didn't send any input.

On successive tries some hours later (I've just let it idle until it gave up on the connection and turned off), it now is in a reconnect loop when I put it into pairing mode.

Without pairing mode, it won't connect.

So I finally got the real hardware to play with and test things out.

Next try will be to update the firmware first.

[kakra]

The firmware update did not improve things but it reset the controller back into a state where it would connect once and rumble, but not send any input. Successive connects just result in a reconnect loop, so the same problem as #295 (comment) even after a firmware update.

My Android phone (Pixel 3 XL) has a similar problem: The controller won't pair at all. OTOH, on the packaging is a sticker that says iOS support is coming later - maybe this includes proper Bluetooth connectivity for Android, too. I didn't try Windows Bluetooth connectivity yet.

But at the current state, I'd say that this is a problem that should be reported to the bluez project if the controller just works using Bluetooth in Windows on the same system, i.e. same Bluetooth adapter. If it doesn't work on either OS, we may need to wait until MS releases a firmware with official iOS support.

In the meantime, I'll take a look at the Bluetooth protocol but I really don't know much about it. If anyone does, help would be appreciated on how to inspect and debug the problem.

[Termuellinator]

While i don't have windows on my system, i already created https://bugzilla.kernel.org/show_bug.cgi?id=213431 after your explanation in #295 (comment) - no response yet though.

[kakra]

I did that months ago and received no reply, once to kernel bugzilla (which seems considered mostly read-only by the kernel devs, I think, most reports should go to the mailing lists), and once to the bluez mailing list. I received some attention on the bluez github project but just once, and for a very different problem.

I'm not sure how to tackle that from here. Does the bluez project need some proper support? Maybe hardware to test with? Whom would we need to get in contact with? Every documentation about bluez (how to contact/support/report bugs) seems pretty sparse. I have the feeling that project only consists of very few (but dedicated) people, and what they really need is some more developers. Unfortunately, docs about Bluetooth specs are pretty hard to read and understand, so it would have a steep learning curve at best.

[Termuellinator]

I agree that the bluez website is not really clear about bugreports. I first tried their IRC channel but got no answer there (only 10 or so people there anyway), so i created the bugzilla report.
i think bluez runs pretty much "under the radar" for most people - on the one side due to the mentioned complexity of the topic and on the other hand due to not having a easy to find way of contributing, reporting and so on. I don't know how i missed the bluez github repo on my last searches, but now that i found it and see that it is indeed active, i guess creating an issue there would be a good first step?
Should i do that or do you wanna chime in (as you are way more knowledgeable than me anyway ^^)?

[kakra]

@Termuellinator There are already two reports by me. Feel free to add your report to an existing one if you see fit, otherwise just open a new one referencing this. Github will automatically crosslink the issue here then, so everyone participating will be aware of it.

https://github.com/bluez/bluez/issues/created_by/kakra

[Termuellinator]

If your issues are already tackling the issues here, then there'd be no real benefit for another one i guess - i wasn't sure if bluez/bluez#127 may have the same root as this issue?

[aaomidi]

What @bruno-fs posted works - I think we can update https://wiki.archlinux.org/title/Gamepad#Xbox_Wireless_Controller_/_Xbox_One_Wireless_Controller to match this new information?

[kakra]

I think we can update

I'm pretty sure Privacy = Device should only be seen as a temporary workaround. It works here without that settings, so it is probably just working around other bugs you're seeing in bluez.

Latest bluez (5.62+) seems to fix some things. But that's actually the version used by @bruno-fs. But actually, I've seen other reports where Realtek BT chipsets are still problematic. So maybe there are kernel driver issues left.

The thing is: We are still seeing people enabling ERTM unconditionally just because it's written in some wiki guides. But modern kernels (5.12+) do no longer need that work-around because underlying L2CAP features have been added - and in reality, disabling ERTM actually causes trouble with rumble on some models/chipsets and has never been a good work-around.

[bruno-fs]

@kakra

I've seen other reports where Realtek BT chipsets are still problematic.

Next month I should get a bluetooth card with intel AX 210 chipset. I'll report here how it goes (or is there a better place to send this?)

[bruno-fs]

Testing new device BT adapter. Same behavior as before.

Manjaro Linux: 5.16.14-1-MANJARO
Adapter: a pcie card with AX210
Controller: xbox carbon black (has the "share" button - not sure the number of the model)

$ lsusb | grep -i blue 
Bus 001 Device 004: ID 8087:0032 Intel Corp. AX210 Bluetooth

Vanilla bluetooth conf

With stock config on /etc/bluetooth/main.conf the controller ended up on loop connecting/disconnecting

steps to reproduce: "forget" all previously paired bluetooth devices (did this through kde-plasma ui) > change /etc/bluetooth/main.conf > systemctl restart bluetooth > btmon | tee > pair/trust/connect controller > turn off/on controller
log-file

Custom config

The following config was enough to stablish a stable connection.

Privacy = device

steps to reproduce: "forget" all previously paired bluetooth devices (did this through kde-plasma ui) > change /etc/bluetooth/main.conf > systemctl restart bluetooth > btmon | tee > pair/trust/connect controller > turn off/on controller
log-file

[kakra]

Yeah, Privacy = device seems to work but I'm not very sure about that solution. I believe it's only hiding an underlying problem. About the AX200 chipsets: These are even problematic in Windows for using the controller via Bluetooth, I tried that myself and could reproduce the same problems we see in Linux.

[Delikt]

For completion: I got a TP-LINK BT400 and disabled the Bluetooth from my PCI WLAN Card - i upgraded my Linux Mint 20.3 with 5.4 Kernel to 5.15 and sadly it didnt work for me.

I got other Problems with the 5.15 Kernel so i have to downgrade it back to the official supported 5.4 Kernel.

So atm i have a unusable Gamecontroller brick :(

[kakra]

BT400 is working just fine for me... I wonder if something else plays into this, maybe some kernel setting?

[Delikt]

It's a Time ago i try around this - but the only kernel modification i remember was the deactivation of the PCI Bluetooth (not sure about this was really on kernel side) - else i never modify the kernel

But anyway i got System Instability Issues with the 5.15 Kernel on my Mint 20.3 - so that isn't a Option so far Linux Mint officially Support this Kernel Version

The latest Kernel Version Linux Mint 20.3 officially Supports atm are 5.13.0-37

[kakra]

So 5.10 would be a newer LTS kernel than 5.4... My system is running fine with 5.15 LTS but I'm pretty sure back with 5.10 it was also working well. 5.4 is really old.

[Delikt]

So 5.10 would be a newer LTS kernel than 5.4... My system is running fine with 5.15 LTS but I'm pretty sure back with 5.10 it was also working well. 5.4 is really old.

If you mean the Controller will may work properly with 5.10 i give it another try with this Kernel

[DavidFencl]

Is there any working solution for this problem? My xbox series controller arrived today and I can't get it connected, same issue as OP described.

[kakra]

@DavidFencl Not really. First ensure you're running the latest controller firmware, you can do this by connecting the controller to a Windows machine and using the Xbox Accessories app from the Windows Store, or by connecting the controller to an Xbox. After I updated my firmware, one model just worked connecting but I had to try 3-5 times for a different model by removing it from bluez pairing DB and start over with the pairing process. I used the KDE Bluetooth GUI for this. It may matter a lot if other nearby devices use Bluetooth at the same time during pairing, I suggest turning Bluetooth off in all other devices within the perimeter while you pair the controller if it wasn't successful after a few attempts.

We collected a few issues (some with solutions) in the projects tab of the repository (see beginning of web page).

[DavidFencl]

@kakra Thanks for input! Second firmware update solved everything. Strangly it only worked after upgrading on actual Win, when I tried to upgrade my firmware in Win VM It said it's up to date but clearly wasn't.

[bmaupin]

In case it helps to have another data point, I tried connecting an Xbox Series X|S controller (the one with the share button) via Bluetooth and it kept disconnecting/reconnecting. I updated the controller firmware to the latest version via the Xbox Accessories App in Windows. I didn't make any other changes, and the controller seems to connect and work just fine now.

I'm not sure what the original version of the firmware was, because the Xbox Accessories app wouldn't tell me the firmware version until I updated. The new firmware version is 5.13.3143.0

I did run lsusb -v on the controller before updating the firmware, and this is the only value that changed after the firmware update:

<   bcdDevice            5.01
---
>   bcdDevice            5.0d

Maybe 5.0d is 5.13 since 0x0d = 13? In which case, maybe the previous firmware version was 5.1.

Lastly, I don't know how to see what kernel module a bluetooth device is using, but my best guess is I'm using vanilla xpad, in case it matters:

$ lsmod | grep xpad
xpad                   40960  0
ff_memless             20480  1 xpad

I'm using Ubuntu 20.04 with this kernel:

$ uname -r
5.13.0-41-generic

[kakra]

Maybe 5.0d is 5.13 since 0x0d = 13? In which case, maybe the previous firmware version was 5.1.

Yes, you can probably assume that.

Lastly, I don't know how to see what kernel module a bluetooth device is using, but my best guess is I'm using vanilla xpad, in case it matters:

xpad does not support Bluetooth devices. It was probably loaded when you connected the controller via USB: Over cable, it acts as a GIP device, over Bluetooth it acts as a HID device.

You can probably look in /sys/class/input to find the controller. It will point a symlink to path containing 0003:* (USB, bus 3) or 0005:* (Bluetooth, bus 5). Within that path, there's a device symlink which in turn has a driver symlink, that driver path has a pointer to the module.

[BaconCatBug]

So on a fresh install today, had this issue crop up. I fixed it with the

Privacy = device
JustWorksRepairing = always
Class = 0x000100
FastConnectable = true

under [General] of /etc/bluetooth/main.conf without any other faffing. The controller is a model 1914 with up to date firmware. I feel like this should be added in the troubleshooting steps as a last resort.

[kakra]

I think Privacy = device is just hiding the underlying problem. I should just work, it does here for me. Which bluez version and which dongle are you using?

Additionally, the troubleshooting docs have a section about this:
https://github.com/atar-axis/xpadneo/blob/master/docs/TROUBLESHOOTING.md#gamepad-does-not-connect-at-all-runs-a-reconnect-loop-or-immediately-disconnects

Actually, Privacy=device has been removed from it a while ago. It may be worth trying if disabling it after a successful pairing will still work.

Does dmesg warn about your firmware version (just in case although you mentioned it being up to date)? If yes, please consider upgrading the controller firmware.

[BaconCatBug]

Bluez 5.53, ZEXMTE Bluetooth USB Dongle, Kernel 5.17.12-xanmod1

No dmesg warnings.

I tried what you suggested, and removed Privacy=device, rebooted, tried to connect and it's now gone back to the same behavior of connecting, but the light continues to flash in pairing mode, then going into a connection/disconnection loop. I re-added Privacy=device, rebooted, and it now works. So it looks like, at least for me (and possibly others), this is a needed step.

[kakra]

Bluez 5.53, ZEXMTE Bluetooth USB Dongle, Kernel 5.17.12-xanmod1

Please run lsusb to identify the chipset of the dongle.

[BaconCatBug]

Bus 003 Device 002: ID 0bda:a725 Realtek Semiconductor Corp. Bluetooth 5.1 Radio

[kakra]

I think there was one report with at least another Realtek dongle before, so we might add a troubleshooting note especially for that chipset. But I think this better needs to be resolved in bluez or the kernel drivers (or the controller firmware itself for that matter). Many other dongles seem to work now without problems (especially after the latest firmware updates).

[kakra]

Closing old Bluetooth issues, please report to the bluez project if the problem persists.

[fjbf]

Manjaro Linux: 5.15.12-1-MANJARO Adaptor: ORICO BTA-608 (RTL8761B) Controller: xbox carbon black (has the "share" button - not sure the number of the model)

First, I started off by modifying /etc/bluetooth/main.conf to add this under [General]:

Privacy = device
JustWorksRepairing = always
Class = 0x000100
FastConnectable = true

Thank you for sharing this tip, @ipkpjersi! My controller (with the share button) is now pairing. Before adding these settings it would always enter the connection loop after pairing - and even putting the controller back in pairing mode wouldn't help.

Funny thing though: on my old laptop I didn't need to do this config - the only step I did was update the controller firmware on a windows running on the same laptop. And I'm running the same distro/kernel version on both machines. I can collect btmon log on that machine if it helps to debug this issue. I also have an xbox one controller that works flawlessly with or without custom settings - might share/test anything with it if helps debugging.

btmon logs

Sharing this in case it helps to debug the issue.

Custom settings

steps to reproduce: "forget" all previously paired bluetooth devices (did this through kde-plasma ui) > change /etc/bluetooth/main.conf > systemctl restart bluetooth > btmon | tee > pair/trust/connect controller > turn off/on controller

log file

Everything works flawlessly. Played a little bit with it and didn't notice any lag.

Vanilla settings

steps to reproduce: "forget" all previously paired bluetooth devices (did this through kde-plasma ui) > change /etc/bluetooth/main.conf > systemctl restart bluetooth > btmon | tee > pair/trust/connect controller > turn off/on controller

log file

Interestingly returning to vanilla settings don't reproduce the original error but don't connect successfully as well. Instead, it keeps blinking as if it's not connected. Maybe "forgetting" all connections didn't clean everything properly 🤔

Working for me on Debian 12

[Kobi-Blade]

Not working for me on Debian 12 with KDE X11, I had to use xone instead and instantly worked.

There also no safe way to uninstall kdeconnect (as suggested by a contributer above), since it's a system package.