Ryujinx
Ryujinx copied to clipboard
Ryujinx
[Bug] Xbox One wireless controller power-off issue
Overview
As it is now, if the Xbox One wireless controller shuts off either due to sitting idle, or if the batteries die, the software of course issues a notification that the game requires at least one player, but any attempts to turn the controller back on fail. The controller light blinks a few times and then turns back off.
The only option is to shut down RyujinX completely, turn on the controller, and then relaunch the software. If the game hasn't been saved, this can be a problem.
Smaller details
No smaller details, this pretty much covers it.
Nature of request
Somehow alter the software to allow the controller to be turned back on and resume gameplay. Or if this is already present and requires a toggle, then make this toggle On by default.
Why would this feature be useful?
Goes without saying, really.
hold the power X button for 5-10 seconds and you power it off. It is something related to the drivers of the controller, not Ryujinx.
@BigEmperor26 Hello, thank you for your reply but I think there might be a misunderstanding. When you say to hold the power button for 5-10 seconds to power it off, I don't think that applies to the issue I described. The problem is not with being unable to power off the controller, but rather with being able to power ON the controller if it has powered off during use with RyujinX. There is something with the software that keeps the controller from being able to power back on while the application is active. As far as it being a driver issue, I suppose that may well be but other games that I use this controller with allow the controller to be powered back on if it has turned off. When RyujinX is running, I cannot power it back on. If I close RyujinX, I am then able to turn the controller back on and launch RyujinX again, so this leads me to believe RyujinX is, at least to some extent, the culprit.
Don't know the specifics, but it's something as follows: Upon losing power, the controller's disconnected state is saved in memory and every attempt to power-up the controller results in the application sending an immediate disconnect signal, shutting-down the gamepad. It will continue to do this until you restart the application (clear the volatile memory).
*An anxiety inducing bug, for sure, but also shame on Microsoft for not allowing customers to toggle the power saving feature on their controllers.
It would be great if someone could take a look at this, as it has become a real pain.
On top of what was already acurately described above, there is no work around, while Ryujinx is still running, to get the controller to turn back on, physically. Minimising the game and focusing elsewhere (ie. the Steam window for example) still does not return control of the controller. As soon as Ryujinx is closed, expected functionality is returned and the controller can be turned back on.
While this issue is under way the log is being utterly smashed with "Applet 'Controller' created" entries. This alone seems bad to me.
I will attach a clean log where I have started a game with the controller powered OFF. Waited ~10 seconds and powered the controller ON. I am then waiting idle until the controller turns itself OFF, waiting ~10 seconds and attempting to power it back ON again without success, then stopping emulation and exiting Ryujinx.
I hope this can help.
Ryujinx_1.1.804_2023-05-18_18-31-52.log
One workaround for this issue is to launch Ryujinx through Steam and use Steam Input. That allows the controller to power back on if it's power off or goes to sleep while Ryujinx is running.
@CraftyCorvid Hey thanks for the tip, I'll give that a try!
Edit: Confirmed this does work, so thanks again. Still, just a workaround and not a solution.
Update on using Steam Input: It does appear to introduce significant input latency for some reason, so it's not a great solution.
@RetroFrito IMO, I think you should re-label this as a bug. Given the software is directly impacting the expected behavior of the hardware.
If it was just Ryujinx not detecting the power-on event from the controller, that would be one thing. But whatever is going on is forcing the hardware back into a powered off state. Also, it does recognise the controller being powered on as I did this in my logging test, provided above, when initially starting the game. The feature you're asking for already exists but does not work when the controller idles, or powers off, in-game.
I believe this to be a duplicate of issue #3301 Both seem to describe the same input issue upon a disconnect. Bluetooth controllers seem to be able to recover, however wifi controllers don't. Which is a weird but maybe important difference. Plugging the controller directly into the PC with a USB cable and you can disconnect and reconnect at will with no issues, but it also randomly disconnects being plugged in after working for 10-20 seconds. So that's another interesting difference.
At the very least, I can confirm this is all the symptoms of my issue. It is completely impossible to recover Xbox Wi-Fi controller connectivity while ryujinx is up after a disconnect event. It really seems limited to specifically the wireless connection. Maybe it's how the emulator handles the USB dongle device?
@KaiserTom Before posting I did read the issue you referred to and the description of that issue does not match the description of mine, so I made a new post.
I tracked the issue down to a line in SDL2GamepadDriver.cs
IntPtr gamepadHandle = SDL_GameControllerOpen(joystickIndex);
It appears to indicate that there's an issue with SDL_GameControllerOpen causing the Xbox One controller to power off. I tried messing around with the SDL config values in SDL2Driver.cs but nothing seemed to make a difference. Not sure how to proceed with fixing this bug. It might be on SDL's side, although I imagine if it was it would be much more widespread and I can't seem to find any information on it online.
SDL_GameControllerOpen returns NULL upon an error. Is that handled anywhere? All I see is if (gamepadHandle == IntPtr.Zero) but IntPtr.Zero isn't NULL, it's 0.
So it looks like if SDL_GameControllerOpen returns a NULL to gamepadHandle, then that gets put into SDL2Gamepad(gamepadHandle, id); as a NULL value. Is that NULL handled in SDL2Gamepad.cs? It seems like it in fact tries to create a new controller with the NULL Index, which seems like a problem.
_gamepadHandle = gamepadHandle;
...
Name = SDL_GameControllerName(_gamepadHandle);
I don't think it has anything to do with the way Ryujinx handles errors from SDL. SDL_GameControllerOpen returns a valid gamepadHandle, not null or 0.
SDL_GameControllerOpenreturns a valid gamepadHandle, not null or 0.
Usually, but not all the time. Unless I'm missing or misinterpreting something, per documentation. "Returns a gamecontroller identifier or NULL if an error occurred"
Looking through the actual SDL source there's multiple places under SDL_GameControllerOpen where it returns NULL upon various errors.
I meant when this particular bug is triggered the function is returning a valid value.
I've been able to track this bug down to this commit in SDL.
Ryujinx works just fine with SDL.dll built from before that commit but that commit onward, this bug can be reproduced.
Even current builds of Ryujinx, if you replace SDL.dll with that one, this bug isn't reproducible.
Edit: It's even reproducible in the testgamecontroller.c test program in SDL.
Edit: In SDL_rawinputjoystick.c, when calling RAWINPUT_UpdateOtherAPIs() after RAWINPUT_JoystickOpen(), RAWINPUT_UpdateXInput() gets called, which tries to get the capabilities using XINPUTGETCAPABILITIES().
That function is what causes the controller to shut off. The only question is: How does this bug not occur in Yuzu when it occurs in Ryujinx and SDL's own testgamecontroller.c?
The answer: Yuzu, by default, doesn't enable XInput / RawInput (ref). If you go to Settings -> Controls -> Advanced -> Enable XInput 8 player support, you'll be able to reproduce that bug in Yuzu too.
Shared my findings in https://github.com/libsdl-org/SDL/issues/3468 too, although I'm not sure if it's the right issue.
Looks like SDL fixed the issue upstream in this commit: https://github.com/libsdl-org/SDL/commit/1da5b2e488cc53534de939ae3c56e5cca7230f73
This issue would be fixed once Ryujinx updates to a version of SDL that includes that commit.
Looks like SDL fixed the issue upstream in this commit: libsdl-org/SDL@1da5b2e
This issue would be fixed once Ryujinx updates to a version of SDL that includes that commit.
Can we get a pr for this, or does it introduce some other problems?
@wwwizzarrdry Need to get a release of SDL to get the fix in SDL-CS as I don't think SDL-CS uses a dev build of SDL.
Is there any way for users to work around this issue in Ryujinx until the fix can get into SDL-CS and then pulled over into Ryujinx releases?
@mbouington Yes, there was an earlier post. Users can add Ryujinx into Steam and launch it from there. I've confirmed this gets around the issue.
Not really a useful workaround though as this causes Ryujinx to spit out thousands of "FOSSILIZE shader cache location" errors. Doesn't prevent the game from launching, but the resolution gets messed up which makes it unplayable as a non-Steam game.
I.E. the resolution is so small (640X480 maybe?) that the view gets zoomed-in on the lower right corner of the screen and you can't see anything. Additionally there is a huge white bar outlining the right and bottom sections of the screen when I launch from Steam with "Path/to/ryujinx.exe" --fullscreen --profile "MyPlayer" "Path/to/Game.xci"
It's just better to use Yuzu for now. Both are great emulators.
@wwwizzarrdry Interesting as I have not experienced this on my end. Granted I have not gone looking for the errors so I can't attest to that, but I haven't noticed any performance drops by launching from Steam.
The easiest solution I've found is to build SDL2.dll yourself using the latest SDL2 main branch, then replace that in the Ryujinx folder. That's what I've been doing.
They only have 1 bug to fix before the next SDL2 release though!
Now someone needs to update https://github.com/Ryujinx/SDL, and then build https://github.com/Ryujinx/SDL2-CS
I have no idea what to do about the conflicts in https://github.com/Ryujinx/SDL, otherwise I'd create a PR myself. @marysaka might know?
confirmed that replacing the SDL2.dll file in the Ryujinx folder with one from the latest release of SDL resolves the issue ✨🙆✨
Now someone needs to update https://github.com/Ryujinx/SDL, and then build https://github.com/Ryujinx/SDL2-CS
I have no idea what to do about the conflicts in https://github.com/Ryujinx/SDL, otherwise I'd create a PR myself. @marysaka might know?
A new release was made some days ago on nuget, going to PR an update (I forgot oops)
