xbox series x controller connected but not working

[vvdveen]

Version of xpadneo

v0.9-1-g84cabe9

Severity / Impact

Critical

• I've read (most of the) the docs and the bug reporting instructions
• It does not work at all
• It used to work in a previous version
• It mostly works but sometimes it doesn't
• I found a work-around
• I probably didn't figure it all out but it's too early to give up
• I don't know how to ...
• It's too complicated
• Fantastic work but ...
• I can code and I want to help

Describe the bug

Connecting the new xbox series x controller fails. Pairing seems successful (the gamepad rumbles), but the X button on the controller continues to blink. Both dmesg and bluetoothctl claim the device is connected. The gamepad is also visible in jspad (there is a /dev/js0), but I am unable to get any interaction with the device.

Disconnecting and reconnecting brings the device in a reconnect loop.

I am on Ubuntu 20.04.1 (LTS). I tried with both my onboard Intel Dual Band Wireless-AC 3168 and a CSR8510 A10 Bluetooth dongle (same results). Today, I updated the controller's firmware to whatever is the latest version. The controller connects perfectly to my Android device.

Steps to Reproduce

See xpadneo-bluetoothctl.txt below. Basically just following the README.

Expected behavior

The device should connect (it seems it does?) and I should be able to use it.

System information

# uname -a
Kernel version: Linux ryzen 5.4.0-54-generic #60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
zsh: no matches found: /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor
4294967295 0
# ls /sys/module/hid_xpadneo/drivers/hid:xpadneo/
bind  module  new_id  uevent  unbind
# maybe I missed something?

Controller and Bluetooth information

• xpadneo-btmon.txt
• xpadneo-dmesg.txt
• xpadneo-lsusb.txt
• xpadneo-bluetoothctl.txt

Additional context

Happy to help debugging this issue further!

[dk89]

I'd like to attach to this issue because I have the same problem with my Series X Controller and my Raspberry PI 4 (Rasbian buster / RetroPie). Some time it says connected but the X keeps blinking and sometimes it's in a connection loop and keeps trying to connect.

System information

# uname -a
Linux retropie 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)

Controller and Bluetooth information

xpadneo-btmon.txt
xpadneo-dmesg.txt

[vvdveen]

Good to see I am not the only one :)

A different machine with an Intel Wireless 7260 chipset gives me similar issues.

I did manage to get the report_descriptor:

➜  0005:045E:0B13.0003 xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
00000000: 05 01 09 05 a1 01 85 01 09 01 a1 00 09 30 09 31 15 00 27 ff  .............0.1..'.
00000014: ff 00 00 95 02 75 10 81 02 c0 09 01 a1 00 09 33 09 34 15 00  .....u.........3.4..
00000028: 27 ff ff 00 00 95 02 75 10 81 02 c0 05 01 09 32 15 00 26 ff  '......u.......2..&.
0000003c: 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01 81 03 05 01 09  ...u.....%.u........
00000050: 35 15 00 26 ff 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01  5..&....u.....%.u...
00000064: 81 03 05 01 09 39 15 01 25 08 35 00 46 3b 01 66 14 00 75 04  .....9..%.5.F;.f..u.
00000078: 95 01 81 42 75 04 95 01 15 00 25 00 35 00 45 00 65 00 81 03  ...Bu.....%.5.E.e...
0000008c: 05 09 19 01 29 0c 15 00 25 01 75 01 95 0c 81 02 15 00 25 00  ....)...%.u.......%.
000000a0: 75 01 95 04 81 03 05 0c 0a b2 00 15 00 25 01 95 01 75 01 81  u............%...u..
000000b4: 02 15 00 25 00 75 07 95 01 81 03 05 0f 09 21 85 03 a1 02 09  ...%.u........!.....
000000c8: 97 15 00 25 01 75 04 95 01 91 02 15 00 25 00 75 04 95 01 91  ...%.u.......%.u....
000000dc: 03 09 70 15 00 25 64 75 08 95 04 91 02 09 50 66 01 10 55 0e  ..p..%du......Pf..U.
000000f0: 15 00 26 ff 00 75 08 95 01 91 02 09 a7 15 00 26 ff 00 75 08  ..&..u.........&..u.
00000104: 95 01 91 02 65 00 55 00 09 7c 15 00 26 ff 00 75 08 95 01 91  ....e.U..|..&..u....
00000118: 02 c0 c0                                                     ...
2986910699 1363

[kakra]

