xpadneo
xpadneo copied to clipboard
atar-axis
xbox series x controller connected but not working
Version of xpadneo
v0.9-1-g84cabe9
Severity / Impact
Critical
- [x] I've read (most of the) the docs and the bug reporting instructions
- [x] 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 ...
- [x] 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
Additional context
Happy to help debugging this issue further!
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
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
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:
- Use
remove DEVICE-MAC - Put the controller into pairing mode
- Wait for it to announce itself, then use
pair DEVICE-MAC - When it paired, immediately run
connect DEVICE-MAC - Check if the link key was written to the info file, otherwise restart from step 1
- 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.
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?
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.
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.
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
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.
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.
I tried to compile fluoride but without success, i get error using gn as a build system.
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.
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.
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.
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.
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
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.
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
I booted into Win 10 and updated the firmware too but unfortunately I still can't get mine to work in Linux :(
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.
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.
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
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?
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.
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.
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.
I had the same problem. Controller worked only via USB. I downloaded the latest version of Windows, updated the controller firmware via Xbox Acessories and paired. Then rebooted into Linux and now it works. But yes, with wrong button mappings. Via USB controller still have correct mappings.
But yes, with wrong button mappings. Via USB controller still have correct mappings.
I have a fix queued. I'll create a PR for it for you to test. I don't have this controller so I cannot test myself but it seems a similar issue like with the Elite 2 controller in SDL.