List of USB BT sticks (add to README)

[atar-axis]

Some users have issues to connect the gamepad to their USB BT stick.
This is in general not a xpadneo issue. But it would be great anyway to have a list of dongles which are compatible and of those which are not.

It would be great if some of you could share their experience too!
We are especially interested in

• How reliable is the connection?
• The output of lsusb | grep -i 'blue'
• The Chipset (if you know)
• where to buy it

---

Cambridge Silicon Radio

• Panda Bluetooth 4.0 USB Nano Adapter
  • Chipset: CSR ???
  • ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
  • Performance:
    • Initial Connection Problems
    • Reliable once connected
  • Reported by @ugly95 here
• MIATONE Bluetooth Adapter Bluetooth CSR 4.0
  • Chipset: CSR8510
  • ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
  • Performance:
    • Initial Connection Problems
    • Reliable once connected
  • Reported by @ugly95 here
• CSL - Bluetooth 4.0 USB Adapter
  • Chipset: CSR 8510 A10
  • ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
  • Performance:
    • Initial Connection Problems
  • Reported by @germangoergs here and here
• Sabrent USB Bluetooth 4.0 Micro Adapter for PC
  • Chipset CSR ???
  • ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
  • Performance:
    • Initial Connection Problems
    • Reliable once connected
  • Reported by @ugly95 here
• Yizhet USB nano Bluetooth 4.0 Adapter
  • Chipset CSR 8510 A10
  • ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
  • Performance:
    • Initial Connection Problems
    • Reliable once connected
  • Reported by @NoXPhasma here

Broadcom

• Plugable USB Bluetooth 4.0 Low Energy Micro Adapter
  • Chipset: BCM20702A0
  • ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
  • Performance:
    • Initial Connection flawless
    • Gameplay sometimes laggy
  • Reported by @ugly95 here and here

[TobiPeterG]

Unreliable device:

• https://www.amazon.de/dp/B01N0368AY/ref=cm_sw_r_cp_apa_i_wn8QCbJNF759S
  • Chipset: CSR 8510 A10
  • ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

[ugly95]

Unreliable device:

• Sabrent USB Bluetooth 4.0 Micro Adapter for PC [v4.0 Class 2 with Low Energy Technology] (BT-UB40)
  • Chipset CSR ???
  • Performance is consistent with other CSR-based dongles I've tried
  • ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

I think the categories should be clarified slightly. It's been almost 2 months since that post and, after testing, I actually prefer the CSR chipsets, even thought they are 'unreliable'.

To clarify, with all the CSR chipset dongles I've tried (3 in total now) it is only the initial connection that is unreliable. However, once the connection is made, the gamepad works perfectly.

As I mentioned, in the previous issue, the workaround to the unreliable connection is to make a script (replacing the MAC address for the one for your own gamepad):

#!/bin/bash

echo -e 'connect 5C:BA:37:D4:46:6A' | bluetoothctl

Usually I only have to run that script once and it connects. Sometimes I need to do it a couple of times. It's a minor inconvenience.

After a few months of using the Broadcom USB dongle, I don't like it. The initial connection is great. Within seconds of powering on my gamepad it connects. So Broadcom beats CSR there.

However, during gameplay, I eventually had some troubles with the Broadcom dongle. Input would be laggy sometimes. And I noticed that if I was idle for a while (maybe a minute without pressing a button) sometimes the next button input wouldn't register. More of an issue is that the controller would occasionally get locked into a rumble. The gamepad would rumble continually until I shut off the controller. This would also result in the gamepad no longer accepting any input until I powered the gamepad off and on again.

In my experience, CSR adapters are unreliable with the initial connection, but otherwise work great. Broadcom adapters are great with the initial connection, but were unreliable for gameplay. I no longer use my Broadcom adapter, and personally would recommend the CSR adapters.

So what is unreliable is the initial connection.

[atar-axis]

I updated the list, thank you for clarifying and the update!

What I can offer you is to change the rumble duration, at the moment we are sending rumble messages to the gamepad which let it rumble as long as possible (~10 minutes) until another message is sent which stops rumbling. So I guess that this message gets lost sometimes which causes the gamepad to rumble the whole 10 minutes. I forgot that the duration length isn't available: https://stackoverflow.com/questions/48034091/ff-replay-substructure-in-ff-effect-empty
But I could lower the duration to a maximum of about 33 seconds, so in the worst case the gamepad would rumble for this long when a package gets lost. Btw,... I am not sure why those packages aren't retransmitted if they get lost. Should dig a bit deeper into the BT stack. I guess that this is caused by the missing ERTM functionality of the gamepad

It would be interesting if the same connection issues show up in Windows too, if not it is most probably a faulty chipset driver - which we should be able to fix somehow.

[ugly95]

I updated the list, thank you for clarifying and the update!