This is not an xpadneo issue, apparently. Secretly, I wish it would, then we could do something about it. But I found myself in a similar situation lately. But I was able to get it back to a working state by repeating the following steps until the link key appeared successfully in /var/lib/HOST-MAC/DEVICE-MAC/info using bluetoothctl:

1. Use remove DEVICE-MAC
2. Put the controller into pairing mode
3. Wait for it to announce itself, then use pair DEVICE-MAC
4. When it paired, immediately run connect DEVICE-MAC
5. Check if the link key was written to the info file, otherwise restart from step 1
6. Reboot

I needed to repeat the steps for 5-10 times until the controllers successfully connected again, and after reboot, it would even auto-connect again now without waiting 30-60s. It looks like repeating the steps often enough clears some internal broken state in the controller, or it depends on the timing you're doing the steps at.

Sometimes, it also works using the KDE GUI to pair the device by going through the "new device wizard" instead of using connect to select one from the devices shown. Whatever I did, it was important to remove the device first with bluetoothctl.

[vvdveen]

Thanks! I tried your suggestion many times now, but no link key shows up.

Do you think that the the missing link key is also causing the connect/disconnect loop later? The output of btmon makes me think it might be related (missing PIN or Key missing, so encryption fails, so the device disconnects):

...
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28    #54 [hci1] 4.818729
        Handle: 68
        Random number: 0x6001800500180660
        Encrypted diversifier: 0x001e
        Long term key: 80016006180005800160061800058001
> HCI Event: Command Status (0x0f) plen 4                   #55 [hci1] 4.824574
      LE Start Encryption (0x08|0x0019) ncmd 1
        Status: Success (0x00)
> HCI Event: Encryption Change (0x08) plen 4                #56 [hci1] 4.920600
        Status: PIN or Key Missing (0x06)
        Handle: 68
        Encryption: Disabled (0x00)
< HCI Command: Disconnect (0x01|0x0006) plen 3              #57 [hci1] 4.920637
        Handle: 68
        Reason: Authentication Failure (0x05)
...

What if we get a working link key from when the device is connected to Windows? Would that work? Also, what piece of software do you think is failing here? The bluetoothctl backend? The bluetooth driver? Something else?

[kakra]

Yes, I think it's possible to get the link key from the Windows registry and put it into the Bluetooth info file - but I'm not sure if the format needs to be converted. But I think it's possible according to the very early development stages of this driver. Also, I do not remember where it is stored.

Did you turn off ERTM? Otherwise, it won't work at all because the device disconnects due to invalid configuration profiles requested (which will result in a similar loop).

Another difference may be that I'm using the L2CAP patch instead of disabling ERTM. It's in the misc folder.

[kakra]

Also, there have been firmware updates fixing Bluetooth pairing and connection stability for the older models, maybe check if your model already has an update available. Windows will install firmware updates to the controller only in USB or GIP-dongle mode, not in Bluetooth mode.

[albertzdic]

Connecting the new xbox series x controller fails. Pairing seems successful (the gamepad rumbles), but the X button on the controller continues to blink. Both dmesg and bluetoothctl claim the device is connected.

Same here. I have ERTM disabled. I tried your suggestion several time without success.
Thanks for the work on the driver.
btmon.txt
dmsg.txt
lsbus.txt
uname.txt

[kakra]

Also, what piece of software do you think is failing here? The bluetoothctl backend? The bluetooth driver? Something else?

I'm not sure what exactly fails here. It's in the Bluetooth stack for sure - but if that's the kernel or the bluez daemon, I'm not sure. If we look at Android which uses the Linux kernel but a different Bluetooth stack (fluoride), and seeing that the controller pairs without problems there, it looks like the problem is in the bluez daemon. OTOH, the controller seems to behave differently based on the Bluetooth stack it sees, and after all seeing that the L2CAP patch works around one of the problems points to the kernel. It may be a bad combination of all three: The kernel, the bluez daemon, and the firmware.

If you manage to pair the controller by transferring the link key from Windows to Linux, it may be interesting to see if the controller presents us a different HID descriptor - and thus may have a "Windows mode".

Maybe we should check if the Linux kernel of Android uses some Bluetooth patches to support its fluoride daemon better. I haven't yet been able to compile fluoride in Linux.

[kakra]

Maybe we should check if the Linux kernel of Android uses some Bluetooth patches to support its fluoride daemon better. I haven't yet been able to compile fluoride in Linux.

