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

carterDWatts commented 3 years ago

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 commented 3 years ago

Which kernel version?

carterDWatts commented 3 years ago

uname -r

5.12.8-arch1-1

kakra commented 3 years ago

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 https://github.com/bluez/bluez/issues/127.

If it works after uninstalling kdeconnect, you are probably seeing https://github.com/bluez/bluez/issues/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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

Termuellinator commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 https://github.com/atar-axis/xpadneo/issues/295#issuecomment-861718311 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 commented 3 years ago

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 https://github.com/atar-axis/xpadneo/issues/295#issuecomment-855226123 - no response yet though.

kakra commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 https://github.com/bluez/bluez/issues/127 may have the same root as this issue?

kakra commented 3 years ago

i wasn't sure if bluez/bluez#127 may have the same root as this issue?

Probably not, XB1S is Bluetooth HID profile, XBXS is Bluetooth LE, both Bluetooth protocols seem to work quite differently. At a first glance, the connection issues with BLE look quite different from what I reported in bluez#127, but I didn't look in detail yet.

crwxrws commented 3 years ago

@kakra, thanks for reminding me of firmware updates! I updated my 1914 today, and I was finally able to connect and play normally, via Bluetooth. Before the update I was having similar connection issues. My kernel is the default that comes with Arch, namely Linux 5.12.9-arch1-1 #1 SMP PREEMPT Thu, 03 Jun 2021 11:36:13 +0000 x86_64 GNU/Linux.

The controller automatically connects to my system once I power it on with the Xbox button. This produces the following output in the journal (hardware addresses censored):

Jun 16 22:56:05 arch kernel: xpadneo 0005:045E:0B13.0009: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x02E0)
Jun 16 22:56:05 arch kernel: xpadneo 0005:045E:0B13.0009: working around wrong SDL2 mappings (changed version from 0x00000507 to 0x00000903)
Jun 16 22:56:05 arch kernel: xpadneo 0005:045E:0B13.0009: report descriptor size: 283 bytes
Jun 16 22:56:05 arch kernel: xpadneo 0005:045E:0B13.0009: fixing up Rx axis
Jun 16 22:56:05 arch kernel: xpadneo 0005:045E:0B13.0009: fixing up Ry axis
Jun 16 22:56:05 arch kernel: xpadneo 0005:045E:0B13.0009: fixing up Z axis
Jun 16 22:56:05 arch kernel: xpadneo 0005:045E:0B13.0009: fixing up Rz axis
Jun 16 22:56:05 arch kernel: xpadneo 0005:045E:0B13.0009: fixing up button mapping
Jun 16 22:56:05 arch kernel: xpadneo 0005:045E:0B13.0009: gamepad detected
Jun 16 22:56:06 arch kernel: xpadneo 0005:045E:0B13.0009: enabling compliance with Linux Gamepad Specification
Jun 16 22:56:06 arch kernel: input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.0009/input/input29
Jun 16 22:56:06 arch kernel: xpadneo 0005:045E:0B13.0009: input,hidraw6: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on 80:32:--:--:--:--
Jun 16 22:56:06 arch kernel: xpadneo 0005:045E:0B13.0009: controller quirks: 0x00000050
Jun 16 22:56:06 arch kernel: xpadneo xpadneo_welcome_rumble start
Jun 16 22:56:06 arch kernel: xpadneo xpadneo_welcome_rumble took 990ms
Jun 16 22:56:06 arch kernel: xpadneo 0005:045E:0B13.0009: Xbox Wireless Controller [44:16:--:--:--:--] connected
Jun 16 22:56:07 arch kernel: xpadneo 0005:045E:0B13.0009: consumer controls not detected

I've also noticed that jstest lists slightly different inputs depending on whether the controller is connected via USB or via Bluetooth.

USB:

Joystick (Generic X-Box pad) has 8 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y)
and 11 buttons (BtnA, BtnB, BtnX, BtnY, BtnTL, BtnTR, BtnSelect, BtnStart, BtnMode, BtnThumbL, BtnThumbR).

Bluetooth:

Joystick (Xbox Wireless Controller) has 9 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y, (null))
and 10 buttons (BtnA, BtnB, BtnX, BtnY, BtnTL, BtnTR, BtnSelect, BtnStart, BtnThumbL, BtnThumbR).

First, the Xbox button (BtnMode) doesn't exist with Bluetooth (I guess that might be expected). Second, there is an extra axis with Bluetooth, called (null). Its value follows the state of the Left Trigger, although not quite the same as the actual Left Trigger. The actual one goes from -32767 to 32767, while the (null) one goes from 0 to -32767.

I can give you more info later, I just wanted to report that not everything is broken. :)

kakra commented 3 years ago

BtnMode will be exposed via an additional keyboard device. It may be possible that I did not yet push the commits needed for this model but if I did, you should see a device "Xbox Wireless Controller Consumer Control" which has the Share button and the Xbox button.

The (null) axis is actually a combination of left and right trigger. It is positioned after the first 6 axis so most games will ignore it. It is there as a roll axis or rudder panel for simulators.

crwxrws commented 3 years ago

Oh I see, that's great! I should mention that I'm probably not using the latest version of xpadneo, because I haven't touched it since the last time I tried to get it to work, roughly a month ago. I will take another look hopefully tomorrow. Thank you!

kakra commented 3 years ago

@crwxrws Just checked, did not merge yet: https://github.com/atar-axis/xpadneo/pull/292 - but you may test the PR and report back there.

kakra commented 3 years ago

Please check the output of

zgrep CONFIG_CRYPTO_USER_API_ /proc/config.gz

(your distribution may actually store the kernel configuration somewhere else, maybe /boot/config)

Also reported here: https://bugs.gentoo.org/796398

Termuellinator commented 3 years ago

CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_CRYPTO_USER_API_RNG=m
# CONFIG_CRYPTO_USER_API_RNG_CAVP is not set
CONFIG_CRYPTO_USER_API_AEAD=m
# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set

module should be fine i guess?

kakra commented 3 years ago

Run lsmod to see if they auto-loaded when bluetooth.service started. Otherwise, load them manually, then restart bluetooth.service. The modules are called algif_{hash,skcipher}.

Termuellinator commented 3 years ago

yeah they are loaded - and because of that i just tried it again and it worked as it should. Interesting, i'll have to test if that is because of recent updates in manjaro or changes in 5.13 rc6. Will have to do that after work though ^^

kakra commented 3 years ago

Okay, maybe keep your report in the bluez project updated.

Termuellinator commented 3 years ago

just to have it mentioned here, too:

So it really seems that 5.13rc6 changed something - in 5.12 i can't connect. Although things are different - the connect/disconnect loop in pairing mode is gone. When i now try to pair the controller, i get:

[bluetooth]# pair 44:16:22:D1:40:A2
Attempting to pair with 44:16:22:D1:40:A2
[CHG] Device 44:16:22:D1:40:A2 Connected: yes
Failed to pair: org.bluez.Error.AuthenticationFailed
[CHG] Device 44:16:22:D1:40:A2 Connected: no

on 5.13 i can pair it and it connects properly, if i turn off the controller it automatically connects after turning it on again - as long as i don't reboot. After reboot, i have to cancel the pairing and re-pair to make it work again. Plus, i get about i'd say 100-200ms lag in input, kind of as described in the mentioned reddit post, too.

crwxrws commented 3 years ago

My output is the same:

CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_CRYPTO_USER_API_RNG=m
# CONFIG_CRYPTO_USER_API_RNG_CAVP is not set
CONFIG_CRYPTO_USER_API_AEAD=m
# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set

I have no trouble connecting after a reboot.

carterDWatts commented 3 years ago

Are your successes all on 5.13? I'm have no changes on Linux carter-g14 5.12.11-arch1-1 #1 SMP PREEMPT Wed, 16 Jun 2021 15:25:28 +0000 x86_64 GNU/Linux.

My output is the same as well

CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_CRYPTO_USER_API_RNG=m
# CONFIG_CRYPTO_USER_API_RNG_CAVP is not set
CONFIG_CRYPTO_USER_API_AEAD=m
# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set

Both algif_hash and algif_skcipherare loaded.

journal on attempting to connect. Would the top line be an issue?

Jun 17 22:35:31 carter-g14 kernel: Bluetooth: hci0: link tx timeout
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x02E0)
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: working around wrong SDL2 mappings (changed version from 0x00000505 to 0x00000903)
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: report descriptor size: 283 bytes
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: fixing up Rx axis
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: fixing up Ry axis
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: fixing up Z axis
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: fixing up Rz axis
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: fixing up button mapping
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: enabling compliance with Linux Gamepad Specification
Jun 17 22:35:34 carter-g14 kernel: input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.000A/input/input41
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: input,hidraw8: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on f8:e4:e3:23:8d:6c
Jun 17 22:35:34 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: controller quirks: 0x00000050
Jun 17 22:35:35 carter-g14 kernel: xpadneo 0005:045E:0B13.000A: Xbox Wireless Controller [44:16:22:cb:bc:28] connected