What I can offer you is to change the rumble duration, at the moment we are sending rumble messages to the gamepad which let it rumble as long as possible (~10 minutes) until another message is sent which stops rumbling. So I guess that this message gets lost sometimes which causes the gamepad to rumble the whole 10 minutes. I forgot that the duration length isn't available: https://stackoverflow.com/questions/48034091/ff-replay-substructure-in-ff-effect-empty
But I could lower the duration to a maximum of about 33 seconds, so in the worst case the gamepad would rumble for this long when a package gets lost. Btw,... I am not sure why those packages aren't retransmitted if they get lost. Should dig a bit deeper into the BT stack. I guess that this is caused by the missing ERTM functionality of the gamepad

It would be interesting if the same connection issues show up in Windows too, if not it is most probably a faulty chipset driver - which we should be able to fix somehow.

I haven't tested much in Windows. I tested the CSR chipsets for the initial connection on Windows and they seemed to connect reliably. So that one was a Linux-only issue for me.

I did not test my Broadcom chipset in Windows. I did find this Bluetooth firmware repository. But when I tried it, I didn't notice any difference.

I did send you one of each (the Miatone for CSR and the Plugable for Broadcom). So when the package gets there you'll have both to play around with if you feel like it.

[atar-axis]

Hey @ugly95!
Thank you very much again!

I have read on the Amazon product page of that plugable stick that a common cause for a laggy connection is using a USB 3.0 port, due to interference. Is this something you have known (and avoided)?

[ugly95]

Yeah, the USB 3.0 port issue is something that is often mentioned with all the USB Bluetooth dongles. I just double-checked, and I am not using a 3.0 port.

[Miss-Inputs]

Well, I guess here's what I've been using, if it helps:
Targus BT 4.0 USB adapter

How reliable is the connection? I have had it stop responding at a few points, but I have a feeling that's not the adapter's fault and is more likely because I live in a crappy apartment with lots of wireless interference, because other non-Bluetooth devices are sometimes misbehaving too in here. I'll update this later since I'm moving soon. Other than that, it always connects successfully and all that, so it does seem to work well under Linux.
The output of lsusb | grep -i 'blue': Bus 001 Device 005: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
The Chipset (if you know)- I guess it's Broadcom BCM20702A0
where to buy it: In Australia it is available at JB Hifi and Officeworks, not sure about online or other countries

[atar-axis]

Thanks Megan!

[Ktysai]

Is not actually an dongle but it was the single solution for Xbox One BT gamepad that worked on Raspberry Pi 3 model B, using Ubuntu Mate 16.04.

Good job!

[Thomseeen]

Not a dongle but the
Ziyituod PCIe WLAN-Karte, Bluetooth 5.0 AC 1730 Mbit / s Wireless PCI Express-Netzwerkadapter, WLAN-Karte, Wireless PCI-e-Karte für den Desktop, Unterstützung für Windows 10
WiFi and Bluetooth card works perfectly without any connection interrupts. lsusb lists the card as 8087:0025 Intel Corp. and it's based on the Intel® Wireless-AC 9260 as far as I know.
Thanks for helping me with two installations, where I couldn't get my controller to work without your driver!

[Lucki]

• tinxi® Bluetooth 4.0 USB Adapter Dongle
  • Chipset CSR 8510 A10
  • ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
  • Performance:
    • Initial Connection problems
    • Reliable once connected

---

Take the performance notes above with a bit of salt. Right now I can't reproduce the initial connection problems anymore but I keep it that way because I had them and the chipset is the same as the other ones.
Also this dongles performance is heavily based on the USB port used, which can be likely caused by my motherboard:

• The dongle doesn't work on USB3, it gets recognized as Bluetooth dongle but there's no Bluetooth coming out of it.
• When using the dongle on my USB2-Hub the controller "looses" connection with the dongle after some time. It's not really a lost connection as both devices stay "connected" but there's no information exchanged when examined with Wireshark.
• Using the dongle with an USB2 port in my pc case the connection stays all the time.

[udf]

