Steam Deck - Long delay in accessing quick menu when bluetooth controller is connected.

[lastrogue]

First and foremost consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
• This is not a forum or a help section, this is strictly developer oriented

Description

When a bluetooth controller is connected to the Steam Deck and a game is launched from Steam Deck's game mode, when trying to access the quick menu by pressing L3+R3 there is a delay of around 30 seconds. This has been seen with multiple cores and multiple controllers.

After exiting RetroArch and disconnecting the bluetooth controller, if a game is launched using just the Steam Deck controls the quick menu comes up righ away.

Expected behavior

Instant access to the quick menu while using a bluetooth controller in the window.

Actual behavior

A delay of approximately 30 seconds occurs when accessing the quick menu and a bluetooth controller is connected.

Steps to reproduce the bug

1. Using the flatpak version RetroArch set a custom game to be launched in steam by specifying the run command to launch a target game. This can be simplified by using EmuDeck.
2. Connect a bluetooth controller. DS4 and Xbox One have both been show to exhibit this issue.
3. Launch the game while in game mode on the steam deck
4. Press the R3+L3 buttons
5. Wait an extended period of time for the quick menu to come up.
6. In some cases this issue goes away after the first launch of the quick menu. In a recent test, the issue remained each time I attempted to open the quick menu.

NOTE: This does not happen when launching RetroArch in desktop mode. EDIT: When launched in desktop mode, the primary controller is the steam deck. The issue still does not occur when changing the input to my bluetooth controller and attempting to launch the quick menu again.

Bisect Results

This has happened as far as I have been using this. It was first reported in the EmuDeck discord on 7/20/2022. But may have likely existed before that date.

Version/Commit

You can find this information under Information/System Information

• Build date: Apr 26 2022
• Git Version: 9b282aa

Environment information

• OS: SteamOS Holo
• Version: 3.2
• Kernel Version: 5.13.0-valve15-1-neptune-02197-gf6ec7ad3762a
• Compiler: N/A

[lastrogue]

When changing the order of the controllers in the steam deck menu, this issue seems to go away. The order seems to be putting both the bluetooth controller and the steam deck controls as Input 1. If you change the order, the issue doesn't occur.

Another note is that this only happens when pressing L3+R3 on the bluetooth controller. Even if the bluetooth controller is connected, the issue does not occur if L3+R3 is pressed on the steam deck controls.

[steveduffin]

This issue persists for me after I’ve disconnected the Bluetooth controller and am back to only using Steam Deck to bring up the menu. Restart clears the issue until I reconnect a controller.

[hymness1]

I can replicate the issue (in fact I was having the same problem as lastrogue ). Reordering the controllers so the bluetooth controller is the first controller makes the menu access instant. As far as I know PPSSPP it is the only emulator I've been having this problem.

[Mythris29]

Same issue here. Very slow to open the quick menu the first time in a game then it seems to be fine and loads instantly after that. Using L3+R3 menu combo.

[arbitar]

Edit: proper workaround found. Steam Deck settings > Controller > Steam Deck > Steam haptics = OFF and reboot You lose the buzz on the touchpads until you set it back to ON and reboot, but the issue goes away.

Also experiencing this issue. Same hardware/OS: Steam Deck. SteamOS Holo, 3.4.4 (20221228.1 stable channel) kernel 5.13.0-valve36-1-neptune, steam version 1671675017. Also using a Bluetooth controller (Xbox One controller).

Here are verbose logs with frontend set to level 0 (debug) for a session of my starting retroarch, loading a ROM with the 1.14.0 - Mupen64plus-next (2.4-Vulkan c10546e) core, using the L3+R3 combo, then exiting the software via Select+Start controller shortcut. The events:

• Opened RA
• Enabled logging
• Pressed L3+R3
• Log message at line 112 was immediately generated: [WARN] [GLX]: glXSwapInterval(-1) failed.
• (waits...)
• After some delay, the menu appears simultaneously with the following log message: [WARN] [SDL]: Failed to create rumble effect for joypad 2: Haptic: Error uploading effect to the device: Connection timed out

If also noted that when I start RetroArch directly (instead of via a launcher like EmulationStation), it also takes a while to load the main menu ... about as long as it takes to load the quick menu. A tail on the logs during startup reveals the same thing, which appears right when the main menu finally loads: [WARN] [SDL]: Failed to create rumble effect for joypad 2: Haptic: Error uploading effect to the device: Connection timed out