kakra commented 3 years ago

@carterDWatts What does journalctl -eu bluetooth show? The hci timeout is probably an issue...

carterDWatts commented 3 years ago

Oh wow it's lit up red. This was when the controller cycled connected and disconnected. The last two lines looped printing.

Jun 22 12:33:13 carter-g14 bluetoothd[593]: src/profile.c:ext_start_servers() L2CAP server failed for Message Notification: setsockopt(L2CAP_OPTIONS): Invalid argument (22)
Jun 22 12:33:13 carter-g14 bluetoothd[593]: src/profile.c:ext_start_servers() L2CAP server failed for Message Access: setsockopt(L2CAP_OPTIONS): Invalid argument (22)
Jun 22 12:33:13 carter-g14 bluetoothd[593]: src/profile.c:ext_start_servers() L2CAP server failed for Phone Book Access: setsockopt(L2CAP_OPTIONS): Invalid argument (22)
Jun 22 12:33:13 carter-g14 bluetoothd[593]: src/profile.c:ext_start_servers() L2CAP server failed for File Transfer: setsockopt(L2CAP_OPTIONS): Invalid argument (22)
Jun 22 12:33:13 carter-g14 bluetoothd[593]: src/profile.c:ext_start_servers() L2CAP server failed for Object Push: setsockopt(L2CAP_OPTIONS): Invalid argument (22)
Jun 22 15:38:06 carter-g14 bluetoothd[593]: src/service.c:service_accept() input-hog profile accept failed for 44:16:22:CB:BC:28
Jun 22 15:38:06 carter-g14 bluetoothd[593]: profiles/deviceinfo/deviceinfo.c:read_pnpid_cb() Error reading PNP_ID value: Request attribute has encountered an unlikely error

kakra commented 3 years ago

That probably means the gamepad didn't pair properly. This may indicate an incompatible settings in bluez.conf, or a kernel config is still missing. I'm not sure how to continue from here, and a bluez dev may know better.

RuiGuilherme commented 3 years ago

@kakra I tried to connect my Echo Dot and I had the same issue as I was having "failed to pair: org.bluez.error.AuthenticationFailed", I came to the conclusion that was some configuration that I did so I decided to remove everything related to Bluetooth to start from scratch... I change only Privacy settings to device, I tried to revert it but it had no effect... It only worked after removing everything:

sudo pacman -Rdd bluez bluez-libs bluez-qt bluez-tools bluez-utils ell

sudo rm /etc/bluetooth/main.conf.pacsave

sudo rm /etc/bluetooth/main.conf

Remove xbox/echo from sudo rm -rf /var/lib/bluetooth/[MAC XBOX/ECHO]

sudo systemctl stop/disable bluetooth.service

sudo systemctl stop/disable bluetooth.target

sudo pacman -S bluez bluez-libs bluez-qt bluez-tools bluez-utils ell

sudo systemctl start/enable bluetooth.service

sudo systemctl start/enable bluetooth.target

Once I have done this, Echo Dot started to give another issue: https://github.com/bluez/bluez/issues/166

And Xbox X|S Controller give me this issue: https://github.com/atar-axis/xpadneo/issues/259

After remove and pair many times Xbox Controller just worked randomly.

kakra commented 3 years ago

Yeah, I think I've seen the issue as I've put all bluez activity on my watch list. I suspect that /var/lib/bluetooth caches some stuff even from unsuccessful previous attempts (maybe even related back to older bluez versions) and that may interfere with later tries. If you can reproduce that again, it may be sufficient to just purge the whole /var/lib/bluetooth folder empty.

Also, I'm running without Privacy = device - it should work:

# egrep -v '^(#.*)?$' /etc/bluetooth/main.conf
[General]
Name = %h-%d
FastConnectable = true
JustWorksRepairing = confirm
[BR]
[LE]
MinConnectionInterval=7
MaxConnectionInterval=9
ConnectionLatency=0
[GATT]
[AVDTP]
[Policy]
ReconnectIntervals=1,1,2,3,5,8,13,21,34,55
AutoEnable=true
[AdvMon]

zebulon2 commented 3 years ago

Many thanks @kakra for developing this driver.

I also acquired a controller model 1914 and am experiencing the same kind of issue as described above, using bluetoothctl for setup:

pairing works and leads to rumble but there is no input and light continues to flash. Sometimes a solid light may appear but this does not last more than a second before flashing again.
subsequent connections may lead to the connect/disconnect loop, but am not sure how to reproduce this 100%
under Steam, controller may be detected. "Identify" may lead to the controller rumbling (good) or not. That said, even if it is identified correctly, there is no working input. Steam may show button commands at the bottom (B Back, A Confirm, etc) but there is no input
all of this happens regardless of ERTM status, and /etc/bluetooth/main.conf is default one, I do not use the Privacy option.
as far as I could read, model 1914 and 1708 are working differently (e.g. 1708 works with iOS, but not 1914), so you might be right about needing specific commands for this model

Controller firmware has been updated to the latest version as of today and the USB cable connection works perfectly. My system runs Archlinux (current kernel 5.12.13) with an AX200 PCIe card that provides BT connection. I also have a separate BT dongle (I will provide specs later) but both AX200 and dongle lead to the same issue. I am happy to help by providing further info and testing.

zebulon2 commented 3 years ago

Note that kernel 5.13 has been released 2 days ago and we should get it in Archlinux around first week of July, if everything goes well. Maybe we will see improvement as reported by @Termuellinator. Has anyone tried the git version of bluez too?

kakra commented 3 years ago

@zebulon2

The latest model does not yet support iOS according to MS but they probably ship an update later, let's hope it also improves compatibility with bluez.

Also, the privacy setting should actually not be used. I've queued a commit in my local git which removes that recommendation from the instructions.

I've not tested this model with Steam Input yet (which you seem to use, otherwise there would be no option to identify the device). But it worked just fine for me with Steam Input disabled for that device. It may be a mapping problem, but the most reliable option is to use evtest to check for input data. If that doesn't work, the connection is not fully established, and Steam Input would not work, too. I've seen reports which hinted it may be necessary to completely purge the bluetooth configuration cache (stop the service, purge /var/lib/bluetooth empty, reboot), then re-pair the controller: If you tried connecting the controller before with wrong settings, this cache may be messed up.

zebulon2 commented 3 years ago

@kakra Many thanks for those pointers. I will try to clear the cache tonight. Also, the weird thing is that bluetoothctl returns that the device is connected, while the light is still flashing. I will report again.

kakra commented 3 years ago

Also, the weird thing is that bluetoothctl returns that the device is connected, while the light is still flashing

Yes, this problem is known: Your kernel is probably missing proper crypto user API modules. This has been fixed in bluez for Gentoo: https://bugs.gentoo.org/796398. If you are seeing the same log entry, then it's probably that bug and your distribution may need to fix the same kernel problem.

zebulon2 commented 3 years ago

Yes, this problem is known: Your kernel is probably missing proper crypto user API modules. This has been fixed in bluez for Gentoo: https://bugs.gentoo.org/796398. If you are seeing the same log entry, then it's probably that bug and your distribution may need to fix the same kernel problem.

These are my config options:

CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_CRYPTO_USER_API_RNG=m
# CONFIG_CRYPTO_USER_API_RNG_CAVP is not set
CONFIG_CRYPTO_USER_API_AEAD=m
# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set

Seems they are enabled, albeit as modules. Is it the issue there? Are there modules to load?

kakra commented 3 years ago

Yeah, try modprobe algif_skcipher and modprobe algif_hash (if I remember correctly).

It may well be that another thing may be missing that I already had in my kernel, and thus I could not identify that it would also be needed.

zebulon2 commented 3 years ago

Yeah, try modprobe algif_skcipher and modprobe algif_hash (if I remember correctly).

It may well be that another thing may be missing that I already had in my kernel, and thus I could not identify that it would also be needed.

OK I see. However those modules should autoload on modern systems, shouldn't they? I think the first thing to do is to look for error 'Failed to open crypto' in dmesg as you report on Gentoo bug list and then start from there. Could you also publish your .config file please? A diff would certainly help identifying differences.

kakra commented 3 years ago

Actually, I looked at the bluez source where the error comes from, and it comes from two places opening the API socket requesting both modules, this is the calling function: https://github.com/bluez/bluez/blob/808be93a11a54074aba901718d37aacaaa292356/src/shared/crypto.c#L131

If you want to diff it, I'm attaching my custom kernel config, it's from kernel 5.10.46 patched with CK (but I currently disabled MuQSS for debug/dev purposes). Maybe you can find something interesting.

Maybe it's the CMAC-AES and ECB-AES thing that's missing and also requested by those routines.

Not sure about auto-loading, I didn't try it. For tests, I just compiled the modules, loaded them, retried the pairing successfully, then I've switched the modules to built-in, re-installed the kernel and rebooted. The controller works since then.

config.gz

atar-axis / xpadneo