Skimming through the commits to net/bluetooth and drivers/bluetooth in the Android kernel didn't reveal any Android-specific patches, so I think they are using the upstream kernel there. So the problem may be in Bluez. If someone manages to compile fluoride for a Linux distribution, it would be interesting to see if it fixes the connection problems, maybe even the rumble-associated disconnects.

[albertzdic]

I tried to compile fluoride but without success, i get error using gn as a build system.

[albertzdic]

Now my controller works.
I had to install windows to a virtual machine, start the app xbox accessories and upgrade the firmware, the upgrade was unsuccessful and the app don't recognize the controller in windows vm, but now in linux the controller works on bluetooth and on usb.

I don't now how but it's fixed.

[kakra]

Now my controller works.

What did you do?

[albertzdic]

I upgraded the firmware of the controller with the windows app in a virtual machine. The upgrade was unsuccessful but now in linux bluetooth works.

[kakra]

Yeah, there may a problem with updating in a virtual machine in that the controller reboots into a flash mode, and thus disconnects from the VM. You'd need to immediately re-connect it in that case for the firmware update to be successful.

[albertzdic]

Only a little thing is changed:
when the controller is connected by bluetooth the share button is mapped to select (the left button), when is connected by usb the select button is mapped correctly.

[albertzdic]

Yeah, there may a problem with updating in a virtual machine in that the controller reboots into a flash mode, and thus disconnects from the VM. You'd need to immediately re-connect it in that case for the firmware update to be successful.

ooops, i hope everything is ok

[kakra]

ooops, i hope everything is ok

Should be, if no firmware is being sent in that mode, nothing happens and the device will boot back normally after re-plugging it.

when the controller is connected by bluetooth the share button is mapped to select (the left button)

Looks like MS likes to shuffle buttons around again on firmware update. We should inspect that and fix the button, and if we cannot properly detect one or the other firmware, I'd prefer going with what the newer firmware provides.

[albertzdic]

also X and Y are inverted

[RustyStriker]

Also had this problem, booted into my windows 10, updated the controller's firmware, fixed all issues... It seems the xbox sx require the update in order to function properly, as before the update it would connect and dc multiple times(not always rumbling).
Axises and buttons didnt change for me

[japgolly]

I booted into Win 10 and updated the firmware too but unfortunately I still can't get mine to work in Linux :(

[johnhoran]

Similiar issue, on first pairing I noticed

(II) config/udev: Adding input device Xbox Wireless Controller (/dev/input/js0)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(II) config/udev: Adding input device Xbox Wireless Controller (/dev/input/event25)
(**) Xbox Wireless Controller: Applying InputClass "libinput keyboard catchall"
(II) Using input driver 'libinput' for 'Xbox Wireless Controller'
(II) systemd-logind: got fd for /dev/input/event25 13:89 fd 64 paused 0
(**) Xbox Wireless Controller: always reports core events
(**) Option "Device" "/dev/input/event25"
(**) Option "_source" "server/udev"
(II) event25 - Xbox Wireless Controller: is tagged by udev as: Keyboard Joystick
(II) event25 - Xbox Wireless Controller: device is a keyboard
(II) event25 - Xbox Wireless Controller: device removed
(**) Option "config_info" "udev:/sys/devices/virtual/misc/uhid/0005:045E:0B13.0008/input/input29/event25"
(II) XINPUT: Adding extended input device "Xbox Wireless Controller" (type: KEYBOARD, id 18)
(II) event25 - Xbox Wireless Controller: is tagged by udev as: Keyboard Joystick
(II) event25 - Xbox Wireless Controller: device is a keyboard

in journalctl, so I tried adding 0B13 entries to udev and modprobe. My controller now vibrates but the pairing light never stops flashing and it never appears in steam.

[kakra]

when the controller is connected by bluetooth the share button is mapped to select (the left button)

Should be fixed in my queued commits. I was seeing a similar problem for XBE2, and that resulted from an SDL2 upgrade that put the controller into its database.

[keidax]

Having the same issue, I upgraded the firmware in Windows but that didn't make any difference.
After applying @kakra's changes to udev and modprobe, I see these two errors in journalctl output:

Nov 29 00:14:36 titan kernel: Bluetooth: hci0: link tx timeout
Nov 29 00:14:38 titan kernel: input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.0009/input/input34
Nov 29 00:14:38 titan kernel: hid-generic 0005:045E:0B13.0009: input,hidraw6: BLUETOOTH HID v5.05 Gamepad [Xbox Wireless Controller] on 8c:c6:81:ce:51:d9
Nov 29 00:14:38 titan systemd-udevd[10333]: 0005:045E:0B13.0009: /etc/udev/rules.d/98-xpadneo.rules:3 Failed to write ATTR{/sys/devices/virtual/misc/uhid/0005:045E:0B13.0009/[drivers/hid:xpadneo]bind}, ignoring: No such file or directory

