-
Notifications
You must be signed in to change notification settings - Fork 628
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] Controller settings are not saved & [Feature Request] xinput implementation #577
Comments
SDL is used to avoid controller-specific code. Xinput is not going to be added, at least not officially. |
I understand, this may not even be a priority, I also understand that there is much more useful work than this, if there was a collaborator who could implement at least the two options, as in pcsx2 among others, it would be interesting, options are always welcome, think carefully perhaps in the future. |
havent you press apply when you change the input device? |
Yes, I pressed apply, I've tried creating the profiles too, it doesn't work, every time I turn off and on the computer and the controls, everything has to be redone, SDL is complicated, I know there are settings in SDL that save in other emulators, even old ones, like yabasunshiro, but the ideal would be to have an option to detect xinput. |
are you 100% sure? I just checked on my machine and the settings and my controller input is still saved |
I will give examples of the problems that occur. If you only use 1 controller (I use Xbox series X/S), the setting is kept for xinput 0, as long as you don't open the emulator with the controller turned off, otherwise the input device will be disabled. If you use 2 or 4 controls, the configuration gets mixed up, player 1 has xinput 1 and no longer 0, player 2 also has xinput 1. The entire configuration is lost, even if you set it correctly as I mentioned. Player 1: xinput 0 When opening the emulator again if the controls are turned off, everything will be lost, and if you open the emulator with the controls turned on, each player's input device will shuffle or simply use the same xinput. That's why I say that it would be very good to implement xinput support as an option in this emulator, because just like redream, flycast, duckstation, pcsx2, rpcs3, xenia, xemu, dolphin, etc... the configuration would be maintained, regardless of whether the control is connected with the emulator open or closed, nothing would ever be lost, in addition to the configuration always being set correctly. |
wait a second are you connecting your controller by bluetooth or wired? |
I connect all 4 by bluetooth, as I mentioned, older emulators such as yabasanshiro which only uses SDL, saves the settings, unfortunately ryujinx "forgets" the settings and disables the input if it doesn't find the connected controller, and even if I avoid opening the emulator with the controller disconnected, assuming that I only open it when the controllers are connected, it still scrambles the xinput order as I already mentioned... it's very sad, every time I open the emulator, I have to go in there and activate each control in the input and indicate one by one. |
Same here. This would be my number 1 issue to fix. |
Xinput does not always assign the same playernumber to the same controller, so this is normal, not really an issue. SDL is more stable |
Xbox controllers have that jank even when using their official API? |
Yes Xinput is a mess, sdl is the way to go. |
I was never going to add Xinput support, so cool I guess |
Well, I just suggested such an implementation, because in all other emulators it works without any problem, I have never seen such repulsion for a simple resource, if I had the necessary skill I would do such an implementation, because I believe that more options are always better than just one option, see dolphin, pcsx2, rpcs3, duckstation, xenia, xemu, flycast among others, well let's not discuss it anymore, if xinput is criticized here let's close this topic and depend only on SDL. |
Flycast only has sdl, not xinput |
If we add multiple input backends, it needs explaining what each one does, when to use it, etc. Simply adopting a completely foreign HID API for a very small subsection of users who will even get a benefit from it is not a way to solve this problem. |
I have xbox series x controller and don't have similar problem. |
Well, I had already closed this topic, but I will reopen it due to the continuity of the conversation, I will try to demonstrate with prints exactly what happens, I hope that this will be clearer for everyone. 1 - Doing the basics, we turn on all the Xbox controllers until they are paired with the PC. see the pictures everything is ok, perfectly defined Now let's see the following, I just closed the emulator and then opened it again and see what happened to the controls Absolutely nothing has changed in the connection of the controls, they are all active in Windows and paired, working perfectly. As I mentioned several times, I can open other emulators, and all the controls are perfectly defined, for example, I opened Dolphin and there they are all perfectly configured for a long time. I understand that implementing xinput may not be necessary, although it would be very useful for those who use controls like mine, but there are certainly problems in SDL that need to be fixed. As previously stated, absolutely no emulator I use presents this issue of simply "forgetting" the control settings, whether with SDL or xinput, not even citron, sudachi, yuzu and all the others for other consoles, so I kindly ask that you review why SDL in ryujinx does not keep my controls properly configured and enabled. |
What is strange is that i do not have this issue with same controllers ! Because if it does this in sdl, it will also do it with xinput or any other wrapper |
I have the same experience. Let me know if I can help debug this issue. The issue we are facing is more of an annoyance than a blocker. Controllers end up working. But we have to configure input settings each time we play, as the settings don't get saved. The input setup doesn´t persist between runs. I'm running the latest Ryujinx and I've tried with multiple 8bitdo/xbox/ps4 controllers. |
Ok, i have just tried with the following controllers:
I am unable to reproduce the issue. I save configuration, exit ryujinx, launch it again, and settings are still there and controllers still assigned. But this issue is not at all related to SDL vs Xinput, it's more about ryujinx not saving the configuration for your installation. Where did you install ryujinx ? Which folder ? |
I use the settings inside the "portable" folder, I checked the properties and both the folder and Config.json are not read-only. |
Thanks for reporting, they already thought I was crazy lol |
Can you try the following:
If there is a difference, it will allow finding the culprit, my guess is that it will be the guid of the controller... |
folder where ryujinx is installed = D:\Emuladores\Nintendo Switch\Emulador portable folder and config.json are not read-only I tried testing with version 1.2.82 and the same problem occurs I just noticed something interesting, I put just 1 of my controllers on the cable, and the settings were saved and kept, even after closing and reopening the emulator The controls are identified differently on Bluetooth and the cable and perhaps SDL is not knowing how to deal with this, it is something to be investigated. Bluetooth controls where the settings are not saved On-cable controls where problems don't occur and settings are maintained |
|
Ok, so what we can see, between 1 and 2, just by quitting ryujinx, there are already changes in the file. With your working configuration we get: Re-run, change nothing and close: (we just loose Player 4) After reconfiguration, we get brand new ids: @GreemDev : Is it something already seen ? I just tried with 2 controllers of exactly the same type (XBox One S) but did not encounter any such issue. |
And strangely this only occurs when the controllers are connected via bluetooth, where they are displayed as "Xinput Bluetooth LE compatible input device" but when connected via usb cable, and they are detected as "Controller (Xbox One for Windows)" no problem occurs. Are the controller IDs different when used via bluetooth? |
The fact that your xbox controller shows as bluetooth LE compatible device is problematic, it should show as Xbox Series controller... Maybe you should check the driver/firmware of the controller. |
They appear as Bluetooth LE compatible device because they are connected via Bluetooth and not through the original wireless adapter for Xbox controls that exists for PC, however, my Bluetooth is of excellent quality and is Intel Bluetooth 5.1 LMP11, which is already embedded on my motherboard, a Gigabyte B660M AORUS PRO AX. But this doesn't seem to be a problem caused by the way I connect the controls to the PC, since it's a problem exclusive to ryujinx, absolutely all the other emulators I use, none of them present a problem, and believe me, I use them a lot... PS: the firmware of all controls are up to date, v5.23.5.0 My database and emulators |
Even with bluetooth and whatever the bluetooth receiver, they should have their correct name and appear as Xbox controllers, not as Bluetooth LE compatible... |
I found these answers on google... What can happen when connecting an Xbox controller via Bluetooth? Number 3 is my case and applies to me. but strangely this doesn't affect anything I use, from PC games and other emulators, the only software that isn't keeping the settings really is just ryujinx, that's why I suggested the implementation of xinput as another option, somehow it seems that in bluetooth the controls enter as generic xinput devices, and there's something missing in the ryujinx SDL to work well with this. |
Xinput will not fix this, as xinput ids (from 0 to 3) will not be assigned always to the same controller, but at least they won't appear disconnected. But this should be fixed by ryujinx dev in sdl, it seems the code assigns different guids upon restart of app, which is messy.... |
This might be the culprit: Maybe... |
it looks like the controller IDs are directly obtained from SDL |
The fact that the guid changes upon application restart is very strange and indeed other emulators also use guid (pcsx2, citra forks, yuzu forks....) and do not show this behaviour. Maybe instead of using guid, just sdl index would be enough... |
i really do not want to break everyone's input configs because of, specifically, Xbox controllers users on Bluetooth lol |
I understand that with xinput the control in my hand will not always be player 1, it may simply be player 2 on the next restart, but what is certain is that both will connect without requiring any type of configuration, almost automatically. When I mention options it is because it is common in other projects, for example in pcsx2 I don't even turn on the SDL option... every time an emulator has an option for xinput, I just leave it turned on and there is no need to define any configuration, see how each control already goes to xinput0 or xinput1 by itself. But I don't want to be more annoying than I already am, I understood that the problem here is some code in SDL X Xinput via bluetooth, since other emulators that I use with SDL do not present a problem, but I am grateful that we finally found the source of the problem. |
It's already broken it seems. @williansti : can you try with older version 1.2.19 if you experience the same: |
I tested this version and unfortunately the same problem occurred. I also tried deleting the portable folder and letting it recreate the config.json in another location, but it also didn't save the control settings. I went further and also tested the old ryujinx, ryujinx-1.1.1402-win_x64, and the same thing happens, apparently it's a very old problem, strange that no one has ever reported this. |
So basically this issue is very limited to xbox series controller and only when they are in the case you explained hereover (recognized as generic xinput device). It can be fixable, but for this a dev with sdl2 minimal knowledge is required. |
Well, just saw someone on github with similar issue: Seems indeed like something is broken at controller level also in linux. What is still puzzling is that this happens only for some people, for others, with same controllers, there is no issue... And looking at the code, it uses standard sdl2 features, so absolutely no reason within this code for it not to work. |
@williansti , just a quick question, do you have Steam running in parallel ? (Even minimised to tray) |
I have steam but it is completely closed, and I leave his background disabled |
Video reproducing the problem recording-2025-02-18-22-24-45.video-converter.com.mp4 |
Overview
In my case I use original Xbox Series X controls, but every time I open the emulator, the input device is disabled. even though I leave everything right with player 1 using xinput 0 and player 2 using xinput 1, even creating a profile for each control, applying the settings and using them correctly, When I return to the emulator I have to do everything again, because nothing is saved. In short, the settings only work during use, they are not saved..
Smaller details
They could improve compatibility with xinput, implementing functionality like reicast, xenia, xemu or dolphin.
reicast already immediately detects any xinput control when triggered and sets each player to an xinput.
xenia and xemu detect xinput controls almost like a native console, no adjustments are required.
Dolphin, after all the configuration and usage indication for xinput 0: player 1, xinput 1: player 2, xinput 2: player 3 and xinput 3: player 4.
By doing all this and saving a profile for each player, the emulator does not forget the configuration and resumes correctly after each use.
Nature of request
Improve compatibility, efficiency and management of xinput controls in the emulator, so that the emulator "remembers" the settings.
Why would this feature be useful?
It would be useful to solve this annoying problem of every time you open the emulator, having to reconfigure all the controls again, for me and many others who use 4 controls, it is terribly sad, redoing everything every time you want to play.
The text was updated successfully, but these errors were encountered: