search

atar-axis / xpadneo

Advanced Linux Driver for Xbox One Wireless Controller (shipped with Xbox One S)
https://atar-axis.github.io/xpadneo/
GNU General Public License v3.0
1.96k stars 112 forks source link

List of USB BT sticks (add to README) #93

Closed atar-axis closed 5 years ago

atar-axis commented 5 years ago

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

Cambridge Silicon Radio

Broadcom

TobiPeterG commented 5 years ago

Unreliable device:

ugly95 commented 5 years ago

Unreliable device:

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

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

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

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

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

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

Thanks Megan!

Ktysai commented 5 years ago

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

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

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:

udf commented 4 years ago
deathxxx123 commented 4 years ago

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:

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

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

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

mmitchell558 commented 4 years ago

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

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:

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

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

Interesting... Where is this setting?

Edit: Found it...

tbehan commented 3 years ago

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:

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:

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:

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

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

The first link seems to be wrong...

kakra commented 3 years ago

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

@kakra

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

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

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

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

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

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

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

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

Realtek Semiconductor Corp.

ORICO BTA-508 Bluetooth 5.0 USB adapter with Kernel 5.8

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

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

kakra commented 3 years ago

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

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

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

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)

SomebodyDoe commented 2 years ago

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

Working Setup

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

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".
    1. Exit the update progress and unplug the controller so it is powered off.
    2. 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 commented 2 years ago

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 km1mwurmwo4rx0p656iw_575px

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 commented 1 year ago

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 commented 1 year ago

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