• CSR 4.0 dongle from a corner store (no idea where you can buy this one, it came in a unbranded ziplock bag) image 1 image 2 (the body looks similar to the "Yizhet USB nano Bluetooth 4.0 Adapter" mentioned above)

  • Chipset CSR ??? (how do I figure this out, lsusb doesn't give any more info?)
  • ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
  • Performance:
    • Initial Connection problems when connecting manually**
    • Somewhat reliable once connected

---

• **Running connect <mac> from bluetoothctl takes a while and sometimes fails, however turning on scanning (scan on) and then powering on the xbox controller connects instantly (after pairing and trusting, of course).

• I get a similar "lost" connection behaviour to what @Lucki describes on my front USB 3.0 ports and some of my back USB 2.0 ports (though I haven't tried them all, I'll test and report later).

[deathxxx123]

https://www.ebay.com/itm/Mini-Wireless-USB-Bluetooth-4-0-Adapter-Dongle-For-PC-Laptop-Win-XP-Vista7-8-10-/223694285836 Unbrand There is video of this Dongle https://youtu.be/CfqN6aA_8mE
And
https://www.aliexpress.com/item/32817164732.html Rocketek RT-BT4B
Chipset: BlueCore® CSR8510™ A10 WLCSP
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

Performance:

• Initial Connection problems (Auto-connect really fast during boot PC, if that matter)

• Reliable once connected (Update:1 disconnect after like 50 hours play, reconnect for 15sec)

  Link Quality:

• Link quality at 1 mether, no obstacle: 254 (255 max)

• Link quality at 4 mether, behind 1 wall: 206 (255 max)

• Link quality at 5 mether, behind 2 walls: connection lost

  About Xbox One S controller (model 1708) hardware:

• Chipset: MediaTek (Helio G70/P70 ?)

• Bluetooth version: 4.2

• Wireless features: ?

Both USB dongles are with same chipset, and works in same way. Most of times will connect after 5-10seconds, sometime almost instant, but after connect works absolutely great with no drops and no reconnections.

I use Ubuntu 18.04.3 64bit, Steam and stand alone games. All installed on Samsung 950 Pro.
I only install XPADNEO and reboot. All works without problems. And because i have other controller too (Logitech F710), the Logitech is faster, more precise analogs, connect instantly and feels better when rumble, but have drop connection problems with Linux and Windows. For that i got Xbox One S - Sport White (model: 1708) controller. Maybe i should update controller firmware to get faster connections?

Used commands to check features:
Link quality check: sudo hcitool lq controller_hardware_adress
Get info about connected hardware: hcitool info controller_hardware_adress

[deathxxx123]

Very soon will write review for BT 5. It's Intel® Wireless-AC 9260 Wi-fi + BT 5 combo on desktop. It cost's me around 35$.

[udf]

• Gigabyte WB1733D (pcie, not usb*)

  • Chipset Intel Corporation Wireless-AC 9260 (rev 29)
  • Performance:
    • Bluetooth works perfectly (WiFi has working monitor mode and packet injection if you need that)

• The Bluetooth requires you to plug in the included internal USB (9 pin) cable, or to run a male-to-male USB-A cable from the USB port on the card.

The mPCIe module is easily removable if you want to replace it with something else.

[mmitchell558]

For those who this solution didn't work out for you try this:
I'm on Fedora 31 and this worked for me:

sudo dnf install sysfsutils
sudo bash -c "echo 1 > /sys/module/bluetooth/parameters/disable_ertm"

I have a generic Bluetooth adaptor and i got my controller working.

[deathxxx123]

* [Gigabyte WB1733D](https://www.amazon.co.uk/Gigabyte-WB1733D-I-1733Mbps-Express-Adapter/dp/B07FBSV1XZ) (pcie, not usb*)
  
  * Chipset `Intel Corporation Wireless-AC 9260 (rev 29)`
  * Performance:
    
    * Bluetooth works perfectly (WiFi has working monitor mode and packet injection if you need that)

* The Bluetooth requires you to plug in the included internal USB (9 pin) cable, or to run a male-to-male USB-A cable from the USB port on the card.

The mPCIe module is easily removable if you want to replace it with something else.

I confirm this is perfectly working combination:
PCIe 1X Adapter: NGFF Wireless Card To PCIe 1X 8X 16X Desktop WIFI WLAN CARD bracket Tray Adapter

The Intel® Wireless-AC 9260 chip: Intel 9260NGW WiFi Card NGFF Dual Band 802.11ac 1730Mbps MU-MIMO Bluetooth 5.0
https://www.ebay.com/itm/Intel-9260-wireless-card-Dual-Band-802-11ac-1730Mbps-MU-MIMO-Bluetooth-5-0-NGFF/283452319619

[l0b0]

Please ignore the below, it was caused by ControllerMode = bredr.

---

Original post:

tl;dr: Linux does not detect my X-Box model 1914 controller with Targus dongle.

My system:

• New X-Box model 1914 controller with original firmware and new batteries.

• Up-to-date Arch Linux with vanilla kernel:

  $ uname --kernel-name --kernel-release --kernel-version --machine --operating-system
  Linux 5.10.9-arch1-1 #1 SMP PREEMPT Tue, 19 Jan 2021 22:06:06 +0000 x86_64 GNU/Linux
  

• Targus-branded Broadcom USB Bluetooth dongle:

  $ lsusb | grep -i bluetooth
  Bus 001 Device 004: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
  Bus 001 Device 005: ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP)
  

What I've done:

1. Installed latest xpadneo driver as of 2021-01-24:

   $ pacman --query xpadneo-dkms-git 
   xpadneo-dkms-git 0.9.r16.g2850d4d-1
   

2. Installed latest firmware for the Bluetooth dongle:

   $ pacman --query broadcom-bt-firmware-git 
   broadcom-bt-firmware-git 12.0.1.1105_p3.r0.g68a7a8a-1
   

3. Disabled Enhanced ReTransmission Mode:

   $ cat /sys/module/bluetooth/parameters/disable_ertm
   Y
   

4. Rebooted, after which dmesg showed that the firmware was updated:

   $ sudo dmesg --notime | grep BCM20702A
   Bluetooth: hci0: BCM20702A1 (001.002.014) build 1764
   Bluetooth: hci0: BCM20702A1 'brcm/BCM20702A1-0a5c-21e8.hcd' Patch
   Bluetooth: hci0: BCM20702A1 (001.002.014) build 1764
   

5. Manually loaded the xpadneo kernel driver:

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

6. Powered on the X-Box controller and enabled Bluetooth discovery mode (the "X" icon on the controller is blinking more quickly than when it powered on).

7. Did a Bluetooth scan & device listing with bluetoothctl.

What I was expecting to happen: The controller should show up in the device listing after scanning for a while.

What actually happened: The controller does not show up, even though three other devices do show up.

The same goes for the GNOME Bluetooth setting dialogue: other devices show up, but not the X-Box controller.

Crosspost on Unix Stack Exchange

[kakra]

Please ignore the below, it was caused by ControllerMode = bredr.

Interesting... Where is this setting?

Edit: Found it...

[tbehan]

• Controller: Xbox One Core Controller - Carbon Black
  • Model: 1914
• USB Dongle: Mpow Bluetooth 5.0 USB Adapter for PC
  • Model: BH456A
  • Chipset: Realtek Semiconductor Corp. Bluetooth Radio'
• PC Software:
  • Firmware rtl8761bu_fw
  • OS: LinuxMint 20.1 Ulyssa
  • Kernel: 5.8.0-44-generic
  • BlueZ 5.53-0ubuntu3
• Performance:
  • Didn't work initially out of the box, had to pair every time it started up.
  • Then if failed to connect at all.
  • Finally got it work, and it works flawlessly with disable_ertm set to either Y or N

---

Background:

I don't have an xbox I just bought the stand-alone controller and the above USB dongle.

What Didn't Work

I installed the MPOW drivers from their site. And out of the box the controller worked right away, until I turned it off. It would get stuck in the connect / disconnect loop like in #166. I had to pair it every time to make it work. I tried everything to alleviate this. I tried:

• Changing the settings in /etc/bluetooth/main.conf according to this post.
• disable_ertm with both Y and N.
• Compiled/installed bluez-5.55.
• Compiled/installed linux-5.11.0 with the L2CAP patch as per Rumble needs ERTM enabled to work reliably #272.

Nothing worked. And eventually it stopped working altogether, I suspect something was corrupted in the controller because bluez was complaining about reading a configuration map (sorry I didn't save the actual error messages). At this point nothing I did could make it work. So I took it to a win10 machine and tried:

• Connecting via USB-C and updated the controllers drivers (Firmware Version 5.5.2641.0).

Still didn't work.

What Worked

1. Installed a win10 virtual machine and passed the USB dongle to it.
2. From within windows using the same USB dongle I was able to test with the "xbox accessories" application and confirm everything was working.
3. Power off the win10 virtual machine and reconnect to stock LinuxMint 20.1 setup (see above).

Finally it was working! So I tested:

• Power cycling the controller, worked.
• sudo systemctl restart bluetooth, worked
• Reboot computer, worked.
• Unpair and Pair again, worked.
• Unplug and re-plugin the USB dongle, worked.
• Tested with /sys/module/bluetooth/parameters/disable_ertm set to both Y and N, worked.
• Played games for about two hours last night, worked without issue.

In each instance the controller does one flash, then goes solid, rumbles, and is connected.

Conclusion

I spent many, many, hours fighting with the controller and the bluetooth stack to get this thing working. So I'm exceptionally happy that it is working so well now. However I must confess I'm not sure why. I think it maybe something internal to the controller and getting it to pair with the same USB dongle on win10, but without more information from the controller itself it will be difficult to know. So I thought I would document my experiences and pass it along to see if it helps the dev team here.

---

I'm a full-time C programmer (microcontrollers mostly) and I'm available to do some more testing and debugging.

Thank you so much for this xpadneo project!

[kakra]

@tbehan

I think it maybe something internal to the controller and getting it to pair with the same USB dongle on win10

Yeah, I suspect something similar. There seems to be some partially re-used internal state in the controller - which may even be cleaned up when switching between the original Wifi dongle and any Bluetooth dongle. This cleanup is sometimes needed. Other times, it just helps pairing it with Windows or an Android phone once. This is why I'm usually recommending to try pairing the controller to a different device (Windows, Android), different dongle (Bluetooth chipset/MAC), or just with a different mode (Bluetooth vs Wifi), then try again.

ERTM should not be disabled if you're using the L2CAP patch: I found that rumble may crash the gamepad firmware when ERTM is disabled. But without L2CAP patch, the controller doesn't pair with ERTM enabled.

Disassembling the firmware to find out about this buggy/quirky behavior could be an interesting project but I fear information gathered there may not be used for this project. So I'd prefer to never post or refer to any information observed from disassembled firmware blobs. The observed bugs are not uniquely a problem when using the Linux Bluetooth stack, some can also be observed by Windows users, Android users seem fine, tho.

I'm a full-time C programmer (microcontrollers mostly) and I'm available to do some more testing and debugging

This may actually be a useful skill. Are you familiar with the Bluetooth protocol? I think whatever bug we are looking for, we won't find a fix for it in xpadneo itself. Every work-around xpadneo could do is probably already covered. But there may be a bug hiding in Bluez or the kernel, and maybe it can be found by observing and understanding the Bluetooth protocol traces between controller and BT dongle. The original Wifi dongle is a complete different protocol (GIP) which is stable (except for the 100 Hz bug).

Also, I'd like to reverse engineer the profile upload protocol implemented in the Elite 2 or later controllers: All models that expose a HID keyboard via Bluetooth should be able to receive mapping profiles by uploading HID reports (probably op-codes 6, 7, 8, 9, or 10 are involved. With profiles, the controller should be able to act as a keyboard, mapping some buttons or combination of buttons to keyboard events. See also here as a starting point: https://github.com/atar-axis/xpadneo/blob/master/docs/descriptors/xbe2_linux.md

XBE2 supports 4 profiles (where the first seems to be a hard-coded default profile resembling the original mapping only), and the other 3 are custom profiles that can be uploaded into the hardware. The new XBXS controller (with share button) probably supports one profile only as it has no hardware switch with LED indicator for selecting a profile. It probably uses hardware-supported mappings but the profile needs to be uploaded when switched.

I'm planning to implement something similar in software for other models but to do it properly, we'd have to know first how it's implemented in controllers supporting that feature native in hardware.

So you see, there's at least two interesting projects for a low-level C programmer usually talking "microcontrollers". :-)

[kakra]

• Controller: Xbox One Core Controller - Carbon Black

  • Model: 1914

• USB Dongle: Mpow Bluetooth 5.0 USB Adapter for PC

  • Model: BH456A

The first link seems to be wrong...

[kakra]

I think it maybe something internal to the controller and getting it to pair with the same USB dongle on win10

Yeah, I suspect something similar

BTW: I've seen cases with the original Xbox One S controller (the first Bluetooth model) where the controller would suddenly expose a completely different HID protocol/mapping after it was paired with Windows. So there's clearly something quirky inside the firmware.

[tbehan]

@kakra

• Controller: Xbox One Core Controller - Carbon Black

  • Model: 1914

• USB Dongle: Mpow Bluetooth 5.0 USB Adapter for PC

  • Model: BH456A

The first link seems to be wrong...

Fixed.

ERTM should not be disabled if you're using the L2CAP patch: I found that rumble may crash the gamepad firmware when ERTM is disabled. But without L2CAP patch, the controller doesn't pair with ERTM enabled.

That's the thing, I'm not using the L2CAP patch anymore. I reset my system to a stock LinuxMint 20.1 system with a stock kernel.

Kernel / L2CAP Testing

This is what my setup looks like now:

Current Setup 5.8.0-44

$ cat /sys/module/bluetooth/parameters/disable_ertm
N

$ uname -a
Linux minty 5.8.0-44-generic #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

• Autoconnect works.
• Pairing works.

---

So I went back and tried an older kernel just in case I missed my apt-get installing a newer ubuntu kernel which had been patched:

Testing Older Kernel 5.8.0-23

$ cat /sys/module/bluetooth/parameters/disable_ertm
N

$ uname -a
Linux minty 5.8.0-23-generic #24~20.04.1-Ubuntu SMP Sat Oct 10 04:57:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

• Autoconnect works.
• Pairing works.

---

And just to be extra sure I downloaded the vanilla 5.8.0 kernel straight from kernel.org. And made sure that the patch was not in the code (it wasn't). And then tried again:

Testing Vanilla Kernel 5.8.0

$ cat /sys/module/bluetooth/parameters/disable_ertm
N

$ uname -a
Linux minty 5.8.0 #1 SMP Wed Feb 24 21:43:54 EST 2021 x86_64 x86_64 x86_64 GNU/Linux

• Autoconnect works.
• Pairing works.

---

This is bizarre because it 100% was not working at all before. And I know I was getting warnings about L2CAP in one of the logs I was looking at.

When it wasn't working for me I tried updating the firmware and that didn't work. So then I tried pairing with windows and the dongle, then switching both back to Linux. Only at that point did it start working properly.

My theory is that my controller was having two problems: 1) the L2CAP issue and 2) a corrupted internal state. Upgrading the firmware on my controller fixed 1, and pairing with windows fixed 2. Looking at the patch from #272 all it does is handle the L2CAP_CONF_UNKNOWN case. If the new controller firmware fixed its internal bluetooth code so that it is sending properly formatted L2CAP then L2CAP_CONF_UNKNOWN would never happen, and then the patch is no longer needed.

Unfortunately I never tried pairing with windows before doing the controller firmware update. So it could be that just the windows pairing alone would have fixed it. I would have to rollback the controller firmware to test. If you know of a way to do that please let me know.

This may actually be a useful skill. Are you familiar with the Bluetooth protocol?

No sorry, somehow I've managed to never have a project with either bluetooth or zigbee. But I have played around with Linux kernel drivers a little bit here and there.

Also, I'd like to reverse engineer the profile upload protocol implemented in the Elite 2 or later controllers: All models that expose a HID keyboard via Bluetooth should be able to receive mapping profiles by uploading HID reports

Interesting. Like I said I don't have bluetooth experience, nor am I familiar with controllers. I was exclusively a mouse+keyboard player until two weeks ago and I still don't actually have a console. But if I have some time this weekend I'll do some reading up on it. I'm curious about getting the battery state readings to work, and from what I've seen so far that seems like something that would need to fixed in BlueZ.

Let me know if you want me to test some other configurations.

EDIT: I'm not getting battery error messages from bluez anymore and it looks like the battery stuff is working fine already.

[kakra]

My theory is that my controller was having two problems: 1) the L2CAP issue and 2) a corrupted internal state. Upgrading the firmware on my controller fixed 1, and pairing with windows fixed 2.

