Closed vvdveen closed 2 years ago
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.
# 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)
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
:
remove DEVICE-MAC
pair DEVICE-MAC
connect DEVICE-MAC
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.
Now my controller works.
What did you do?
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 X and Y are inverted
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:
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.
I'll create a PR for it for you to test.
Great, just ping me.
I'm not exactly sure what the "link key" looks like. After the controller rumbles but the light is still blinking, I can see these sections in /var/lib/HOST-MAC/DEVICE-MAC/info
:
[General]
...
[IdentityResolvingKey]
...
[RemoteSignatureKey]
...
[LocalSignatureKey]
...
[LongTermKey]
...
[SlaveLongTermKey]
...
[DeviceID]
...
Does that look correct, or should there be something else called link?
I tried pairing and unpairing in Windows several times, which didn't seem to make a difference. But I'm using Windows on a separate laptop, not in a dual-boot situation. Maybe it only works once already paired with the same Bluetooth controller device?
The sections are different for BLE... Bluetooth up to Xbox Elite 2 have only one key section.
My controller works now. First of all I deactivated my internal Bluetoothcontroller an bought an external USB Bluetooth Controller, because the internal had a pretty bad range.
After that I got the same problems like before. But now I connected the controller with my Windows-PC and copied the BLE-paring-keys from the registry to the infofile in Linux. After restarting the Bluetooth service the Controller immediately connected to my Linux.
So one of the failure points seems to be the controller and the Linux Bluetooth stack negotiating the keys properly. It may work in maybe 1 of 20 tries properly but the others just fail. Copying the keys from Windows seems to always work.
After following these instructions, I was able to connect to the controller in Linux.
Don't know if it helps somehow but for me worked following:
No idea... black magic involved probably...
Yeah, it often looks like pairing the controller to any other host which successfully pairs the controller (Android, Windows) usually mostly fixes a following pairing in Linux. I think the Linux Bluetooth stack is incomplete from the view of the Xbox controller firmware and fails to properly initialize. Pairing to a different system may clear some invalid states. I wish it would be possible to somehow firmware-reset the controller, so it starts fresh. But I know of no such reset method.
After following these instructions, I was able to connect to the controller in Linux.
can confirm that copying keys from windows worked for me as well. At least as far as fixing the pairing and connecting issue (" PIN or Key Missing" Connect/Reconnect loop).
Edit: After connecting controller do other devices had to "e-pair it with a windows pc and recopy the keys... just a heads up for anyone running into the issue.
After following these instructions, I was able to connect to the controller in Linux.
can confirm that copying keys from windows worked for me as well. At least as far as fixing the pairing and connecting issue (" PIN or Key Missing" Connect/Reconnect loop).
How is the controller working for you ? Didn't look much into the issue but using mine via bluetooth has a noticable lag. USB connection is flawless.
After following these instructions, I was able to connect to the controller in Linux.
can confirm that copying keys from windows worked for me as well. At least as far as fixing the pairing and connecting issue (" PIN or Key Missing" Connect/Reconnect loop).
How is the controller working for you ? Didn't look much into the issue but using mine via bluetooth has a noticable lag. USB connection is flawless.
I'm running a osmc rpi3b+ setup trying to get things to work with steamlink (Xbox Wireless controller model 1914 - firmware 5.5.2641.0). Controlling the Kodi UI in osmc seems to be ok. But I'm running into problems with steamlink so couldn't test it in games yet.
The issue with steamlink seems to be that it's for whatever reason doubling over the left analog stick to serve as a super sensitive mouse input. Switching "controller - mouse" (or whatever it's called) in the steamlink overlay doesn't seem to do anything seems to be working as intend - Right analog stick moves a curser at appropriate speeds, left analog stick still spazzes out.
But this appears to be a steamlink/osmc issue not related to xpadneo as steamlink does appear to discover the controller as an XInputDevice even with xpadneo removed. Interestingly it doesn't recognize the controller when it's not paired via bluetooth but plugged in through usb directly...
I didn't need to copy the keys from Windows, after it connected on a W10 virtual machine, I could connect to a the host with a 1914 model controller. It's the second gamepad I connect and now none of them shows up for the games I've tested (supertux and a game in steam). Guess that's a different issue, as the connected/disconnected loop that I was experiencing is gone.
@rubencabrera Does it show up in jstest
and evtest
? If yes, then that's a different issue.
@kakra No, none of the controllers shows up now for those. Nothing is shown in the jstest-gtk, none of the events available in /dev/input/
matches the controllers, the number of options there doesn't change when disconnecting. I can't see changes in /dev/
either.
Funny thing is that on the bluetooth manager they show as connected. While both are, I can see this from bluetoothctl info
:
Device 44:16:22:6B:C3:1A (public)
Name: Xbox Wireless Controller
Alias: Xbox Wireless Controller
Appearance: 0x03c4
Icon: input-gaming
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Vendor specific (00000001-5f60-4c4f-9c83-a7953298d40d)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb)
UUID: Human Interface Device (00001812-0000-1000-8000-00805f9b34fb)
Modalias: usb:v045Ep0B13d0501
ManufacturerData Key: 0x0006
ManufacturerData Value:
00
^That's for the 1914 model, if I turn it off, then the info command for the other shows:
Device 44:16:22:0A:D3:B8 (public)
Name: Xbox Wireless Controller
Alias: Xbox Wireless Controller
Class: 0x00000508
Icon: input-gaming
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: usb:v045Ep02FDd0903
Don't want to pollute this issue report with something unrelated, but wasn't sure if it is or not.
So it seems BT is okay. Then maybe the driver is not bound properly. Run dmesg -w
in a second terminal and connect the device, watch what happens in the second terminal.
Doing it just for one controller, the model 1708, which used to work fine until the 1914 connected.
[< 549,396284>] hid-generic 0005:045E:02E0.001C: unknown main item tag 0x0
[< 0,000326>] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.001C/input/input45
[< 0,000504>] hid-generic 0005:045E:02E0.001C: input,hidraw5: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on ac:ed:5c:5d:5e:93
It doesn't seem to trigger loading/binding xpadneo. Could you check if DKMS actually reinstalled xpadneo after the latest kernel update? I have at least one user report that found DKMS didn't rebuild the driver after kernel update. The cause for this is unknown but you can fix it by reinstalling the driver.
dkms status
yields: hid-xpadneo, v0.9-4-gbf8a3c3, 4.15.0-124-generic, x86_64: installed
but uname -a
shows Linux myhostname 4.15.0-126-generic
. I don't remember updating the kernel between the moment the second Xbox controller could connect and when none of the 2 were detected, these 2 events were almost immediate, IIRC. Not sure if there's a correlation here or I just messed with something that made this more confusing.
Well, another kernel update became available, so I just installed.
dkms status
showed
hid-xpadneo, v0.9-4-gbf8a3c3, 4.15.0-124-generic, x86_64: installed
hid-xpadneo, v0.9-4-gbf8a3c3, 4.15.0-128-generic, x86_64: installed
but nothing changed.
Uninstalled xpadneo and installed again. When connecting the 1708 controller it rumbled (which it didn't do before even though it was working quite well in every other aspect). The 1914 doesn't rumble but it is now detected and usable in games, there's about half a second lag, but we can leave that for another issue.
I'm going to give it a test run this weekend, thanks a lot for your help!
In case it helps anyone who doesn't have a dual boot or a second windows device (connecting the 1914 controller to an android device didn't do the trick for me):
groups
on your terminal). If not, add it with sudo adduser $USER vboxusers
, this is quite important for the guest VM to see the bluetooth controller.lsusb -v
and looking for the name of the device with Bluetooth
next to bDeviceProtocol
(that's how I found mine, yours might differ). Select the correct device. In my case VBox took hold of the controller and Bluetooth was not available on the host anymore, if this doesn't happen automatically, try to disable BT on the host first.I used this askubuntu answer as help, what I wrote here adds some of my experience but I found the answer very useful in case you want to check.
If you did the dmesg -w
thing again, you should see hid-xpadneo taking over the device this time. I'm not sure if this worked for the second controller: If it doesn't rumble on connect, it's usually not been taken over by xpadneo.
dmesg -w
shows when the 1708 connects:
[< 40,686001>] hid-generic 0005:045E:02E0.000B: unknown main item tag 0x0
[< 0,000205>] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.000B/input/input28
[< 0,000474>] hid-generic 0005:045E:02E0.000B: input,hidraw5: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on ac:ed:5c:5d:5e:93
1914 controller then enters the connected/disconnected loop as before connecting it to Windows 10 (I'm now stuck at getting the guest VM to see the bluetooth again, for some reason my steps above don't work now -edit: the udev vbox rules had disappeared, I might be touching many things at the same time). No messages are shown in dmesg -w
output.
VirtualBox udev rules had disappeared, I reinstalled virtualbox 6.1 and in the Widows 10 VM I had the controller light flashing, so had to remove it and pair it again with Windows 10. That succeeded. I went back to the host and now, again, both controllers connect but xpadneo is not used, I have the same output in dmesg as before. Uninstalling xpadneo and installing again.
Dmesg shows:
First controller (1708):
[< 289,449072>] hid-generic 0005:045E:02E0.0008: unknown main item tag 0x0
[< 0,000202>] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.0008/input/input25
[< 0,000549>] hid-generic 0005:045E:02E0.0008: input,hidraw5: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on ac:ed:5c:5d:5e:93
[< 0,095636>] hid_xpadneo: unknown parameter 'disable_ff' ignored
[< 0,000258>] xpadneo 0005:045E:0B13.0006: fixing up Rx axis
[< 0,000004>] xpadneo 0005:045E:0B13.0006: fixing up Ry axis
[< 0,000004>] xpadneo 0005:045E:0B13.0006: fixing up Z axis
[< 0,000004>] xpadneo 0005:045E:0B13.0006: fixing up Rz axis
[< 0,000004>] xpadneo 0005:045E:0B13.0006: fixing up button mapping
[< 0,000491>] xpadneo 0005:045E:0B13.0006: working around wrong SDL2 mappings (changed version from 0x00000501 to 0x00000501)
[< 0,000004>] xpadneo 0005:045E:0B13.0006: enabling compliance with Linux Gamepad Specification
[< 0,000160>] input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.0006/input/input26
[< 0,000424>] xpadneo 0005:045E:0B13.0006: input,hidraw5: BLUETOOTH HID v5.01 Gamepad [Xbox Wireless Controller] on AC:ED:5C:5D:5E:93
[< 0,000010>] xpadneo 0005:045E:0B13.0006: controller quirks: 0x00000050
[< 0,980188>] xpadneo 0005:045E:0B13.0006: Xbox Wireless Controller [44:16:22:6B:C3:1A] connected
[< 0,000088>] xpadneo 0005:045E:02E0.0008: fixing up report size
[< 0,000211>] xpadneo 0005:045E:02E0.0008: battery detected
[< 0,000002>] xpadneo 0005:045E:02E0.0008: working around wrong SDL2 mappings (changed version from 0x00000903 to 0x00000903)
[< 0,000000>] xpadneo 0005:045E:02E0.0008: enabling compliance with Linux Gamepad Specification
[< 0,000061>] input: Xbox Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.0008/input/input27
[< 0,000231>] xpadneo 0005:045E:02E0.0008: input,hidraw6: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on ac:ed:5c:5d:5e:93
[< 0,000002>] xpadneo 0005:045E:02E0.0008: controller quirks: 0x00000040
[< 0,979578>] xpadneo 0005:045E:02E0.0008: Xbox Wireless Controller [44:16:22:0a:d3:b8] connected
[< 0,798706>] xpadneo 0005:045E:02E0.0008: battery registered
Nothing shows up when I connect the second controller, but what you see in the output above is also related to it (its the MAC ending in 1A
).
Both controllers are usable not from games, but 1914 controller is having the half a second lag.
I'll leave things as they are till tomorrow and be sure to not install anything or do any upgrades. I want to see if the same situations repeats itself after a reboot. Let me know if there's any other test of logs that might be useful.
Version of xpadneo
v0.9-1-g84cabe9
Severity / Impact
Critical
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
Controller and Bluetooth information
Additional context
Happy to help debugging this issue further!