[Linux] Long loading times if Xbox One Controller is connected via bluetooth

iGom commented 4 years ago

Description

Retroarch takes a long time, as well as games or thumbnails to load if Xbox One S Controller is connceted via bleutooth on Linux (enhanced retransmission mode within Bluetooth protocol needs to be disabled for Xbox1pad to work)

Expected behavior

Normal loading times

Actual behavior

Long loading times, thumbnails don't even load, I also noticed menu doesn't show battery charge level or shows 0% next to clock time)

Steps to reproduce the bug

Disable the aforementioned Bluetooth mode using commend $ sudo sh -c 'echo 1 > /sys/module/bluetooth/parameters/disable_ertm'
Connect Xbox One S Controller via Bluetooth to laptop
Launch Retroarch and wait, then launch any core/game

Version/Commit

RetroArch: Stable 1.8.5 installed via PPA

Environment information

OS: Ubuntu Focal Fossa 20.04 (Lubuntu distro) Linux 5.4.0-22-generic x86_64

http://dpaste.com/08264DR

prurigro commented 4 years ago

It does occur for me with an 8bitdo controller in xbox bluetooth mode.

Sanaki commented 4 years ago

Same here with the 8bitdo SN30 Pro+ in xinput mode on x86_64 Linux. EDIT: Just timed it, about 30 seconds to start retroarch, another 30 to start up the snes9x core and 15 past that for the game to actually load. This bug is by no means new, but I forgot to report it back when I originally noticed it. Tried backtracking as far as 1.6.9 (6f5cad5f5993e27fc1daa5e5e04f1749164f9a1c), still was an issue then.

goodjaerb commented 4 years ago

I just ran into this issue today with my Xbox One S bluetooth controller. I know it use to work just fine. I thought retroarch was just frozen but after reading the information here I waited a minute or so and sure enough the emulator started. But did anyone else have this issue: the controller detected as "Xbox Wireless Controller" which is slightly off, it should be "Xbox One S Controller" or something like that more specific. The autoconfig wasn't quite right as it should be I believe because it wasn't detected properly.

Beside that (possibly separate issue?) if I plug the Xbox One S controller in with USB it detects fine and the autoconfig loads but it plain doesn't work. No response from any buttons.

quick edit: i own two 8bitdo M30 bluetooth controllers and they work perfectly, no wait times or anything.

otonoton commented 4 years ago

Same issue here with 8bitdo SN30 Pro on Ubuntu 18.04. If the gamepad is connected before RA starts, it takes somewhere around 30 seconds to start up, and the same delay happens again every time content is loaded or closed. GDB seemed to suggest there was some kind of hang happening in a udev function but I didn't write it down. The same pad on my raspberry pi does not have this issue. Also if I wait until the game is loaded before turning on the pad, then there is no delay... but then closing content will have a delay if I don't turn off the pad first.

Sanaki commented 4 years ago

Just got an 8bitdo m30, same issue present. I'm now thinking this is due to the attempt to check and display controller battery. I managed to get this error once when it hung trying to end the process by turning off the controller (to get it to finish closing). Failed to open /sys/class/power_supply/hid-e4:17:d8:58:86:7f-battery/capacity: No such file or directory Upon attempting to cat that file myself, the terminal hung up for about ten seconds before returning cat: '/sys/class/power_supply/hid-e4:17:d8:58:86:7f-battery/capacity': No data available

Entire contents of uevent:

POWER_SUPPLY_NAME=hid-e4:17:d8:58:86:7f-battery
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_MODEL_NAME=8BitDo M30 gamepad
POWER_SUPPLY_SCOPE=Device

goodjaerb commented 4 years ago

@Sanaki I had the same idea, but you can disable the battery display and it still happens. Unless there are still checks happening int he background. I believe those "failed to opens" ceased when I disabled the battery display but the bluetooth lag remained. It's also strange that when I posted before, my M30's worked fine, but now they behave just as the xbox controller. It seems tied to the bluetooth adapter as I can unplug it while it's "lagging" and I believe the core immediately resumes. Then I can plug it in and it works fine. I would have to do more tests.