Matches my theory. And fits observations. But 1 is probably just fixed because a link key was already present. Without ERTM, you'll have a hard time getting the link key negotiated. Once that's stored in the Bluetooth service, successive connects will work.

Looking at the patch from #272 all it does is handle the L2CAP_CONF_UNKNOWN case. If the new controller firmware fixed its internal bluetooth code so that it is sending properly formatted L2CAP then L2CAP_CONF_UNKNOWN would never happen, and then the patch is no longer needed.

Well, I think sending CONF_UNKNOWN would be a valid reply that should be handled in the host side implementation. It's probably not fully correct to use the same code path as the other L2CAP reply but for the moment it works. But I agree that it shows the gamepad having an incomplete implementation - but it may be sufficient for what it does, so it's probably not broken in that regard. But the gamepad firmware seems to do a lot more shortcuts in other places, leading to situations of internal broken or incomplete state. There are also race conditions when sending rumble data faster than 100 Hz, or when sending rumble data at all with ERTM disabled. It seems the gamepad expects some level of implementation details of the host side without ever checking if that is really true, while it takes some shortcuts itself by omitting some implementation details. I think that can be called broken.

I'm curious about getting the battery state readings to work, and from what I've seen so far that seems like something that would need to fixed in BlueZ.

The battery reports are actually embedded in the HID protocol, there should be nothing about it that is handled by the Bluetooth stack. It's report 0x04. But that is not hard-coded, we actually detect it during descriptor parsing when the kernel passes the battery HID report descriptor to us. The driver stores the ID, and later when a report comes in, we actually handle the report parsing ourselves and stop the kernel from using its own battery parsing implementation. We do this because the battery reports are malformed: The descriptor says the payload has a level value of 0-255 but that is not true. The payload is actually a 2 bit level value and some status bits.

