kakra
commented
1 year ago Does this happen when rumble is involved?
Closed kode54 closed 4 months ago
kakra
commented
1 year ago Does this happen when rumble is involved?
bezirg
commented
1 year ago I have also disconnects happening randomly after some minutes. The controller is disconnected and immediately reconnected by doing the "welcome rumble" dance.
It seems to happen consistently on one of the 2 series s controllers when both are connected which make me think that it might be a gamepad issue.
If it is not the gamepad's fault then it could be also my hci0 controller's fault. I am saying that because I had previously other bluetooth problems with my hci0 controller (wifi ax200).
kakra
commented
1 year ago The AX200 is known to have problems with this controller. Maybe we should add Lite-On to this list.
Overflwn
commented
11 months ago Sorry for necro'ing this issue, didn't know if I really should open a new (similar) one
I also have the same problem with my Series X controller and a TP-Link UB500 dongle. The controller keeps getting disconnected after some time between 1-15 minutes and immediately reconnects with the init rumble. I'm only using it while playing Steam games and at least these games recognize the re-connection and I can continue playing after waiting for the reconnect.
xpadneo-dkms-git (0.9.r144.g9b3b696-1) Archlinux 7.4.7-arch1-3
Don't know how to check what exact firmware my controller has installed, however, last time I updated was approx. 2-3 weeks ago, so I guess it should be the newest firmware available..
Dmesg log (here I connected the controller after booting, which got re-connected at approx 130.8 and then it re-connected again at about 280.0):
[ 8.008364] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 8.008366] Bluetooth: BNEP filters: protocol multicast
[ 8.008368] Bluetooth: BNEP socket layer initialized
[ 8.008834] Bluetooth: MGMT ver 1.22
[ 8.014114] NET: Registered PF_ALG protocol family
[ 8.076898] RTL8226B_RTL8221B 2.5Gbps PHY r8169-0-2a00:00: attached PHY driver (mii_bus:phy_addr=r8169-0-2a00:00, irq=MAC)
[ 8.163482] Bluetooth: hci0: Bad flag given (0x1) vs supported (0x0)
[ 8.273978] r8169 0000:2a:00.0 enp42s0: Link is Down
[ 8.300227] Generic FE-GE Realtek PHY r8169-0-400:00: attached PHY driver (mii_bus:phy_addr=r8169-0-400:00, irq=MAC)
[ 8.490358] r8169 0000:04:00.0 enp4s0: Link is Down
[ 8.544757] userif-4: sent link down event.
[ 8.544760] userif-4: sent link up event.
[ 9.486995] userif-4: sent link down event.
[ 9.486999] userif-4: sent link up event.
[ 10.823730] IPv6: ADDRCONF(NETDEV_CHANGE): enp42s0: link becomes ready
[ 10.823818] r8169 0000:2a:00.0 enp42s0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 11.023842] userif-4: sent link down event.
[ 11.023846] userif-4: sent link up event.
[ 11.254477] memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=965 'Xorg'
[ 12.568736] rfkill: input handler disabled
[ 13.417079] Bluetooth: RFCOMM TTY layer initialized
[ 13.417086] Bluetooth: RFCOMM socket layer initialized
[ 13.417087] Bluetooth: RFCOMM ver 1.11
[ 21.002697] logitech-hidpp-device 0003:046D:4074.0009: HID++ 4.2 device connected.
[ 24.707696] systemd-journald[338]: File /var/log/journal/b04f138d26264ec68ce4ea2d7b7077ef/user-1000.journal corrupted or uncleanly shut down, renaming and replacing.
[ 25.191957] rfkill: input handler enabled
[ 26.765962] rfkill: input handler disabled
[ 32.910751] input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.000A/input/input30
[ 32.910863] hid-generic 0005:045E:0B13.000A: input,hidraw9: BLUETOOTH HID v5.17 Gamepad [Xbox Wireless Controller] on e8:48:b8:c8:20:00
[ 32.919426] loaded hid-xpadneo 0.9.r144.g9b3b696
[ 33.000704] xpadneo 0005:045E:0B13.000A: BLE firmware version 5.17
[ 33.000709] xpadneo 0005:045E:0B13.000A: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x028E)
[ 33.000710] xpadneo 0005:045E:0B13.000A: working around wrong SDL2 mappings (changed version from 0x00000517 to 0x00001130)
[ 33.000712] xpadneo 0005:045E:0B13.000A: report descriptor size: 283 bytes
[ 33.000713] xpadneo 0005:045E:0B13.000A: fixing up Rx axis
[ 33.000714] xpadneo 0005:045E:0B13.000A: fixing up Ry axis
[ 33.000715] xpadneo 0005:045E:0B13.000A: fixing up Z axis
[ 33.000715] xpadneo 0005:045E:0B13.000A: fixing up Rz axis
[ 33.000716] xpadneo 0005:045E:0B13.000A: fixing up button mapping
[ 33.000786] xpadneo 0005:045E:0B13.000A: gamepad detected
[ 33.000787] xpadneo 0005:045E:0B13.000A: enabling compliance with Linux Gamepad Specification
[ 33.000812] input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.000A/input/input31
[ 33.000889] xpadneo 0005:045E:0B13.000A: input,hidraw9: BLUETOOTH HID v11.30 Gamepad [Xbox Wireless Controller] on e8:48:b8:c8:20:00
[ 33.000908] input: Xbox Wireless Controller Consumer Control as /devices/virtual/misc/uhid/0005:045E:0B13.000A/input/input32
[ 33.000928] xpadneo 0005:045E:0B13.000A: consumer control added
[ 33.000945] input: Xbox Wireless Controller Keyboard as /devices/virtual/misc/uhid/0005:045E:0B13.000A/input/input33
[ 33.000965] xpadneo 0005:045E:0B13.000A: keyboard added
[ 33.000967] xpadneo 0005:045E:0B13.000A: controller quirks: 0x00000050
[ 33.000968] xpadneo xpadneo_welcome_rumble start
[ 33.991677] xpadneo xpadneo_welcome_rumble took 990ms
[ 33.991680] xpadneo 0005:045E:0B13.000A: Xbox Wireless Controller [44:16:22:d5:6f:ad] connected
[ 34.041149] xpadneo 0005:045E:0B13.000A: reverting to original version (changed version from 0x00001130 to 0x00000517)
[ 34.041154] xpadneo 0005:045E:0B13.000A: reverting to original product (changed PID from 0x028E to 0x0B13)
[ 34.160599] xpadneo 0005:045E:0B13.000A: BLE firmware version 5.17
[ 34.160603] xpadneo 0005:045E:0B13.000A: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x028E)
[ 34.160605] xpadneo 0005:045E:0B13.000A: working around wrong SDL2 mappings (changed version from 0x00000517 to 0x00001130)
[ 34.160607] xpadneo 0005:045E:0B13.000A: report descriptor size: 283 bytes
[ 34.160608] xpadneo 0005:045E:0B13.000A: fixing up Rx axis
[ 34.160608] xpadneo 0005:045E:0B13.000A: fixing up Ry axis
[ 34.160609] xpadneo 0005:045E:0B13.000A: fixing up Z axis
[ 34.160609] xpadneo 0005:045E:0B13.000A: fixing up Rz axis
[ 34.160610] xpadneo 0005:045E:0B13.000A: fixing up button mapping
[ 34.160676] xpadneo 0005:045E:0B13.000A: gamepad detected
[ 34.160677] xpadneo 0005:045E:0B13.000A: enabling compliance with Linux Gamepad Specification
[ 34.160698] input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.000A/input/input34
[ 34.160792] xpadneo 0005:045E:0B13.000A: input,hidraw9: BLUETOOTH HID v11.30 Gamepad [Xbox Wireless Controller] on e8:48:b8:c8:20:00
[ 34.160808] input: Xbox Wireless Controller Consumer Control as /devices/virtual/misc/uhid/0005:045E:0B13.000A/input/input35
[ 34.160823] xpadneo 0005:045E:0B13.000A: consumer control added
[ 34.160836] input: Xbox Wireless Controller Keyboard as /devices/virtual/misc/uhid/0005:045E:0B13.000A/input/input36
[ 34.160852] xpadneo 0005:045E:0B13.000A: keyboard added
[ 34.160854] xpadneo 0005:045E:0B13.000A: controller quirks: 0x00000050
[ 34.160855] xpadneo xpadneo_welcome_rumble start
[ 35.151572] xpadneo xpadneo_welcome_rumble took 990ms
[ 35.151574] xpadneo 0005:045E:0B13.000A: Xbox Wireless Controller [44:16:22:d5:6f:ad] connected
[ 130.858072] xpadneo 0005:045E:0B13.000A: reverting to original version (changed version from 0x00001130 to 0x00000517)
[ 130.858077] xpadneo 0005:045E:0B13.000A: reverting to original product (changed PID from 0x028E to 0x0B13)
[ 134.359713] xpadneo 0005:045E:0B13.000B: BLE firmware version 5.17
[ 134.359717] xpadneo 0005:045E:0B13.000B: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x028E)
[ 134.359719] xpadneo 0005:045E:0B13.000B: working around wrong SDL2 mappings (changed version from 0x00000517 to 0x00001130)
[ 134.359720] xpadneo 0005:045E:0B13.000B: report descriptor size: 283 bytes
[ 134.359721] xpadneo 0005:045E:0B13.000B: fixing up Rx axis
[ 134.359722] xpadneo 0005:045E:0B13.000B: fixing up Ry axis
[ 134.359723] xpadneo 0005:045E:0B13.000B: fixing up Z axis
[ 134.359723] xpadneo 0005:045E:0B13.000B: fixing up Rz axis
[ 134.359724] xpadneo 0005:045E:0B13.000B: fixing up button mapping
[ 134.359781] xpadneo 0005:045E:0B13.000B: gamepad detected
[ 134.359781] xpadneo 0005:045E:0B13.000B: enabling compliance with Linux Gamepad Specification
[ 134.359811] input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.000B/input/input37
[ 134.359899] xpadneo 0005:045E:0B13.000B: input,hidraw9: BLUETOOTH HID v11.30 Gamepad [Xbox Wireless Controller] on e8:48:b8:c8:20:00
[ 134.359918] input: Xbox Wireless Controller Consumer Control as /devices/virtual/misc/uhid/0005:045E:0B13.000B/input/input38
[ 134.359934] xpadneo 0005:045E:0B13.000B: consumer control added
[ 134.359950] input: Xbox Wireless Controller Keyboard as /devices/virtual/misc/uhid/0005:045E:0B13.000B/input/input39
[ 134.359966] xpadneo 0005:045E:0B13.000B: keyboard added
[ 134.359968] xpadneo 0005:045E:0B13.000B: controller quirks: 0x00000050
[ 134.359969] xpadneo xpadneo_welcome_rumble start
[ 135.350686] xpadneo xpadneo_welcome_rumble took 990ms
[ 135.350692] xpadneo 0005:045E:0B13.000B: Xbox Wireless Controller [44:16:22:d5:6f:ad] connected
[ 202.998399] usb 1-2.3: reset full-speed USB device number 6 using xhci_hcd
[ 273.352523] usb 1-2.3: reset full-speed USB device number 6 using xhci_hcd
[ 274.983042] usb 1-2.3: reset full-speed USB device number 6 using xhci_hcd
[ 287.837607] xpadneo 0005:045E:0B13.000B: reverting to original version (changed version from 0x00001130 to 0x00000517)
[ 287.837613] xpadneo 0005:045E:0B13.000B: reverting to original product (changed PID from 0x028E to 0x0B13)
[ 291.121082] xpadneo 0005:045E:0B13.000C: BLE firmware version 5.17
[ 291.121087] xpadneo 0005:045E:0B13.000C: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x028E)
[ 291.121089] xpadneo 0005:045E:0B13.000C: working around wrong SDL2 mappings (changed version from 0x00000517 to 0x00001130)
[ 291.121091] xpadneo 0005:045E:0B13.000C: report descriptor size: 283 bytes
[ 291.121092] xpadneo 0005:045E:0B13.000C: fixing up Rx axis
[ 291.121093] xpadneo 0005:045E:0B13.000C: fixing up Ry axis
[ 291.121093] xpadneo 0005:045E:0B13.000C: fixing up Z axis
[ 291.121094] xpadneo 0005:045E:0B13.000C: fixing up Rz axis
[ 291.121094] xpadneo 0005:045E:0B13.000C: fixing up button mapping
[ 291.121150] xpadneo 0005:045E:0B13.000C: gamepad detected
[ 291.121151] xpadneo 0005:045E:0B13.000C: enabling compliance with Linux Gamepad Specification
[ 291.121180] input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.000C/input/input40
[ 291.121283] xpadneo 0005:045E:0B13.000C: input,hidraw9: BLUETOOTH HID v11.30 Gamepad [Xbox Wireless Controller] on e8:48:b8:c8:20:00
[ 291.121303] input: Xbox Wireless Controller Consumer Control as /devices/virtual/misc/uhid/0005:045E:0B13.000C/input/input41
[ 291.121321] xpadneo 0005:045E:0B13.000C: consumer control added
[ 291.121341] input: Xbox Wireless Controller Keyboard as /devices/virtual/misc/uhid/0005:045E:0B13.000C/input/input42
[ 291.121360] xpadneo 0005:045E:0B13.000C: keyboard added
[ 291.121362] xpadneo 0005:045E:0B13.000C: controller quirks: 0x00000050
[ 291.121363] xpadneo xpadneo_welcome_rumble start
[ 292.112083] xpadneo xpadneo_welcome_rumble took 990ms
[ 292.112088] xpadneo 0005:045E:0B13.000C: Xbox Wireless Controller [44:16:22:d5:6f:ad] connected
[ 345.063670] usb 1-2.3: reset full-speed USB device number 6 using xhci_hcd
[ 346.604234] usb 1-2.3: reset full-speed USB device number 6 using xhci_hcd
[ 348.150879] usb 1-2.3: reset full-speed USB device number 6 using xhci_hcd
Arian8j2
commented
11 months ago @Overflwn I have exactly same problem with exactly same controller and bluetooth dongle, Controller disconnect after some times, and the time it takes to disconnect is pretty much random, One time i could play for 3 hours without any disconnects but some times it will disconnect every 15 minutes or so.
I don't think it's a problem from bluetooth dongle because problem still exists if i hook it up via usb.
I even hooked up controller with a Windows machine and updated it's firmware to latest one but the problem still exists on Linux.
xpadneo version: 0.9.r144.g9b3b696
archlinux kernel version: 6.4.7.arch1-2
Overflwn
commented
11 months ago @Arian8j2 Regarding USB, try installing xone aswell. Now, before plugging in make sure that the controller is shut off or disconnected from bluetooth. Then connect the USB cable. That way xone should take over and not xpadneo (you will notice this by checking if there's the "welcome rumble", it should not trigger if you do it this way and that's when xone actually takes control)
This way your controller shouldn't have a problem anymore, at least it worked for me. However, I bought myself a xbox controller dongle on Amazon, which works perfectly fine with xone.
It's a shame though, I wouldn't need the dongle if the bluetooth connection just worked stabily..
Arian8j2
commented
11 months ago @Overflwn I usually play casual games with controller so the disconnect doesn't bother me that much, So i probably stick with xpadneo and bluetooth, but thanks for the info.
kakra
commented
11 months ago @Overflwn I have exactly same problem with exactly same controller and bluetooth dongle, Controller disconnect after some times, and the time it takes to disconnect is pretty much random, One time i could play for 3 hours without any disconnects but some times it will disconnect every 15 minutes or so. I don't think it's a problem from bluetooth dongle because problem still exists if i hook it up via usb. I even hooked up controller with a Windows machine and updated it's firmware to latest one but the problem still exists on Linux. xpadneo version:
0.9.r144.g9b3b696archlinux kernel version:6.4.7.arch1-2
Well, that's exactly the problem with incompatible Bluetooth hardware (tho, whether it's the controller or the dongle which is incompatible can be left as an unsolved discussion). With some Bluetooth dongles, the problem even persists in Windows.
If you are seeing the exact same problem with USB, things become strange:
You could try:
Rumble crash can be avoided by inhibiting raw HID access to the controller device file. The udev file shipped with xpadneo does this but if you're running OpenRGB (or other software which operates on devices in raw mode), it may bypass this protection even for hardware it doesn't support. Try uninstalling such software temporarily. Take note: This only applies for the controller in Bluetooth mode, not in USB mode (USB is not HID).
Rumble crash seems to be triggered by games:
For the last mode (HID), SDL has received a patch to stay at intervals above 50ms (it used 10-20ms previously). You may need to update your SDL version. Some native games ship with bundled older versions of SDL which don't have this fix. Disabling raw HID access is a reliable work-around. Disabling rumble is a reliable work-around, too. Also, try disabling Steam Input.
Later firmware versions seem to prefer longer intervals: We found that xone needed to go from 10 to 20ms, and xpadneo needed to go from 20 to 50ms after some firmware update. USB may be unaffected but it's more likely that it needs 20ms intervals, too.
Arian8j2
commented
11 months ago @kakra I tried turning off rumble by setting trigger_rumble_mode to 2 and rumble_attenuation to 100 and tested out and rumble was successfully turned off then played a game for an hour and the issue was still there so i don't think the problem is due to rumble crash.
connections over USB cable don't use the xpadneo driver, xpadneo isn't involved at all in this case.
I tried with usb and powered off bluetooth completely with bluetoothctl, then played the same game for an hour and there was no issues, Maybe last time it was still connected to bluetooth for some reason, idk.
It seems the UB500 is the problem, If i understand correctly even #432 has the same problem.
Overflwn
commented
11 months ago Maybe last time it was still connected to bluetooth for some reason, idk.
Yup, that‘s why I wrote that you first have to shut the controller (or the bt connection) off before plugging in. If you are connected via BT and then connect the cable, it seems like the controller keeps using the BT connection.
kakra
commented
11 months ago If you are connected via BT and then connect the cable, it seems like the controller keeps using the BT connection.
It should not do that. I have 6 or 7 different models and vendors of Xbox compatible controllers, all support Bluetooth, three are genuine MS controllers. Each of them turns Bluetooth off and disconnects automatically from xpadneo as soon as USB is plugged in. So I rather suspect a flaky cable which doesn't properly establish a USB data connection and maybe only provides power if anything at all. Or you're connecting through a USB hub which doesn't always properly establish connection due to bandwidth or power constraints. Many non-powered USB hubs only support low-power USB devices as per spec, only a few ignore the spec and then it depends on your mainboard chipset (AMD usually allows running out of spec while Intel shuts down USB early).
A flaky cable may also explain why the controller intermittently re-connects. Also, using a passive USB hub may explain why the controller disconnects during rumble because it may exceed the spec power limit when rumble motors are running.
Try using a USB connector directly on your motherboard, or use an actively powered USB hub. If using a black USB connector (USB 2.1) try going to a blue USB 3 connector instead (provides more power). Or otherwise: If a lot of devices are already connected to either blue or black connectors, try isolating the controller on the other color to see if there are bandwidth/power limits you can circumvent that way. Also, if you're using a USB hub with more than 4 connectors, try switching to one with only 4 connectors (hubs with more than 4 connectors most likely have a cascaded hub inside with some connectors attached directly to the bus, some connectors handled by the internal hub chip).
Regarding the Bluetooth dongle: I originally suggested using TPL UB400. Unfortunately, there are a lot of China clones out there which only mimic the CSR chipset but don't behave exactly the same. The kernel works around a lot of those issues but some devices may have problems still. I'm not sure which chipset the UB500 uses. Running lsusb may reveal it.
PS: The controller uses a high-speed connection thus your USB cable should not be longer than 3 meters (10 feet), better 2 meters (6 feet). In any case, never daisy-chain USB cables or USB hubs.
Arian8j2
commented
11 months ago @kakra @Overflwn Thanks for the helps, I will try to get my hands on UB400, as soon as i got it i will test it and share my result.
kakra
commented
11 months ago Thanks for the helps, I will try to get my hands on UB400, as soon as i got it i will test it and share my result.
Yeah thanks, corrected my post to "UB" too ;-)
Overflwn
commented
11 months ago @kakra I will try again later today. I have used my USB3 ports on the pc case, I‘ll try it with MB ports aswell.
I haven‘t actually checked if GNOME shows the BT connection still being active, I just noticed that when I connect the cable while the BT connection is active, the random reconnect (with init rumble) kept happening, unless I first disconnect BT or shut the controller off and then connect the cable.
I think my USB cable should be fine though, as the controller works fine with it and I can also use it to copy files from phones and stuff like that.
kakra
commented
11 months ago I think my USB cable should be fine though, as the controller works fine with it and I can also use it to copy files from phones and stuff like that.
Yeah sounds like the cable might be okay, or the connector for that matter. That behavior is still strange and should not happen: The controller is supposed to drop wireless connections as soon as the wire is plugged in and established a USB data connection.
Arian8j2
commented
10 months ago Used UB400 for two days, Played games for about 6 hours in this two days and had no disconnect, So now i'm pretty sure the problem is something with UB500, I also sens a little more latency (just a little) with UB400 than UB500 but i can't say for sure.
It is better to have a file like tested-bluetooth-devices.md or something like that, that people write their experience with different bluetooth devices and send pr, So people know which bluetooth dongle is better to buy or which devices has problems.
Again, Thank you @kakra @Overflwn for all the helps.
kakra
commented
10 months ago Arian8j2
commented
10 months ago @kakra
I already had these configured.
Also, see here: https://github.com/atar-axis/xpadneo/blob/master/docs/BT_DONGLES.md
Oh cool i missed that :), Please add these too:
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)ID 2357:0604 TP-Link TP-Link UB500 AdapterAlso these are btmgmt info output if needed:
UB500:
hci1: Primary controller
addr E8:48:B8:C8:20:00 version 10 manufacturer 93 class 0x6c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy static-addr phy-configuration wide-band-speech
current settings: powered ssp br/edr le secure-conn privacy
name arch #2
short nameUB400:
hci0: Primary controller
addr 00:1A:7D:DA:71:15 version 6 manufacturer 10 class 0x6c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy static-addr phy-configuration
current settings: powered ssp br/edr le secure-conn privacy
name arch
short name
rautesamtr
commented
10 months ago I am having the same issue with random disconnects and immediate reconnects with TP-Link UB500 Adapter on Linux (Arch) but not Windows 11. The issue very often occurs immediately at the beginning of lego games after the menu and the level/hub loads and then randomly.
According to kernel source TP-LINK UB500 is Realtek 8761BUV Chipset.
Arian8j2
commented
10 months ago @rautesamtr If you can, buy UB400 it doesn't have that problem.
kanedait
commented
10 months ago I am having the same issue with random disconnects and immediate reconnects with
TP-Link UB500 Adapteron Linux (Arch) but not Windows 11. The issue very often occurs immediately at the beginning of lego games after the menu and the level/hub loads and then randomly.According to kernel source TP-LINK UB500 is Realtek 8761BUV Chipset.
thanks for info chipset "TP-LINK UB500 is Realtek 8761BUV" i don't know how to see the chipset of my TP-LINK. I think I have found a solution, since it works on Fedora 36 copied these 4 files, and put them on Fedora 38 rtl8761b_config.bin.xz rtl8761b_fw.bin.xz rtl8761bu_config.bin.xz rtl8761bu_fw.bin.xz add link https://drive.google.com/drive/folders/1EDSdTsvKfLmJ2cJHkuf1TS5Q_tzjdhfN?usp=drive_link if I go against the regulation I remove
rautesamtr
commented
10 months ago Found the chipset trough other bug reports but you can also find it refered in kernel source linux/drivers/bluetooth/btusb.c when you look for the usb id.
Testing your firmware and no disconnects so far. Looks like realtek introduced new bugs with their firmware update. Firmware problems are known but maybe we should open another ticket specifically regarding the disconnects in the current firmware.
CosmicHeron
commented
9 months ago I have started encountering the same issue with the ASUS USB-BT500, here is the info btmgmt info outputs:
hci0: Primary controller
addr 04:42:1A:5B:DA:F4 version 10 manufacturer 93 class 0x7c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy static-addr phy-configuration wide-band-speech
current settings: powered bondable ssp br/edr le secure-conn
name arch
short name When using the same BT adapter and controller on Windows I don't seem to get any random disconnects/reconnects. And oddly enough I don't seem to get reconnects if using a PS5 DualSense controller on Arch. Maybe the driver/firmware update @rautesamtr mentioned changed/broke whatever part xpadneo relies on?
[Edit] After testing the gamepad without xpadneo, except for RetroArch games seem to detect the controller fine without mapping issues, but the Bluetooth connection still drops occasionally so it's definitely a bluez/driver/kernel problem.
kanedait
commented
9 months ago I have started encountering the same issue with the ASUS USB-BT500, here is the info
btmgmt infooutputs:hci0: Primary controller addr 04:42:1A:5B:DA:F4 version 10 manufacturer 93 class 0x7c0104 supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy static-addr phy-configuration wide-band-speech current settings: powered bondable ssp br/edr le secure-conn name arch short nameWhen using the same BT adapter and controller on Windows I don't seem to get any random disconnects/reconnects. And oddly enough I don't seem to get reconnects if using a PS5 DualSense controller on Arch. Maybe the driver/firmware update @rautesamtr mentioned changed/broke ~whatever part xpadneo relies on~?
[Edit] After testing the gamepad without xpadneo, except for RetroArch games seem to detect the controller fine without mapping issues, but the Bluetooth connection still drops occasionally so it's definitely a bluez/driver/kernel problem.
Try the firmware files I posted your BT adapter probably has the same chipset
kode54
commented
9 months ago There's an outstanding issue in bluez 5.69 affecting Xbox controllers (and off-topic, Playstation DualShock controllers), fixed in master, not in a release yet. Best to either downgrade to 5.68, or roll your own updated version with the fix cherry-picked.
kakra
commented
9 months ago After testing the gamepad without xpadneo, except for RetroArch games seem to detect the controller fine without mapping issues, but the Bluetooth connection still drops occasionally so it's definitely a bluez/driver/kernel problem.
Just ftr: xpadneo is a HID driver, not a Bluetooth driver. So if you're having issues with Bluetooth, it's always a bluez/kernel issue never an issue with xpadneo. There's nothing in xpadneo that directly interacts with Bluetooth.
The mapping issues you're seeing should be fixed once software switched to SDL2 2.28+ and removed custom mapping profiles for Xbox controllers. I'm not sure if RetroArch uses SDL but it may make its own (wrong) assumptions about mappings. One way around it may be checking if RetroArch has read permissions on /dev/hidraw* and revoke that until it properly handles hidraw (either through SDL2 or natively).
CosmicHeron
commented
9 months ago Downgrading Bluez to 5.68 fixed all connectivity issues.
As far as RetroArch goes, messed around some more with and without xpadneo. With it loaded the controller is recognized as an "Xbox Wireless Controller" and works with the udev controller driver though the default mapping is all wrong and has to be manually reassigned.
Without xpadneo however the controller is correctly recognized as an "Xbox Wireless S Controller" but inputs simply do not do anything in the frontend (even keyboard presses are ignored, somehow). The controller works in games but the mapping is again all wrong. Switching the controller driver to sdl2 (which should be using 2.28+ on Arch Linux at least) forced the emulator to use a fallback profile and the controller works albeit without rumble.
I've made sure to put myself into the input group as suggested by the Arch wiki to avoid any permission issues.
The DualSense on the other hand works fine on the default controller driver, without mapping issues, so I'm going to chalk this one up to something not being right with RetroArch and its controller profiles.
kakra
commented
9 months ago controller works albeit without rumble.
Please try disabling the initial rumble. There's a race condition in SDL2 which prevents games from detecting rumble support if the announcement of the feature is delayed.
CosmicHeron
commented
9 months ago Has anyone else updated to BlueZ 5.70 and checked if the issue still persists for them? Upgrading didn't seem to fix the random disconnects and reconnects with the Xbox Series S controller (using the latest firmware), and I started getting them even when using the downgraded 5.68 version. With and without xpadneo. As previously, these don't happen when using the same controller and USB dongle on Windows 11 or when using the DualSense on Linux so a hardware fault is unlikely.
Annoyingly, using dmesg -w no useful message is logged that would indicate what happens, only this:
[ 1547.009376] xpadneo 0005:045E:0B13.0010: reverting to original version (changed version from 0x00001130 to 0x00000517)
[ 1547.009381] xpadneo 0005:045E:0B13.0010: reverting to original product (changed PID from 0x028E to 0x0B13)
[ 1550.358823] xpadneo 0005:045E:0B13.0011: BLE firmware version 5.17
[ 1550.358827] xpadneo 0005:045E:0B13.0011: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x028E)
[ 1550.358829] xpadneo 0005:045E:0B13.0011: working around wrong SDL2 mappings (changed version from 0x00000517 to 0x00001130)
[ 1550.358831] xpadneo 0005:045E:0B13.0011: report descriptor size: 283 bytes
[ 1550.358832] xpadneo 0005:045E:0B13.0011: fixing up Rx axis
[ 1550.358833] xpadneo 0005:045E:0B13.0011: fixing up Ry axis
[ 1550.358834] xpadneo 0005:045E:0B13.0011: fixing up Z axis
[ 1550.358835] xpadneo 0005:045E:0B13.0011: fixing up Rz axis
[ 1550.358836] xpadneo 0005:045E:0B13.0011: fixing up button mapping
[ 1550.358879] xpadneo 0005:045E:0B13.0011: gamepad detected
[ 1550.358880] xpadneo 0005:045E:0B13.0011: enabling compliance with Linux Gamepad Specification
[ 1550.358912] input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.0011/input/input55
[ 1550.359009] xpadneo 0005:045E:0B13.0011: input,hidraw13: BLUETOOTH HID v11.30 Gamepad [Xbox Wireless Controller] on 04:42:1a:5b:da:f4
[ 1550.359032] input: Xbox Wireless Controller Consumer Control as /devices/virtual/misc/uhid/0005:045E:0B13.0011/input/input56
[ 1550.359059] xpadneo 0005:045E:0B13.0011: consumer control added
[ 1550.359079] input: Xbox Wireless Controller Keyboard as /devices/virtual/misc/uhid/0005:045E:0B13.0011/input/input57
[ 1550.359099] xpadneo 0005:045E:0B13.0011: keyboard added
[ 1550.359101] xpadneo 0005:045E:0B13.0011: controller quirks: 0x00000050
[ 1550.359103] xpadneo xpadneo_welcome_rumble start
[ 1551.349714] xpadneo xpadneo_welcome_rumble took 991ms
[ 1551.349719] xpadneo 0005:045E:0B13.0011: Xbox Wireless Controller [3c:fa:06:50:cc:62] connectedFrom what testing I did the disconnects happen exclusively while in-game, never while just connected but on the desktop or something like that. The only exception was when trying to use the game in in the Yamagi Quake 2 source port so it might be that it's reading the inputs in some different way that doesn't cause the connection to drop? But it also doesn't implement rumble in any way afaik if that's a factor, however I got disconnects even when playing games that don't use rumble (Panzer Paladin, for example).
kakra
commented
9 months ago From what testing I did the disconnects happen exclusively while in-game, never while just connected but on the desktop or something like that. The only exception was when trying to use the game in in the Yamagi Quake 2 source port so it might be that it's reading the inputs in some different way that doesn't cause the connection to drop? But it also doesn't implement rumble in any way afaik if that's a factor, however I got disconnects even when playing games that don't use rumble (Panzer Paladin, for example).
There's a problem with the rumble implementation of the controller: If the game sends rumble too fast, the firmware will crash and the controller restarts, resulting in a disconnect, eventually followed by a reconnect. xpadneo itself has a countermeasure for this bug by reducing the rumble effects to fixed 50ms intervals. But this can only work if your games actually use rumble through the driver.
If your games use hidraw to directly interface with the controller, bypassing xpadneo, xpadneo cannot do its job. If this happens via SDL, that has a similar countermeasure - at least with later version which adjusted the interval from 10ms or 20ms to 50ms. If games use other libraries to directly interface with the controller in raw mode, no such countermeasure will exist.
You can prevent raw access to the controller by finding the hidraw number in the log (in your log above, it's hidraw13). Take note that this number will change every time the controller reconnects. Then run getfacl /dev/hidraw13 to find if your user has read and/or write access and revoke any permissions to that device: chmod a-rw /dev/hidraw13.
When properly installed, xpadneo should prevent access to the hidraw device. But we had issues in the past where other software would unconditionally overwrite that behavior and permit world read/write access to any hidraw device (which is a security disaster, btw, because it allows keylogging by any background process). The software we found is OpenRGB and QMK Firmware. Both should have fixed the behavior in latest versions but if you use such software, uninstall it, and then it works, you should report a bug there.
Even if you use software that doesn't implement rumble, the used software layer may still send rumble commands to the controller, even if the values are 0. If that doesn't pass through xpadneo but hidraw instead, there's nothing xpadneo could fix. SDL 2.28 or higher should be safe.
CosmicHeron
commented
9 months ago That might have been it! I did try getfacl /dev/hidraw13 and got back:
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw13
# owner: root
# group: root
user::---
group::---
other::---which like you said is expected, the user does not have read permissions. But I was also running polychromatic which depends on openrazer, which requires the user to be in the plugdev group. So I guess it might have been bypassing those permissions entirely? Either way, uninstalled both, rebooted, tried a few games that are rumble heavy and were guaranteed to disconnect within the first of minutes of play. After about 20 minutes I didn't get any dropped connections.
I'll do some more testing to make sure and if that was indeed the cause I'll log an issue on openrazer with a link to this thread.
kakra
commented
9 months ago Maybe openrazer adds the plugdev group to hidraw devices unconditionally, without looking at the vendor or capabilities of the raw device. If that happens, your user will get read/write access to the device and allows games to bypass the driver. You can also try setting SDL_JOYSTICK_HIDAPI=0 and/or SDL_JOYSTICK_RAWINPUT=0 so SDL would bypass raw access. I'm not sure which variable does what, I've simply set both.
BTW: Looks like the problem is here: https://github.com/openrazer/openrazer/blob/4cd7cdefc9729f94fd15c8343f2c7e6a21ec93ac/install_files/udev/99-razer.rules#L31
It sets the device node group for all input devices to plugdev - which should not be needed any longer: plugdev has been deprecated due to security concerns and replaced with a session manager adding the seat user to the ACL list of the device nodes. If your system doesn't use such a session manager, you may still need plugdev.
Looking at the rules file, it should skip the plugdev assignment if the vendor doesn't match. So if it still assigns the plugdev group to your hidraw device, there's either a bug in openrazer, or another software assigns permissions. At a first glance, it doesn't look like polychromatic fiddles with udev rules.
You can run udevadm monitor -p to see which events trigger and which properties are assigned for which device node.
CosmicHeron
commented
9 months ago And I'm back at square one, what I thought was the solution stopped working after a few days. Now the Xbox controller will lose connection and reconnect even when just sitting at the desktop. If it does so during a game rumble will stop working and won't work until the controller is manually disconnected and connected again. Setting the above mentioned environment variables doesn't seem to have any effect, unfortunately.
The same controller works with the same dongle plugged into the same USB port fine in Windows, and the DualSense controller does not appear to have any connectivity issues in Linux so this has to be an ongoing regression with BlueZ and/or the kernel. But until it is fixed the controller is rendered essentially useless in Linux.
kakra
commented
9 months ago If it does so during a game rumble will stop working and won't work until the controller is manually disconnected and connected again.
This may be fixed by setting modparam ff_connect_notify=0. I'm planning a rework of that feature in v0.10 so there's no longer a delay between detecting the input device and offering rumble.
liberodark
commented
8 months ago OS : Manjaro
Kernel : 6.5.5
Bluez : 5.70
SDL2 : 2.28
Xpadneo : hid-xpadneo 0.9.r144.g9b3b696
Xbox FW : 5.17.3202.0
USB BT 1 : ID 2357:0604 TP-Link TP-Link UB5A Adapter (UB500)
USB BT 2 : ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) (UB400)
Hi, have same issue with all Wireless Xbox Controller & TP Link UB500 & ASUS USB-BT500 on Manjaro.
Is Disconnecting randonmly. But work on USB & Rumble work.
And is working in BT on Steam Deck.
Also have send PR for update dongles : https://github.com/atar-axis/xpadneo/pull/441
Last question for @kakra is when you speak to ff_connect_notify=0 you need to rebuild project with static bool param_ff_connect_notify = 0;
Or set hid-xpadneo ff_connect_notify=0 ?
This is my dmesg log (without any change) :
https://paste.yunohost.org/nupuqumuxo.sql (UB500)
https://paste.yunohost.org/ivoletamuy.sql (UB400)
xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
xxd: /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:0B20.000B/report_descriptor: Permission denied
4294967295 0btmgmt info (UB500)
hci0: Primary controller
addr E8:48:B8:C8:40:00 version 10 manufacturer 93 class 0x7c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy static-addr phy-configuration wide-band-speech
current settings: powered bondable ssp br/edr le secure-conn
name pc-pc
short name btmgmt info (UB400)
hci0: Primary controller
addr 00:1A:7D:DA:71:15 version 6 manufacturer 10 class 0x7c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy static-addr phy-configuration
current settings: powered bondable ssp br/edr le secure-conn
name pc-pc
short nameHave try to set in : /etc/bluetooth/main.conf (KO)
MinConnectionInterval=7
MaxConnectionInterval=9
ConnectionLatency=0Have try to disable ERTM (KO)
options bluetooth disable_ertm=1
Have try to install firmware send by @kanedait (KO) Also have create a installer : https://github.com/liberodark/rtl8761b
Have try to downgrade : bluez bluez-libs bluez-utils in 5.68 (KO)
Best Regards
kakra
commented
4 months ago Closing as reports are not very focused on a single cause. Many of the issues are already fixed, or proven third-party bugs and documented in the troubleshooting docs, or will be fixed with the new rumble infrastructure coming in v0.10.
If you still feel like your individual problem is not solved, please check the other open reports and subscribe or comment there, or wait for v0.10 going live. If no open bug reports fits your problem, feel free to open a new request.
Version of xpadneo
xpadneo-dkms-git 0.9.r121.g727a84f-1
Controller Model
Connection mode
Installed Software
Protocol Information
Please help us identify at which layer the problem can be found if you want to report mapping errors or if the controller fails to be detected:
evtestis showing issues (describe the issues below)BTN_NORTHandBTN_WESTare intentionally swappedjstestis showing issues (describe the issues below)gamepad-toolis showing issues (post console output below)Please describe how it is failing below in the next sections.
Severity / Impact
Describe the Bug
The controller worked just fine on the previous 5.13.3143.0 firmware, but now that I'm on the recently released 5.13.3146.0 firmware, it randomly disconnects after a few minutes. And since you mention that USB support is not there, I cannot get it to work with that, either.
Steps to Reproduce
Expected Behavior
I expect the controller to stay connected and working.
Screenshots / GIFs / Videos
I have no screen shots to demonstrate it. I do have some dmesg log output, though.
System Information
Controller and Bluetooth Information
xpadneo-btmon.txt
xpadneo-dmesg.txt
xpadneo-lsusb.txt
Additional Context
As I said, this issue only started after I briefly used Windows 11 and made the mistake of updating my controller's firmware. Windows does not allow me to revert it, either.