Open TheStremon opened 5 years ago
This is done on purpose by RA due to a limitation of (or maybe my understanding of?) the USB support of the operating system (at least on Windows and Linux, this seems to be the case).
Basically, reading from the Bliss-Box in a raw mode in order to get the connected pad type causes RA's input driver (which has already opened the device for reading button presses) to show the Bliss-Box port as being unplugged and re-plugged, leading to an infinite loop.
The only solution I can think of is to make this raw mode Bliss-Box pad check before the input driver opens the device, but this would mean every instance of RA would have to explicitly check for a Bliss-Box without first knowing that one exists, which is an approach I'm fairly certain @twinaphex would disagree with.
Wait, so the controller type detection is supposed to be broken? I don't understand, why was it implemented in the first place if it's not supposed to work correctly? Also is it normal the detection is working correctly at first RA startup? Because the drivers/controller wasn't loaded yet maybe? Or am I misunderstanding something? I mean the Bliss-Box dev told me himself this detection was supposed to work perfectly on RA, and was confirmed by the devs who worked on it. And you're telling me it never worked due to the way RA behaves? I'm lost here, there might be some miscommunication somewhere.
Wait, so the controller type detection is supposed to be broken?
That wasn't the intention when I wrote it, but I didn't know the OS would behave the way it does.
why was it implemented in the first place
The alternative is to not know the pad type at all, making it fairly useless.
is it normal the detection is working correctly at first RA startup
Yes, because when the program starts, it has no concept of a previous pad type. It can only store the last detected pad type when there is one. From that point on, any disconnect/reconnects will just re-use the last saved type instead of querying for a new one, because that will create an infinite loop.
Ulao may be mistaken or just misunderstood/didn't know about this particular RA limitation. I had completely forgotten about it myself until I tried to "fix it" once you posted this issue, then realized what was going on all over again... and I'm the one who originally wrote all the Bliss-Box code in RA.
But yes, it always required a restart due to this issue.
I see, that makes sense. Thanks for your explanation.
First and foremost consider this:
Description
I got a detection issue with the Bliss-Box (Gamer Pro one port model). Retroarch only detects the first controller type it was started with. When connecting another controller, RA does see the new connection but only sees it as the first controller connected. There is no problem with the Bliss-Box device itself outside of RA, I tested it with the dev.
Expected behavior
RA should recognize the newly connected controller type when I change it and push the BlissBox reset button.
Actual behavior
RA detects the new connection, but always sees it has the same controller, the one that was connected at RA startup. Only restarting RA makes it detect the newly plugged controller.
Steps to reproduce the bug
Bisect Results
It was always the case since I started using the Bliss-Box.
Version/Commit
You can find this information under Information/System Information
Environment information
Additional Information
In case it's needed, you can find my log file attached, showing the issue. I start RA with a GC controller, then switch to Snes, then to Saturn. RA always saw the controller as the GC controller. (of course if I started RA with the Saturn controller, it would have stayed on it instead of the GC one) retroarch-log.txt