Once the first battery report is received, we register a power interface with the kernel to report the battery level. We don't do that earlier because we cannot poll the battery, and GUIs do not handle an unknown battery state very well. So unless the gamepad sent the first battery report, there won't be a battery associated in the Linux power management. But later there will, and it should work.

In dmesg it looks like this:

[34838.468557] xpadneo 0005:045E:02FD.0016: battery detected
...
[34839.460277] xpadneo 0005:045E:02FD.0016: Xbox Wireless Controller [c8:3f:26:a9:2d:6c] connected
[34839.990682] xpadneo 0005:045E:02FD.0016: battery registered

And then it shows up in upower -d:

Device: /org/freedesktop/UPower/devices/gaming_input_xpadneo_battery_0
  native-path:          xpadneo_battery_0
  model:                Xbox Wireless Controller [c8:3f:26:a9:2d:6c]
  power supply:         no
  updated:              Do 25 Feb 2021 07:41:12 CET (47 seconds ago)
  has history:          yes
  has statistics:       yes
  gaming-input
    rechargeable:        yes
    warning-level:       none
    battery-level:       normal
    percentage:          55% (should be ignored)
    icon-name:          'battery-low-symbolic'
  History (charge):
    1614235272  55,000  discharging
    1614235272  0,000   unknown
  History (rate):
    1614235272  0,000   unknown

