-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Xbox One wireless controller power-off issue #4973
Comments
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. |
Don't know the specifics, but it's something as follows: *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. |
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 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
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. |
So it looks like if
|
I don't think it has anything to do with the way Ryujinx handles errors from SDL. |
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 |
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 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 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 libsdl-org/SDL#3468 too, although I'm not sure if it's the right issue. |
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 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! |
SDL 2.28.0 is out now with a fix for this 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? |
confirmed that replacing the |
A new release was made some days ago on nuget, going to PR an update (I forgot oops) |
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.
The text was updated successfully, but these errors were encountered: