This is the first step of getting rid of the controller indirection
on Android. (Needing a way for touch controls to provide input
to the emulator core is the reason why the controller indirection
exists to begin with as far as I understand it.)
This lets the TAS input code use a higher-level interface for
overriding inputs instead of having to fiddle with raw bits.
WiiTASInputWindow in particular was messy with how much
controller code it had to re-implement.
This hack was added in 8f0cbefbe5, and the part of it in SI_DeviceGCAdapter is present on Android already, so I don't see any reason why this part doesn't apply to Android.
This is mostly a brainless merge, #ifdef-ing anything that doesn't match between the two while preserving common logic. I didn't rename any variables (although similar ones do exist), but I did change one log that was ERROR on android and NOTICE elsewhere to just always be NOTICE. Further merging will follow.
Loading configs while another thread is messing with stuff just doesn't feel like a good idea
Hopefully fixes Wiimote Scanning Thread crashes on startup
I am not confident there are no race conditions between s_write_mutex,
s_controller_write_payload_size, and s_controller_write_payload. But
this code should be safer than before.
s_controller_write_payload_size needs to remain an atomic because Read()
loads and stores without holding a mutex, Output() stores while holding
s_write_mutex, and ResetRumble() stores while holding s_read_mutex! I'm
pretty sure this code is wrong, specifically ResetRumble().
You can safely read or write non-atomic integers on multiple threads,
as long as every thread reading or writing it holds the same mutex
while doing so (here, s_mutex).
Removing the atomic accesses makes the code faster, but the actual
performance difference is probably negligible.
If libusb fails to initialize, an assertion fails, but if that happens before the main window is created, then Dolphin just dies. Now, the panic alert is properly shown and the user can ignore it.
If InputConfig::LoadConfig() was called once with a non empty/customized config,
then called again after manually deleting the config (dolphin calls LoadConfig() every time it opens the mapping widget),
the second load would fail to clear the values on any non first EmulatedController and would instead keep the
previous config values despite it being deleted (while it would instead correctly default the first EmulatedController).
This is not a big bug though the code is better now.
Fixes bug: https://bugs.dolphin-emu.org/issues/12744
Before e1e3db13ba
the ControllerInterface m_devices_mutex was "wrongfully" locked for the whole Initialize() call, which included the first device population refresh,
this has the unwanted (accidental) consequence of often preventing the different pads (GC Pad, Wii Contollers, ...) input configs from loading
until that mutex was released (the input config defaults loading was blocked in EmulatedController::LoadDefaults()), which meant that the devices
population would often have the time to finish adding its first device, which would then be selected as default device (by design, the first device
added to the CI is the default default device, usually the "Keyboard and Mouse" device).
After the commit mentioned above removed the unnecessary m_devices_mutex calls, the default default device would fail to load (be found)
causing the default input mappings, which are specifically written for the default default device on every platform, to not be bound to any
physical device input, breaking input on new dolphin installations (until a user tried to customize the default device manually).
Default devices are now always added synchronously to avoid the problem, and so they should in the future (I added comments and warnings to help with that)
Removed useless locks to DeviceContainer::m_devices_mutex, as they were all already protected by m_devices_population_mutex.
We have no interest in blocking other threads that were potentially reading devices at the same time so this seems fine.
This simplifies the code, and I've adjusted a few comments which mentioned possible deadlock that should now be totally gone.
The deadlock could have happen if a thread directly called EmulatedController::UpdateReferences(), while another another thread also reached EmulatedController::UpdateReferences() within a call to ControllerInterface::UpdateDevices(), as the mentioned function locked both the DeviceContainer::m_devices_mutex and s_get_state_mutex at the same time.
The deadlock was frequent on game emulation startup on Android, due to the UpdateReferences() call in InputConfig::LoadConfig() and the UI thread triggering calls to ControllerInterface::UpdateDevices().
It could also have happened on Desktop if a user pressed "Refresh Devices" manually in the UI while the input config was loading.
Also brought some UpdateReferences() comments and thread safety fixes from https://github.com/dolphin-emu/dolphin/pull/9489
TheConfuZzledDude