EDIT: I'm not getting battery error messages from bluez anymore and it looks like the battery stuff is working fine already.

Maybe with your previous setup/situation, the kernel was never able to receive a battery report.

[tbehan]

The battery reports are actually embedded in the HID protocol, there should be nothing about it that is handled by the Bluetooth stack.

In my case I'm actually getting the battery information from bluez, not xpadneo. This is what my upower -d output looks like:

$ upower -d
Device: /org/freedesktop/UPower/devices/mouse_hidpp_battery_0
  native-path:          hidpp_battery_0
  model:                M720 Triathlon Multi-Device Mouse
  serial:               405e-c2-6d-5e-d8
  power supply:         no
  updated:              2021-02-25T16:40:22 EST (15 seconds ago)
  has history:          yes
  has statistics:       yes
  mouse
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    battery-level:       normal
    percentage:          55% (should be ignored)
    icon-name:          'battery-low-symbolic'

Device: /org/freedesktop/UPower/devices/gaming_input_dev_98_7A_14_D7_EC_B0
  native-path:          /org/bluez/hci0/dev_98_7A_14_D7_EC_B0
  model:                Xbox Wireless Controller 987A14D7ECB0
  serial:               98:7A:14:D7:EC:B0
  power supply:         no
  updated:              1969-12-31T19:00:00 EST (1614289237 seconds ago)
  has history:          yes
  has statistics:       no
  gaming-input
    rechargeable:        no
    warning-level:       none
    percentage:          86%
    icon-name:          'battery-missing-symbolic'

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply:         no
  updated:              2021-02-24T23:25:53 EST (62084 seconds ago)
  has history:          no
  has statistics:       no
  unknown
    warning-level:       none
    icon-name:          'battery-missing-symbolic'