This message only seems to be generated here, and only if joypad->rumble_effect is set to -1, or 'uninitialized' but presumably supported. (Only the first part of the message is generated there, "Failed to create rumble effect for joypad N:" - the rest comes from SDL. More on that later.)

This is done elsewhere in the file where the input is configured. There's a chance for it to be set to -2 (unsupported) if SDL_HapticEffectSupported returns SDL_False... but this clearly isn't happening, and perhaps it should.

The SDL2 function that seems to be returning an erroneous value that is allowing haptics to be enabled is quite simple. The SDL2 function that generates the "Haptic: Error uploading effect to the device:" portion of the error message is actually the linux-specific implementation of SDL_HapticNewEffect which lies here. It attempts an ioctl to send a EVIOCSFF and, if there is a problem, returns the friendly error name for 110 (ETIMEDOUT).

This is specific to force feedback, and not rumble like that used in a controller. The only source of non-rumble force feedback on the system is the Deck's touchpad buzzing - which makes a lot of sense, since it's in position 2 in my Steam Input list and RA is having problems with "joypad 2". I disabled Steam Haptics in the Steam Settings > Controller > Steam Deck menu and restarted my system. The problem has gone away entirely. This leads me to believe either:

• Steam Input's virtual devices are not passing the haptics of the Deck's controller along correctly. (seems most likely)
• The Deck's haptics hardware is non-compliant with existing standards. (seems middlingly likely)
• SDL2 is not detecting some new property of force feedback devices (seems unlikely)

I believe this could and should likely be fixed by Valve, but in the meanwhile, RA could resolve this issue by possibly discovering some way to not block the main thread in the frontend while loading force feedback effects

[tristianc]

Edit: proper workaround found. Steam Deck settings > Controller > Steam Deck > Steam haptics = OFF and reboot You lose the buzz on the touchpads until you set it back to ON and reboot, but the issue goes away.

I experience the issue described in the opening ticket and the proposed workaround works for me.

This is specific to force feedback, and not rumble like that used in a controller. The only source of non-rumble force feedback on the system is the Deck's touchpad buzzing - which makes a lot of sense, since it's in position 2 in my Steam Input list and RA is having problems with "joypad 2".

What controllers, outside of the Steam Deck, provide non-rumble force feedback? I ask in an attempt to duplicate this issue on a platform other than the Steam Deck.

[arbitar]

What controllers, outside of the Steam Deck, provide non-rumble force feedback?

I would assume relatively few. Possibly the original Steam Controller, as I believe it possessed a similar touchpad haptic feedback system in parallel with a conventional rumble system, though I do not own one to test. Force feedback systems are typically reserved for things like steering wheels and flight sticks and such and less so for non-physical rumble/vibration mechanisms, as more appropriate rumble mechanisms exist for this purpose. It is typically used in circumstances that call for some actual physical resistance or motion on the control interface: steering wheels that actually jerk to the side when you hit a virtual pothole, sticks that resist motion in some direction.

I believe this issue is largely limited to the Steam Deck because of Valve's (in my opinion) misclassification of the hardware as force feedback instead of rumble. It's understandable why this was done: they likely wanted to prevent naive game rumble routines from rumbling the touchpads along with the normal rumble motors when it just fires all the rumble motors on a given controller index, so they likely chose to preemptively circumvent the issue by classifying them as force feedback motors instead. Software "in the know" will use them properly, otherwise they'll be ignored. I believe Steam Input's implementation of these rumble systems as a force feedback device is incomplete, leading to this issue.

I ask in an attempt to duplicate this issue on a platform other than the Steam Deck.

As I chiefly suspect the culprit to be Steam Input, the virtual controller abstraction software that lies between real controllers and software seeking controller inputs on the Steam Deck, I suspect finding other controllers that exhibit this same behavior is relatively unlikely.

[tristianc]

The root cause of this issue is being tracked in libsdl-org/SDL#8071

[tristianc]

I can no longer reproduce the issue with the Steam client update released on December 11. Even with haptics enabled, RetroArch no longer hangs while I use a bluetooth controller.

[arbitar]

I can corroborate. The issue seems to be gone, even with haptics enabled. The RetroArch menu now appears immediately (as expected) and I don't see complaints about haptic effect upload errors.

Recommend closing the issue.