Controller Hotplug/Swap Handling Improvements

[AL2009man]

during the work from #1086, @protocultor has been providing guidance on how some of the code works. But, they wonder if the current HID Driver handles Controller Slot. Given Sonic Unleashed is a Single-player game, it would make more sense to have a connected controller be Player 1, given Sonic Unleashed is a single-player only game.

After investigation, it turns out: there wasn't one in place. So, I've spent most of the day investing and troubleshooting it in between adding Steam Virtual Gamepad.

Originally: I looked at a SDL_CONTROLLER_TYPE_VIRTUAL setup, but ultimately went with a more semi-complicated FindFreeController / Controller State management setup that aims to prioritized Player 1 whenever Player 2/3/4 is connected.

This method ensures that Steam Deck's docked users are able to get a more seamless experience if they decided switching to a Docked setup while in-game.

But given this is a more involved process that requires multiple controllers (ideally: controllers that has RGB Lightbars like DualShock 4 and DualSense controllers...and maybe Xbox Elite Series 2?), This is the part where I'll need help conducting a series of test to ensure it goes smoothly before I make it ready for a review.

• Linux build.
• Lightbar respects Player 1. Otherwise: it'll try to revert to Player LED lights until the next in-game event (refer to PlayStation Lightbar/LED Events doesn't function if Single or Multiple controllers are connected or reconnected. #1190)
• Ensures that Cutscenes' lightbar changes still works as intended
• Steam Deck's internal inputs under Game Mode (Steam Input is enabled by default)
• Testing the way how multiple controllers (minus for Nintendo Switch Joy-Cons) are connected simultaneously without the entire .exe file to leak and cause a computer reboot.

the Steam Deck portion is the one I have access to, and I can test it myself once the flatpak file gets added to GitHub Actions. The others: I'll need help from contributers on testing them out.

[AL2009man]

I rebase the entire PR in order to ensure any changes from Steam Virtual Gamepad and Face Button layouts aren't affected. That being said: the good news is that this PR will be ready for review.

this PR now has a Virtual Controller setup (it's not a TRUE Virtutal Gamepad type, for obvious reasons), where Player 0 is detected: Player LED should not turn your Gamepad into "Player 2". It play nicely with Steam Deck's onboard inputs and easier controller swapping controllers mid-game. It's not exactly perfect, but it should do the job's done.

additionally: PlayStation Lightbar will now play nicely with Player Indexs beyond Player 1. it should now change the lightbar color that corresponds to the game, this is a very hacky workaround due to Lightbar changes being tied to Player 1.

I could try else method like this code session:

    // Fetch the lightbar color for Player 1
    uint8_t r = 0, g = 0, b = 0;
    if (App::s_isWerehog)
    {
        r = 22; g = 0; b = 101; // Night color
    }
    else
    {
        r = 0; g = 37; b = 184; // Day color
    }

but I have noticed that the Day color's lightbar color isn't consistent, as it makes the Lightbar color far more brighter. I don't know the exact Lightbar color it really uses for "isDayTime".

As outlined in the thread: I'm still requesting additional testings.

[AL2009man]

temporarily revert back to Draft PR. will need Steam Virtual Gamepad PR to be merged first. Makes it a lot easier to verify the Hotswap changes on Steam Deck.

Since then: I added a fallback lightbar mechanic. During Day-Time: the lightbar will be more consistently blue, while simultaneously ensuring that all Controllers with RGB Lightbar functions will follow and respect it. it's more of a hacky workaround for the time being.

Right now: Cutscene portions (the part where Sonic turns into Werehog or revert back) will need to be tested. I actually got to test it in my end, and the cutscene didn't change my PlayStation's lightbar right away.

[hyperbx]

I'm not really sure of the point of this PR? We don't directly use the g_controllers array for input access, that's more of a leftover from an earlier implementation.

What's really being polled is g_activeController, so the events for controllers connecting and disconnecting should probably just overwrite that single instance and the array should be omitted outright. Then for fixing the LED problem, you could just turn off the LED on the disconnect event and refresh it on the connect event instead.

[AL2009man]

I'm not really sure of the point of this PR? We don't directly use the g_controllers array for input access, that's more of a leftover from an earlier implementation.

What's really being polled is g_activeController, so the events for controllers connecting and disconnecting should probably just overwrite that single instance and the array should be omitted outright. Then for fixing the LED problem, you could just turn off the LED on the disconnect event and refresh it on the connect event instead.

as stated: it's meant to improve Controller Detection, especially on Steam Deck's docked setup while addressing the Lightbar function (not to be confused with Player LED of Xbox 360/DualSense).

That being said: I did gave it a shot on making g_activeController the primary setup, but went thru a couple of issues that makes it a no-go. (one of them breaks button prompt detection when Steam Input is in use). I'll give it a shot again at some point-- got occupied with other stuffs.