[kakra]

I'd say you are in the reconnect loop then currently. The udev error is there because the device is already gone, our driver wasn't even loaded yet. Do you see the link key in the Bluetooth database?

[vvdveen]

Found some time to look at this again. I extracted the key information from the windows registry and added a LinkKey section to the /var/lib/bluetooth/<mac>/<mac>/info file. Connecting with bluetoothctl didn't work (again a loop). I then removed the configuration files and tried again from bluetoothctl. This time it did work and it seems to be pretty stable also. It is weird, because I tried this many times before with no luck. The only difference now is that I paired the controller in Windows, which maybe removed some internal state in the controller? Or I got lucky...

There is no LinkKey section in the bluetooth info file.

[kakra]

I'm suspecting that there is some internal state that gets cleared by luck sometimes, otherwise I cannot explain the seemingly random behaviors. The link key section shouldn't be missing, tho. You might by lucky to get it when trying to pair again.

[ShadowNinja]

I can confirm that booting into Windows, pairing the controller, and then unpairing it while it's connected fixes the failure to pair.

Steps I followed:

• Unpaired the controller in Linux.
• Rebooted into Windows and paired the controller
• Rebooted into Linux and tried to pair the controller unsuccessfully (controller buzzes, and it shows up as a controller in an SDL app (antimicrox), but the pair light on the controller doesn't stop blinking and inputs don't register in antimicrox).
• Rebooted into Windows. I noticed that Windows also seemed to also be stuck in a disconnect/reconnect loop this time. I unpaired the controller, repaired it, and then unpaired it while it was still connected.
• Rebooted into Linux. This time I was able to pair the controller successfully (other than the back/share/guide and L/R stick click mappings being wrong, but that's a seperate issue). I'm able to disconnect and reconnect successfully.

[intgr]

I have similar issues as reported in this bug: pairing/connecting seems successful, the controller rumbles, but "X" button continues flashing and there's no LinkKey in device info file.

More remarkably, setting Privacy = device in main.conf entirely prevents pairing with the controller. Did anyone else see this behavior?

I tried Linux 5.12rc2, which as the L2CAP patch, along with both disable_ertm=Y and N, but toggling it did not seem to affect any behavior.

• hid-xpadneo v0.9-36-gb827510
• Linux 5.12rc2 (tried 5.11.6-arch1-1 too)
• Bluetooth PCIe controller Wireless-AC 9260 (rev 29) -- other people report success with this
• Model: Xbox Series X Controller Carbon Black
• Controller firmware upgraded via Xbox Accessories

report_descriptor

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
00000000: 05 01 09 05 a1 01 85 01 09 01 a1 00 09 30 09 31 15 00 27 ff  .............0.1..'.
00000014: ff 00 00 95 02 75 10 81 02 c0 09 01 a1 00 09 33 09 34 15 00  .....u.........3.4..
00000028: 27 ff ff 00 00 95 02 75 10 81 02 c0 05 01 09 32 15 00 26 ff  '......u.......2..&.
0000003c: 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01 81 03 05 01 09  ...u.....%.u........
00000050: 35 15 00 26 ff 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01  5..&....u.....%.u...
00000064: 81 03 05 01 09 39 15 01 25 08 35 00 46 3b 01 66 14 00 75 04  .....9..%.5.F;.f..u.
00000078: 95 01 81 42 75 04 95 01 15 00 25 00 35 00 45 00 65 00 81 03  ...Bu.....%.5.E.e...
0000008c: 05 09 19 01 29 0c 15 00 25 01 75 01 95 0c 81 02 15 00 25 00  ....)...%.u.......%.
000000a0: 75 01 95 04 81 03 05 0c 0a b2 00 15 00 25 01 95 01 75 01 81  u............%...u..
000000b4: 02 15 00 25 00 75 07 95 01 81 03 05 0f 09 21 85 03 a1 02 09  ...%.u........!.....
000000c8: 97 15 00 25 01 75 04 95 01 91 02 15 00 25 00 75 04 95 01 91  ...%.u.......%.u....
000000dc: 03 09 70 15 00 25 64 75 08 95 04 91 02 09 50 66 01 10 55 0e  ..p..%du......Pf..U.
000000f0: 15 00 26 ff 00 75 08 95 01 91 02 09 a7 15 00 26 ff 00 75 08  ..&..u.........&..u.
00000104: 95 01 91 02 65 00 55 00 09 7c 15 00 26 ff 00 75 08 95 01 91  ....e.U..|..&..u....
00000118: 02 c0 c0                                                     ...
2986910699 1363