Daemon:
  daemon-version:  0.99.11
  on-battery:      no
  lid-is-closed:   no
  lid-is-present:  no
  critical-action: HybridSleep

Note that the data is coming from /org/bluez and I'm not getting anything from xpadneo_battery_0. If I run If I run dmesg | grep xpadneo | grep battery I get nothing. And if I turn on debugging for BlueZ this is what it looks like:

$ sudo bluetoothd -d -n
bluetoothd[41400]: Bluetooth daemon 5.53
bluetoothd[41400]: src/main.c:parse_config() parsing /etc/bluetooth/main.conf
{ ... }
bluetoothd[41400]: profiles/battery/battery.c:parse_battery_level() Battery Level updated: 50%
bluetoothd[41400]: profiles/battery/battery.c:batt_io_ccc_written_cb() Battery Level: notification enabled
bluetoothd[41400]: profiles/gap/gas.c:read_device_name_cb() GAP Device Name: Xbox Wireless Controller 987A14D7ECB0
{ ... }
bluetoothd[41400]: profiles/battery/battery.c:parse_battery_level() Battery Level updated: 85%

If I swap batteries with a fresh pair the battery level goes to 100%, so it seems accurate to me. In my case I'm using AA batteries not one of the official xbox rechargeable ones. So I wonder if that makes a difference?

[kakra]

I'm using plain AA batteries, too. I never saw bluez showing any battery levels here, nor did anyone else report that. Also, I wonder how accurate those levels really are. I wonder if it uses the same bit format as described here: https://github.com/atar-axis/xpadneo/blob/master/docs/reports/xb1s_battery_event.md

The XBE2 controller has internal rechargeable batteries (and comes with a docking station case, too), I've neither seen bluez reporting a battery there.

Which bluez version are you using? Maybe that's a distribution patch?

[tbehan]

My bluez is version 5.53, I also downloaded and compiled the stock version 5.55 and got the same result.

As for the accuracy it seems fairly accurate so far. The batteries I was using yesterday dropped from 85% to 84% just from a few minutes of playing around with the Bluetooth connections yesterday. And when I put in fresh batteries it reads 100%. The weekend is here now so hopefully I'll get some gaming in :). I'll see how it looks after a few hours of usage.

[sergiogarciadev]

Realtek Semiconductor Corp.

ORICO BTA-508 Bluetooth 5.0 USB adapter with Kernel 5.8

• Chipset: RTL8761B
• ID 0bda:8771 Realtek Semiconductor Corp. Bluetooth Radio
• OS: Ubuntu 20.04
• Kernel: 5.8.0-50-generic
• BlueZ: 5.53-0ubuntu3.1
• Controller: Xbox One Series Controller (Model: 1914)
• Performance:

Dongle is not recognized by default, need to use install its driver and Orico doesn't provide one. I got driver from Mpow BH519A and correct firmware.

If you don't have rtl8761b_fw.bin in your system, the rtl8761a_fw.bin it will get loaded, this firmware causes bluetoothd to crash in many situations (connecting, paring) with this dongle.

It may enter in a loop pairing or connecting after pairing, in this case remove device, restart bluetooth service and try again. After it connects and the xbox logo on controller stop flashing and keeps on, the connection is stable.

The /etc/bluetooth.conf setting for ControlMode and Privacy doesn't change the pairing issue, neither trusting the device.

---

ORICO BTA-508 Bluetooth 5.0 USB adapter with Kernel 5.11

• Chipset: RTL8761B
• ID 0bda:8771 Realtek Semiconductor Corp. Bluetooth Radio
• OS: Ubuntu 21.04
• Kernel: 5.11.0-17-generic
• BlueZ: 5.56-0ubuntu4
• Controller: Xbox One Series Controller (Model: 1914)
• Performance: No issues found

I will update this with future information, after more tests.

[kakra]

Kernel 5.8 is quite ancient in terms of Bluetooth. Kernel 5.9 added a lot of quirk handling for many Bluetooth dongles. Are you able to try a newer kernel, maybe 5.10 at least because that is an LTS kernel?

[sergiogarciadev]

Kernel 5.8 is quite ancient in terms of Bluetooth. Kernel 5.9 added a lot of quirk handling for many Bluetooth dongles. Are you able to try a newer kernel, maybe 5.10 at least because that is an LTS kernel?

I will try later with a fresh install, this is my main machine and I can't upgrade yet.

[pedrovanzella]

Using a PCIe WiFi / BT (though it connects through a USB header on the motherboard) with an Intel AX210 chipset. Works with my Elite Series 2 out of the box on kernel 5.14, though Bluetooth dies on reboot. One needs to completely power cycle the computer to get BT back.

No performance issues so far.

[Da-Boom]

Not Working Device

https://www.ebay.com.au/itm/303605520995
Chipset: CSR 8510-A10 (Unbranded Knockoff lsusb -v lists iProduct 2 BT DONGLE10 and iManufacturer 0)
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

• Does not get recognised at all (bluetoothctl lists no default device)
• Supposedly would work with a kernel patch - don't have the knowhow to do this, its a long process

[SomebodyDoe]

Here are my experiences

My System: OpenSUSE Tumbleweed with Gnome 41.1, BlueZ 5.62 and xpadneo-kmp-default 0.9.1. I use the "XBOX Wireless Controller" (Series S/X) (QAT-00002, MODEL NO: 1914).

I tested xpadneo with two BT USB dongles:

1. Vivanco USB Bluetooth 4.0 Dongle 30447
   (Broadcom BCM20702)
   Bus 001 Device 003: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
   Vivanco changed design of the dongle since I bought it. But they kept the model number (30447). The old generation has three little fins at the side. Can't tell, if Vivanco switched the OEM and if the dongle uses now a different chip.
   Here is a picture of the old design:
   https://web.archive.org/web/20211114192752/https://www.vivancotrade.co.uk/wp-content/uploads/2017/03/30447.jpg

2. Logilink USB Bluetooth 4.0 Dongle BT0015
   (Cambridge Silicon Radio CSR8510 A10)
   Bus 001 Device 009: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
   Stores:
   https://geizhals.de/logilink-bt0015-a1046240.html

The gamepad works with both dongles, if they got connected with a Win system on the same machine before pairing with Linux.
Otherwise the gamepad runs a reconnection loop or immediately disconnects.
Connecting the gamepad with my Android phone breaks the pairing with Linux and I have to pair the pad with Win again.
I had no reconnection issues with the CSR dongle. I felt no lag with the broadcom dongle (but I'm not playing quick action games).

[KarlK90]

Working Setup

After the taking the steps below works absolutely flawless, pairing works out of the box with the integrated Gnome Bluetooth manager.

• OS: Ubuntu 21.10
• Shell: Gnome 40
• Kernel: Xanmod Edge 5.15.6-xanmod2
• Chipset: Intel Wireless AC 9260
• Bluez 5.60
• xpadneo @ 64e6a27

Steps

Update controllers via Windows Dev Machine running in Virtual Box

1. Make sure you are in the right group sudo adduser $USER vboxusers
2. Have all Virtual Box Guest extensions on the host and machine installed
3. Inside the VM get the Xbox Accessories app
4. Connect controller via USB cable
5. Connect controller in Virtual Box to the VM
6. Open the Xbox Accessories
7. Press the Xbox button on the controller to power it up
8. Wait until the controller is recognized and click on the update button and start the update
9. There is a progress bar and the controller will "reboot" several times, this disconnects the controller from the VM as well and the update progress shows "failed update".
10. Exit the update progress and unplug the controller so it is powered off.
11. Repeat from step 4. until the progress bar reached its end.

Update /etc/bluetooth/main.conf

1. Add this block taken from here to /etc/bluetooth/main.conf

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

Just connect via the Gnome built-in Bluetooth manager and enjoy

[deathxxx123]

AMD RZ608 Wi-Fi 6E module (rebranded MediaTek MT7921K) and Bluetooth 5.2 combo.
That come with MB: Gigabyte X570S AORUS ELITE AX
And AYANEO
https://www.anandtech.com/show/16666/amd-wifi-6e-rz608

The MB:
https://www.gigabyte.com/Motherboard/X570S-AORUS-ELITE-AX-rev-11/sp#sp

Connection is very good and i do not see any problems, actually MB comes with Wi-fi and BT antenna and maybe this is ultimate BT combo for wireless Xbox One S controller.

Distro tested:
Pop!_OS 22.04 LTS
Manjaro Gnome with lastest updates.

It's working out from box and with xpadneo too.

[mscharley]

I've had my dongle for a while and it's worked fine for the little bits of bluetooth I've needed in the past. I've just tested it with xpadneo for a few hours of gaming and no dropouts or other issues so far.

I got it here: https://www.mwave.com.au/product/simplecom-nb409-bluetooth-50-usb-wireless-dongle-with-a2dp-edr-ac38550

Branding: Simplecom NB409 Bluetooth 5.0 USB Wireless Dongle with A2DP EDR
I'm not sure what chipset it is exactly, but probably some really common off the shelf thing because someone else reported the same USB id above with completely different branding.

lsusb: ID 0bda:8771 Realtek Semiconductor Corp. Bluetooth Radio

Unlike the previous report, it's worked straight out of the box for me on Manjaro KDE with kernel 5.15 and 6.1. I had to manually install xpadneo, the AUR package didn't work for me (DKMS in both cases). Other than that, so far so good. I did update the firmware of the controller via windows as a debugging step while still on the broken AUR package, but even with the AUR package the bluetooth was pairing fine, i just wasn't getting the rumble.

[kakra]

Please add new issues for reporting working setups and don't make this an endless mega issue. Thanks. :-)