Closed orbea closed 3 years ago
This is a known bug of the controller firmware when using Bluetooth connections, it also happens in Windows. There's nothing we can do except poking MS about it: https://answers.microsoft.com/en-us/xbox/forum/all/xbox-elite-series-2-disconnecting-from-pc/7e5a964a-16cc-4e83-8dec-aa8c858b875c
Depending on the model, firmware version, and rumble patterns you'll experience loss of input (partially or completely), spontaneous controller reboots, or full devices freezes (with the rumble motors stopping after 30+ seconds). The Bluetooth stack may or may not detect a disconnect or connections timeout. This is most likely purely an issue with the device firmware and nothing that can be fixed or worked around from the driver.
We already deployed some work arounds, e.g. by using tighter rumble timing and intervals of at least 10ms before updating the rumble motors which prevents most instantaneous crashes. Future versions of xpadneo will work towards supporting the original controller dongle which uses Wifi instead of Bluetooth. With that, rumble is stable if we stay above the 10ms intervals. Apparently, the dongle firmware must be uploaded to the dongle during device init, and it's closed source and legal implications for shipping it aren't clear yet.
I'm not sure where this file is?
Yeah, this is because Steam Input steals the device and presents it under uinput. You should disable Steam controller support in big picture mode otherwise we get wrong info, and some of the work-arounds of the driver may not work.
Thanks for the detailed reply. It is unfortunate to learn this is a problem with the device firmware. I had the same issue with a wired xbox 360 gamepad I broke by dropping one too many times, but was never able to get a detailed explanation. :)
Future versions of xpadneo will work towards supporting the original controller dongle which uses Wifi instead of Bluetooth.
Is there a place this can be tracked?
Yeah, this is because Steam Input steals the device and presents it under uinput. You should disable Steam controller support in big picture mode otherwise we get wrong info, and some of the work-arounds of the driver may not work.
I don't use steam and have never installed it to this computer.
I wonder if it would be possible to reverse engineer the firmware and then replace it with an open source reimplementation? At the very least I doubt this would be trivial, but it would avoid having to rely on microsoft to fix this issue.
Is there a place this can be tracked?
Yeah, this is because Steam Input steals the device and presents it under uinput. You should disable Steam controller support in big picture mode otherwise we get wrong info, and some of the work-arounds of the driver may not work.
I don't use steam and have never installed it to this computer.
Then this is strange... Do you use other types of similar software that moves the controller to uinput? Because this looks like uinput may be involved:
/sys/devices/virtual/misc/uhid/0005:045E:02FD.002B/report_descriptor
With
disable-ff=1
ordisable-ff=2
the issue seems rarer?
Looks like a placebo effect, this parameter isn't supported any longer:
[202861.316468] hid_xpadneo: unknown parameter 'disable_ff' ignored
Since you are running Gentoo and probably installed without the official installer, you may need to install the udev rules manually, along with the other files that should go to /etc
. Also, there may be artifact files in /etc
you may need to remove.
I'm using Gentoo myself, I should probably add some official installer for it.
Then this is strange... Do you use other types of similar software that moves the controller to uinput?
Not that I am aware of. This is a relatively new install with a stock 5.9.12
kernel using the source from kernel.org. The only programs I have that would use a gamepad are emulators like dolphin-emu, pcsx2, ppsspp and potentially wine.
Looks like a placebo effect, this parameter isn't supported any longer:
Thanks for pointing this out, I also noticed the logs after I wrote that. It seems sometimes it happens sooner and other times it happens later.
Since you are running Gentoo and probably installed without the official installer, you may need to install the udev rules manually, along with the other files that should go to /etc. Also, there may be artifact files in /etc you may need to remove.
Yes, I used make ; make modules_install
.
Looking at the install scripts I created these files.
$ cat /etc/modprobe.d/99-xpadneo-bluetooth.conf
options bluetooth disable_ertm=y
$ cat /etc/modprobe.d/xpadneo.conf
alias hid:b0005g*v0000045Ep000002E0 hid_xpadneo
alias hid:b0005g*v0000045Ep000002FD hid_xpadneo
alias hid:b0005g*v0000045Ep00000B05 hid_xpadneo
alias hid:b0005g*v0000045Ep00000B13 hid_xpadneo
$ cat /etc/modprobe.d/99-xpadneo-options.conf
options hid_xpadneo disable_deadzones=0 rumble_attenuation=0 trigger_rumble_mode=0
$ cat /etc/udev/rules.d/98-xpadneo.rules
ACTION=="add", KERNEL=="0005:045E:02FD.*|0005:045E:02E0.*|0005:045E:0B05.*|0005:045E:0B13.*", SUBSYSTEM=="hid", DRIVER!="xpadneo", ATTR{driver/unbind}="%k", ATTR{[drivers/hid:xpadneo]bind}="%k"
ACTION=="add", DRIVERS=="xpadneo", SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="1", TAG+="uaccess", MODE="0664", ENV{LIBINPUT_IGNORE_DEVICE}="1"
And ertm is disabled.
$ cat /sys/module/bluetooth/parameters/disable_ertm
Y
Did I miss anything?
Edit: After creating these missing files the rumble when connecting started to work.
After creating these missing files the rumble when connecting started to work.
Now, the rumble throttler of xpadneo should work and you may have better luck. After all, I don't think your system was actually using xpadneo before.
Now, the rumble throttler of xpadneo should work and you may have better luck. After all, I don't think your system was actually using xpadneo before.
I was able to rmmod hid_xpadneo
and then when connecting the gamepad it would get loaded again as shown by lsmod(8)
so I thought it was used at some level. Regardless you may be right that I will have better luck now, after short testing I was unable to reproduce the problem again. I'll report back after more thorough testing.
Thanks for the help!
I was able to
rmmod hid_xpadneo
and then when connecting the gamepad it would get loaded again as shown bylsmod(8)
so I thought it was used at some level.
This is because the gamepad PIDs are in the driver so the kernel autoloads it, but your dmesg logs didn't show any presence that it actually initialized the controller so udev didn't bind the device to the driver. If you compare dmesg now, you'll see xpadneo actually logging device init. The connect rumble is actually a hint for that so you know it worked without looking at the logs (and it's a test if 3rd party manufacturers implemented rumble correctly).
@orbea As a Gentoo user, you could use my kernel patch which integrates xpadneo right into the kernel, and with it you also probably no longer need to disable ERTM: https://github.com/kakra/linux/pull/11
Clone the repository, then checkout that PR branch, now run:
git remote update --prune
git reset --hard
git format-patch --stdout origin/master | sudo tee /etc/portage/patches/sys-kernel/gentoo-sources/9300_xpadneo.patch
(9300 is just a number to order this after Gentoo kernel patches, any number 9000-9999 should work)
This will export a patch above my current master (which points to the base version of the kernel I'm using) for xpadneo. The branch names include the kernel branch which is 5.10 currently.
Then re-emerge gentoo-sources. You may need to sudo mkdir -p /etc/portage/patches/sys-kernel/gentoo-sources
once first. Also, you may need to unmask sys-kernel/gentoo-sources-5.10*
. The build log should say "User patches applied". To remove a patchset, delete the file from the patches folder and re-emerge gentoo-sources again.
After installing that kernel, you should have xpadneo built right into the kernel - just enable it in make menuconfig
, no udev rules needed, and hopefully also no Bluetooth adjustments.
There are a few other pull requests that track several other performance patchsets useful for gaming with the gentoo-sources kernel (MuQSS + full CK patchset, Intel's kernel performance patches from ClearLinux, support for Valve's Proton fsync.
At some point I'll rebase those patches when they become incompatible with the latest kernel version. If you're having problem with one of those, consider asking your question there and not here. Thanks.
Thanks for pointing that out. I'll give it a try soon when I move to 5.10 kernels. I am currently on 5.9.15 using sources from kernel.org, but I am fairly familiar with compiling the kernel manually that I should manage. In gentoo genkernel does most of the tedious work.
Regarding this issue it still enters the infinite rumble, but sometimes it never seems to happen. Maybe some games reproduce it easier? I haven't found the time to try to debug it further yet.
Regarding this issue it still enters the infinite rumble
Yeah, using the 10ms intervals is only half of the solution. The other crash condition seems to be deeply hidden in the Bluetooth implementation of the controller firmware itself and can also be observed in Windows. There's no known work-around. You can try disabling the trigger rumble (if your controller has those rumble motors) with parameter trigger_rumble_mode=2
but to me it looks mostly like a placebo effect: If anything, it may reduce the issue but doesn't fix it either.
I am currently on 5.9.15 using sources from kernel.org, but I am fairly familiar with compiling the kernel manually that I should manage. In gentoo genkernel does most of the tedious work.
I unmasked =sys-kernel/gentoo-sources-5.10*
- it's mostly identical to kernel.org with a few Gentoo-specific security fixes. You should really use that one. Also, I'm not using genkernel, I'm using make menuconfig
with migrating the .config
over each time, as you would by manually compiling the kernel. The nice side-effect of this is that I can add various patches and slipstream them automatically into the installation via /etc/portage/patches
but still have full control over the kernel configuration.
I am pretty stuck in my ways after manually installing my own kernel in Slackware for so long. I am rather new to Gentoo, but found genkernel does away with lot of the tedium of updating the kernel, it is still able of using arbitrarily modified source trees, using menuconfig, custom config files and offers more control on the kernel version.
genkernel --luks --lvm --bootloader=grub2 --mountboot --menuconfig --kernel-config=/usr/src/config --makeopts=-j4 --no-zfs all
I compiled a 5.10.5
kernel, applied PR https://github.com/kakra/linux/pull/11 as a patch and enabled xpadneo in menuconfig. Then I removed all of the modifications listed in comment https://github.com/atar-axis/xpadneo/issues/264#issuecomment-745367007.
It seems to work just as well as it did before.
$ cat /sys/module/bluetooth/parameters/disable_ertm
N
Also you can just add .patch
or .diff
at the end of PR and commit links to get a patch. :)
Yes, this is how I'm using xpadneo in Gentoo: Compiled right into the kernel as a patch (but still as a loadable module). Updating xpadneo from the xpadneo source itself still works (if compiled as a module), if you use make -C hid-xpadneo reinstall
from the xpadneo project root (it will re-compile as user, then use sudo
for installation).
BTW: Yep, appending .patch
to PR URLs is a lesser known but very useful feature. ;-)
Just curious, but are there any known similar controllers with working bluetooth and rumble?
We should be supporting any controller that claims to be compatible with Xbox controller HID mode. I think most 8BitDo controllers in xinput mode are supported. Some of them have rumble support, tho, their implementation is buggy/limited sometimes. The driver has work-arounds for it via quirk flags.
Maybe we should start compiling a list of known-compatible controllers in the docs.
@orbea stretching "similar" (if you're looking for anything that works), PS2-PS4 controllers have in-tree Linux drivers written by Sony, and PS5 controller support is waiting to be merged.
The interesting bit is that PS5 controllers started discussion about how to properly support the trigger rumble natively via kernel APIs. Our driver currently synthesizes the rumble values from the strong and weak motor values because we only get two values from the kernel rumble API.
This will be interesting and I'll be watching the development once merging is complete.
@lights0123 I have various official and non-official PS3 controllers, but they all fail with bluetooth in the same way.
This may be a duplicate of #272.
Please re-open if it is still an issue.
Version of xpadneo
https://github.com/atar-axis/xpadneo/commit/bf8a3c3d7e28162d074744539d0b228566cb0e32
Severity / Impact
Describe the bug
When using an official Xbox Wireless Controller with rumble it will occasionally get stuck on a rumble on state and will not stop rumbling until the controller is turned off. During this time other input still works as expected. This can completely break gameplay depending on the game.
Steps to Reproduce
Expected behavior
The rumble should not get stuck.
Screenshots/Gifs
N/A
System information
I'm not sure where this file is?
Best guess is?
Controller and Bluetooth information
xpadneo-btmon.txt.gz xpadneo-dmesg.txt xpadneo-lsusb.txt
Additional context
With
disable-ff=1
ordisable-ff=2
the issue seems rarer? Withtrigger_rumble_mode=1
when this occurs I also lose all other input. It also does not rumble when connecting the gamepad. Please let me know if there is any other info I can provide?