RPCS3
"HORI. Real Arcade Pro.V HS 1" stops working with HIDAPI error after stop game, open Pads panel
Quick summary
My arcade stick, correctly reported by RPCS3's Configuration-Pads-SDL handler as "HORI. Real Arcade Pro.V HS 1," stops working after running certain games, then opening Configuration-Pads.
Details
The arcade stick may also stop working after running the game 2 to 3 times, without opening Configuration-Pads.
It may also stop working simply after opening Configuration-Pads multiple times, although this is much less reliable.
The most reliable, though not quite 100%, repro case is:
- With the HRAPV stick plugged in to a USB port on the PC, in PS4 or PS3 mode, run RPCS3
- Go to Configuration-Pads and set "Handlers" to "SDL"--""HORI. Real Arcade Pro.V HS 1" should populate in the "Devices" field
- Click "Save" to close Configuration-Pads
- Close RPCS3
- Run RPCS3
- Launch Virtua Fighter 2 (NPUB30928)
- Once the game's own screens appear, Stop the game
- Go to Configuration-Pads == For the SDL Handler, shown by default, under Devices, instead of the arcade stick's name being shown, "No Device Detected" appears, with the field greyed out
If the arcade stick's name is still shown under "Devices" instead of "No Device Detected," repeat steps 6 through 8; the issue will usually reproduce within three tries.
At this point, the following line, in magenta font, will have appeared in RPCS3's log:
E SDL: Could not open device 0! SDL Error: HIDAPI device disconnected while opening
I've also reproduced the issue when using two other games: Fighting Vipers (NPUB30929) and Midway Arcade Origins (BLUS31083). I was unable to reproduce the issue with the only other game I currently have installed, Demon's Souls (BLUS30443).
The repro steps above were without "Keep Pads Connected" and "Pad Handler Mode" - "Multi-threaded" being set under Configuration-Input/Output. The problem still occurs with those options set.
Once the problem occurs, the arcade stick will not work again in RPCS3 until RPCS3 is closed and restarted; leaving RPCS3 open and unplugging/replugging the stick does not correct the issue, nor does switching to a different Handler and back to SDL again, or clicking the "Refresh" button under Handlers: Devices remains grayed-out with "No Device Detected."
Attach a log file
Attach capture files for visual issues
No response
System configuration
Operating System: Windows 11
CPU: i7-10750H
GPU: GTX 1660 Ti Driver version 535.98
Other: 16 GB RAM S271HL NVIDIA High Definition Audio
Other details
No response
The earliest build in which I am able to reproduce the issue is 0.0.32-16621:
- https://github.com/RPCS3/rpcs3/pull/15722
- https://github.com/RPCS3/rpcs3-binaries-win/releases/download/build-7e27e1420e9bf6545a6f642987f56ac335649bcd/rpcs3-v0.0.32-16621-7e27e142_win64.7z
It's been easier to repro in these older builds than in the current one; in 0.0.32-16621 and some other slightly more recent builds I tested--the most recent I happened to test, aside from the current build, being 0.0.32-16754--all I had to do for a 100% repro case was:
- extract the compiled Windows download to an empty dir
- run the .exe
- in the opening dialogue check the two bottom boxes and confirm
- click No when asked if you want to update
- click the Pads icon
- set Handler to SDL (here my Hori arcade stick auto-populates in "Devices")
- click Save
- click the Pads icon again == "Devices" now says "No Device Detected"
Whereas in the current build, 0.0.32-16830, it may take 8 tries or so of clicking Pads and closing it with ESC to get "No Device Detected" to appear.
I did test the build before prior to 0.0.32-16621, ie 0.0.32-16620, more thoroughly as well, installing and running VF2 etc, and was unable to reproduce it there at all.
It seems to be a bug in SDL. We used to create and destroy the SDL instance on each game boot or pad settings dialog. But since they apparently have a bug in MacOS in SDL_Quit, we now have one instance throughout the entire lifetime of RPCS3. The internal state of that instance seems to be broken after opening and closing the device a bunch of times.
Commit 18a99a7d8fa9d6a10d80d50dbc44ec5c9bccd8a2 ("input: use static hid singleton for init and exit") sounded promising, but the issue still reproduces in 0.0.33-16949-4ba5bd1 Alpha, whose latest build notes included that commit. (I just clicked the Pads icon and closed it with ESC a few times with the arcade stick plugged in and handler set to SDL.)
please try if the attached rpcs3.exe fixes your issue and eventually provide your rpcs3.log file
In the Pad menu you can only select and refresh the handlers. Stick movements etc. are disabled
please try if the attached
rpcs3.exefixes your issue and eventually provide yourrpcs3.logfile In the Pad menu you can only select and refresh the handlers. Stick movements etc. are disabled
I get an error running that version of rpcs3.exe:
"rpcs3.exe - System Error
The code execution cannot proceed because opencv_world4120.dll was not found. Reinstalling the program may fix this problem."
That's because you are not on recent build. Unzip the attached file in the rpcs3's main folder
That's because you are not on recent build. Unzip the attached file in the rpcs3's main folder
With that rpcs3.exe and opencv_world4120 pasted into the current Windows release build (RPCS3 Version: 0.0.37-18022-9c93ec0b Alpha | master), I followed the original repro steps and the problem reproduced on the first try. Log attached.
@smbhax please test v0.0.29-15422 and v0.0.29-15426. 15422 is the last working build for me. The issue is present since 15426 on my env
@smbhax please test v0.0.29-15422 and v0.0.29-15426. 15422 is the last working build for me. The issue is present since 15426 on my env
I've just tested those two builds and was unable to reproduce the issue in either of them.
As I mentioned on Aug 15 2024, the earliest build in which I've been able to reproduce the issue is 0.0.32-16621.
The error is present on my env even before v0.0.32-16621. Tested with multiple controllers even on v0.0.32-16620 (good for you) and got the error:
SDL: Could not open device 1! SDL Error: IDirectInputDevice8::SetCooperativeLevel() DirectX error 0x80070006
It seems the issue is not due to an SDL PR or SDL version update but probably due to v0.0.29-15426 (#14403) (a non SDL PR) randomly triggering the issue on SDL. I see atomic, shared pointers etc. on that PR. Probably a data corruption. That PR is also reported as a regressing PR for other kind of issues (#15088, #14663, #14546)
I think I found the issue at least on Windows.
Please test the attached binary (it is based on latest version v0.0.37-18143).
It is properly working for me. I can move to Pad menu, start games etc.
I think I found the issue at least on Windows. Please test the attached binary (it is based on latest version v0.0.37-18143). It is properly working for me. I can move to
Padmenu, start games etc.
Using that exe, I cannot reproduce the Configuration-Pads-Devices field depopulating, as happens in the original repro case.
However, with that exe, the controller is unresponsive, both in the game and in Configuration-Pads.
@smbhax it seems you got different results than me and other users but that is good to narrow the bug.
Please test the attached binary.
Based on your latest results (unresponsive in game and in Pad menu), I would expect it will be good in game but possibly still unresponsive/disconnecting in Pad menu.
@smbhax it seems you got different results than me and other users but that is good to narrow the bug. Please test the attached binary. Based on your latest results (unresponsive in game and in
Padmenu), I would expect it will be good in game but possibly still unresponsive/disconnecting inPadmenu.
This one works fine in the configuration menu and in the game.
In fact, the last one did, too; I was mistakenly looking for visual feedback when pressing controls in the config menu, and an old custom gamepad configuration for the game I was testing seems to have been what was causing the controller not to respond in game--once I deleted that, it worked fine. So, the unsuccessful test on the previous version of your .exe was purely user error, sorry about that!