I've considered making a second issue because the autoconfig's for my bluetooth devices appear all out of whack but I don't know if it is related to this or not.

Sanaki commented 4 years ago

Yeah, it's still running the check in the background. The errors going away isn't actually a good sign. The error means it stopped waiting for a "no data" response. The reason it's taking so long is because it -doesn't- error. I'm fairly confident this is the issue. I'll see if I can replace the check with a spoof file and rebuild to verify. As for the autoconfig, I just learned the hard way that the m30 in particular screws up the button layout if you update from 1.10 to 1.13 or 1.14. I'm going to downgrade mine later.

EDIT: Seems both status and capacity are being checked, and both return no data for me. That'd account for double the time on the freeze in retroarch.

EDIT2: I've verified during the hang, even with battery display disabled, it's opening /sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.001A/power_supply/hid-e4:17:d8:58:86:7f-battery/uevent and hanging on reading that. I'm not having much luck rebuilding to stop accessing that, but I'm getting very good at making retroarch segfault when I change something I shouldn't have.

gouchi commented 4 years ago

You may start here for power state checking.

Sanaki commented 4 years ago

Changing joypad driver from udev to linuxraw sometimes remedies this issue, though some cores will hang indefinitely until the controller is disconnected. Not quite sure what that means for how to fix it while still using udev though.

EDIT: To be clear, I don't recommend linuxraw for general use. It can't handle controller disconnects and reconnects, for one.

joshuaseltzer commented 4 years ago

This issue seems very similar and related to a long-time issue I've been dealing with on MacOS (#3660). About a year ago, I attempted to set up a development environment to debug this but never was able to figure it out unfortunately.

The symptoms I face are almost identical to what people are experiencing here on Linux. Personally I'm using a Dualshock 3 via Bluetooth on MacOS Mojave 10.14.6. It all began when upgrading to macOS Sierra years ago.

Mangus78 commented 4 years ago

I've noticed that turning OFF "show battery level" under settings>user interface>views, resolved the issue and now there are no more lag or dalay doing whatsoever. So it seems to be definitely a battery check issue. Ubuntu 20.04/retroarch 1.8.8/8bitdo sf30 pro

joshuaseltzer commented 4 years ago

@Mangus78 I was hopeful that this would fix the controller lag issue on macOS, but it didn't change anything.