[kakra]

There are a lot of Bluetooth patches floating around currently, we may need to wait until 5.12.0 settled. Especially, there are patches working on BLE and privacy mode.

[intgr]

@kakra I see. Can you link to any patches in particular that you think can help? Thanks!

[kakra]

@intgr I've created a project about all known Bluetooth problems which may be useful but I cannot pinpoint any particular commits to fixing any particular problem. The commits are more like general improvements, and the sum of those may make the controller work more reliably (or the opposite for that matter).

When we get to know about particular kernel versions fixing a problem, I'll add columns to the project identifying the kernel or Bluez version and will move issues there.

In general, it seems like onboard Bluetooth chipsets are more problematic than USB Bluetooth dongles. This may be due to many onboard chips requiring firmware, there are some commits around firmware loading bugs in the bluetooth kernel list. You may also want to try updating the linux-firmware package. But apparently there's not much more we can do except sit and wait, and yes, take note of any observations.

[j0sk]

In general, it seems like onboard Bluetooth chipsets are more problematic than USB Bluetooth dongles. This may be due to many onboard chips requiring firmware, there are some commits around firmware loading bugs in the bluetooth kernel list.

I updated the Xbox series x controller firmware and edited all bluetooth related environment variables just to get pairing issue and controller light stayed blinking. My other controller, Xbox One S controller works without any issues.

Then I remembered that I have extra bluetooth dongle and I disabled the onboard bluetooth chipset. Now both of my controllers are working with this usb dongle.

lsusb | grep 'Bluetooth'

Bus 006 Device 003: ID 8087:0029 Intel Corp. AX200 Bluetooth

Bus 002 Device 003: ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth

So there are pairing issues with Series X controller when using the Intel Corp. AX200 Bluetooth chipset but it pairs just fine the xbox one controller.
Both of the controllers are working fine with Asus dongle. (Asus BT400)

[ByteRaper]

On Retropie with current updates (kernel 5.10.17) and bluez 5.58, it's not possible to pair/connect to Xbox Wireless Controller (4416).
Also tried the Asus BT400 dongle and every fix I could find. Controller is on the newest firmware and working fine under Windows.

The Dude on #279 has the same controller it seems ( the MAC of these controllers begin with 44:16:xx ) so my question just got answered.

[kakra]

The Dude on #279 has the same controller it seems ( the MAC of these controllers begin with 44:16:xx

There may still be subtle differences with chipset revision or actual implementation. Usually, those chipset share the same OEM MAC but have custom board designs, different firmware versions or slightly different wiring and quirks. That's probably why the btusb driver supports such vast amounts of very different dongles: In the end, it's mostly the same chip design and they work all kind of the same.

[zebulon2]

See #295 (comment) for a workaround proposed by stobb3s and also mentioned in https://bbs.archlinux.org/viewtopic.php?pid=1678405#p1678405 as early as 2016!

[rinnaz]

Now it seems to be working with kernel 5.14 and following BT config

[General]
Privacy = device
JustWorksRepairing = always
Class = 0x000100
FastConnectable = true

[kakra]

@rinnaz Which bluez version?

[ahmtcn123]

Now it seems to be working with kernel 5.14 and following BT config

[General]
Privacy = device
JustWorksRepairing = always
Class = 0x000100
FastConnectable = true

Can you add some details?

[rinnaz]

@kakra bluez 5.53

@ahmtcn123 Sure. Let me know if you are interested in something specific

• xpadneo: latest git version
• Linux: 5.14.5-mainline
• Bluetooth adapter: TP-Link UB400 USB
• Model: Xbox Series X Controller
• Controller firmware upgraded via Xbox Accessories

Modifying /etc/bluetooth/main.conf fixes reconnection loops, and kernel 5.14 makes it able to pair. Sometimes it fails to reconnect though (controller rumbles, but logo continues blinking), but it seems to be BT adapter issue.

[kakra]

Sometimes it fails to reconnect though

This may be due to using Privacy = device and using attribute caching of bluez.

[kakra]

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