I timed it on macOS, and it appears that the lag/hang is for 15 seconds. It seems as though this issue is unrelated on Mac (I believe it's a rumble-related bug, not battery level).

goodjaerb commented 4 years ago

@Mangus78 I'll have to try again on 1.8.8. Turning that feature off before did not resolve anything for me. Same OS.

Sanaki commented 4 years ago

There was an update today for the SF30 Pro+ involving battery. While it didn't fix the problem at all, the description has made me think the freeze from udev attempting to read the battery is related to some special method involved in the xbox game bar battery reporting that goes against the standard Bluetooth battery spec.

EDIT: Forgot to specify, turning off battery display changes nothing here. Stack trace confirms it's hung up on battery despite that being off (ten second freeze where I typed <FROZEN> into the output):

access("/sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.001F/power_supply/hid-e4:17:d8:d8:f9:80-battery/uevent", F_OK) = 0
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.001F/power_supply/hid-e4:17:d8:d8:f9:80-battery/uevent", O_RDONLY|O_CLOEXEC) = 21
fstat(21, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
fstat(21, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(21, <FROZEN>"POWER_SUPPLY_NAME=hid-e4:17:d8:d"..., 4096) = 162
read(21, "", 4096)                      = 0
close(21)                               = 0
getrandom("\x1f\x9e\x4f\x7f\x6d\x10\x77\x69\x5c\x55\xcd\x2a\xba\xb0\xb2\xb1", 16, GRND_NONBLOCK) = 16
readlinkat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:256/0005:045E:02E0.001F/power_supply/hid-e4:17:d8:d8:f9:80-battery/subsystem", "../../../../../../../../../../.."..., 99) = 54
openat(AT_FDCWD, "/run/udev/data/+power_supply:hid-e4:17:d8:d8:f9:80-battery", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

denilsonsa commented 4 years ago

I can confirm Sanaki findings. I'm using Raspberry Pi 4 running Gentoo arm64.

Using strace -f -o strace.log retroarch, I can see retroarch opening that path about four times during startup. And that path takes about 10 seconds to return any data, which means at least 40 extra seconds waiting for retroarch to load.

Not only the startup gets slower, but loading thumbnail images (inside playlists) also gets slower/delayed while my 8BitDo Bluetooth controller is connected in X-input mode (turn on the controller by holding X+Start). Switching the controller to Android/Dinput mode (turning it on by holding B+Start) (and re-pairing it) solves the issue, because there will be no power_supply path in /sys/ anymore.

Regardless of the bluetooth controller, RetroArch is still reading the power_supply/*battery/* path from my Wireless Logitech USB keyboard (it has a dongle connected through USB). I don't know why RetroArch wants to read from it.

Suggestions:

RetroArch could stop reading such data.
RetroArch should try reading that data in non-blocking mode. Of course this is easier said than done, as it means converting a simple synchronous call into async code. However, the benefit to the end-user is enormous.

Other people are also being affected by this issue. On a quick search, I found a few reddit posts:

Some investigation:

cd /sys/devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11/*/power_supply/hid-*-battery
for a in capacity model_name  online  present scope status type uevent ; do time grep -H '' $a ; done

capacity took 5.2 seconds (not used by RetroArch)
status took 5.2 seconds (not used by RetroArch)
uevent took 10.2 seconds (read multiple times by RetroArch)

MrZammler commented 4 years ago

Hi, I'm also affected by this bug. I'm on Gentoo on x86_64, and it seems that by using the xpadneo driver there's no more blocking while using retroarch. (The same driver also enables rumble in Steam for the SN30+ Pro). There's an ebuild for the driver in vortex overlay.

Sanaki commented 4 years ago

Tested xpadneo out. While it does resolve the issue, it has some of its own issues, such as forcing the Nintendo button layout for 8bitdo controllers and failing to expose the guide button as a button.

EDIT: Nintendo button layout is fixable and will likely not be on by default in future versions. The lack of guide button exposure is by design. The issue with that is more that Retroarch doesn't know how to handle the correct signal (KEY_HOMEPAGE). So yeah, it seems pretty decent overall. The issue still should likely be fixed outside of xpadneo though.

RBertoCases commented 3 years ago

SN30 Pro+ user here. I tried using dinput mode on the controller. It works but didn't care for the button layout changes. So tried a wired connection in xinput mode and can confirm that resolves the issue on my end.

Tested on Pop!_OS 20.10 x86_64, Retroarch 1.9.0

gitowiec commented 3 years ago

xpadneo driver

How can I use and configure the xpadneo driver with RetroArch? Please elaborate

Sanaki commented 3 years ago

You install the driver. It automatically handles xinput controllers over bluetooth. That's it. 8bitdo users probably will want to follow my instructions here to make the controller use the standard xbox button layout. https://github.com/atar-axis/xpadneo/

gitowiec commented 3 years ago

@Sanaki thank you, I just choose 2 (no trigger rumble) to pass anything else than 32. Can I pass 0 to disable everything? Zero 2 does not have rumble, and I don't know what other 1,4,8 options mean. Or should I choose 16?

Sanaki commented 3 years ago

You should be able to just pass 0 if need be.

chinarut commented 3 years ago

ah - see I'm not alone here. Experiencing this issue on Ubuntu 20.04.2 LTS w an 8Bitdo Lite controller.

I did not have this issue a few weeks ago and the only major change I see is an update to 20.04.2.

AlexFolland commented 3 years ago

This seems to be a duplicate of #8510. However, this has more information, so that one should probably be closed instead.

That being said, I am experiencing this right now with the latest git build using an 8Bitdo SN30 Pro. Here are some facts.

I'm running Manjaro 21.0 stable with XFCE and using the retroarch-git AUR package.
The gamepad works, but the only problem is a long delay on a black screen every time I start RetroArch, close content, or start content.
I'm using the input driver in RetroArch called x.
I've timed the black screen delay multiple times with a stopwatch and it always lasts 25 seconds.
With the gamepad not connected at all, there's no delay starting RetroArch. It starts instantly, like in the next frame after I click the launcher in my XFCE panel.
There is no delay with a PS4 gamepad connected instead. This is only happening with the 8bitdo SN30 Pro.
The 8bitdo SN30 Pro is connected using the "Windows" connection mode, which requires pairing it after starting it with Start+Y.
While this is happening, RetroArch's CPU and GPU usage is insignificant.
I am able and willing to gather any requested logs for this.

nadenislamarre commented 3 years ago

if needed, i fixed it today on batocera.linux (https://github.com/batocera-linux/batocera.linux/commit/ce894a8e7730f5c0a67a507e50489ffb6614ca01) (at least, i applied a workaround to disable battery at linux level) because of the battery long (and incorrect) answer from the firmware, udev takes long time to applies rules (and then declare the pad as a joystick). 8bitdo should give me a firmware dev contact to work on the subject. depending on the pad and configuration, retroarch reads the battery information too at boot and it takes long too, but it is not the ra fault.

joshuaseltzer commented 3 years ago

@nadenislamarre this is great. I’m not super familiar with this code base, but it looks like all of the patches are specific to Linux-based builds. I might try to apply this patch to the macOS version, but then I’d also need to setup an environment to build a release.

nadenislamarre commented 3 years ago

this is the linux hid driver. you cannot apply on mac os x. and i guess you've not the code for that driver open on osx. this is to prevent linux to get battery information about the pad.

joshuaseltzer commented 3 years ago

@nadenislamarre yeah I was hoping a similar patch could be applied to the controller logic/code on macOS since it experiences the same exact lockups.

nadenislamarre commented 3 years ago

yes, because it is a firmware issue i think, it is not related to linux nor mac os x i think. i will see if i can do something to help to fix at firmware level. i"m currently trying to get a contact.

obrie commented 3 years ago

Can this be enabled through the usbhid.quirks kernel option? e.g. In the RPi's /boot/config.txt, I was thinking something along the lines of:

usbhid.quirks=0x045e:0x02e0:0x40

Happy to test, but wanted to see if you knew off-hand.

gouchi commented 3 years ago

Can you make a test with this patch if it is improving the situation ?

Thank you.

tomgar commented 3 years ago

@obrie I guess the usbhid quirks option is for usb connections and not bluetooth ones which is the one having the issue at hand.

@nadenislamarre did someone from 8bitdo contact you about this? Thanks!

nadenislamarre commented 3 years ago

not technical peopl

gouchi commented 3 years ago

So you are still having the issue in RA 1.9.6 ? (The patch is included)

Sanaki commented 3 years ago

I actually forgot about testing this, sorry about that. Seems I can't properly validate this, since the above cat commands actually return instantly now. I'm not sure when this changed or why, I assume it was a kernel update that did so. Hopefully someone else can chime in.

tomgar commented 3 years ago

@gouchi just checked with RA 1.9.6 and yes, the issue is still there.

gouchi commented 3 years ago

Are you still getting this issue with current stable RA 1.9.9 ?

tomgar commented 3 years ago

@gouchi I can confirm that the issue is gone for Linux's udev input driver starting from RA 1.9.8.

joshuaseltzer commented 3 years ago

Are you still getting this issue with current stable RA 1.9.9 ?

Working great for me on both 1.9.8 and 1.9.9 on macOS Mojave 10.14.6 and a DualShock 3 (Bluetooth).

AlexFolland commented 3 years ago

A DualShock 3 gamepad is not an Xbox One gamepad. macOS is not Linux.

gouchi commented 3 years ago

@tomgar Thank you for the feedback.

@iGom Please close this issue.

gouchi commented 2 years ago

@LibretroAdmin I think this issue can be close because of tomgar's feedback. Thank you.

libretro / RetroArch