This lets us get rid of the Reset call in ProcessInputPayload, which was
causing us some threading headaches (see 74ed5e5532). Instead we handle
disconnection in the same way as the libusb implementation does.
We can register a BroadcastReceiver to have Android tell us when a GC
adapter gets connected instead of having a loop where we continuously
call SleepCurrentThread(1000) and poll the current status. When waiting
for a GC adapter to connect, this both reduces power usage and improves
responsiveness.
Note that I made openAdapter get the UsbDevice that's been stored by the
hotplug code instead of having openAdapter find the UsbDevice on its own
like before. This is only because I want to ensure that the UsbDevice
being tracked for disconnection is the same as the UsbDevice actually
being used, in case the user has multiple adapters connected.
Remove the redundant s_populate_mutex and only use
ControllerInterface::m_devices_population_mutex instead to prevent a
deadlock caused by locking them in opposite orders.
The device population functions in the win32 InputBackend previously
locked s_populate_mutex first before calling various functions that
locked m_devices_population_mutex. This normally worked but
ControllerInterface::RefreshDevices locks m_devices_population_mutex
first and then calls HandleWindowChange which then locked
s_populate_mutex, potentially causing the deadlock.
Fix this by using PlatformPopulateDevices to lock
m_devices_population_mutex before running the code that was previously
protected by s_populate_mutex. The functions in question lock
m_devices_population_mutex anyway, so this shouldn't meaningfully
increase contention on the lock.
Reproduction steps:
* Let Dolphin finish startup.
* In Win32.cpp::OnDevicesChanged set a breakpoint on the call to
PlatformPopulateDevices. When the breakpoint is triggered the function
will have locked s_populate_mutex, but since PlatformPopulateDevices
won't have run yet m_devices_population_mutex will still be unlocked.
* Unplug a device from your computer.
* Wait for the breakpoint to trigger. (At this point you can plug the
device back in).
* Freeze the ntdll.dll!TppWorkerThread() that triggered the breakpoint.
* Resume Dolphin and start a game.
* Core::EmuThread will call ControllerInterface::ChangeWindow which
calls RefreshDevices. It locks m_devices_population_mutex, then calls
InputBackend::HandleWindowChange, which tries to lock
s_populate_mutex.
* Unfreeze ntdll.dll!TppWorkerThread().
At this point EmuThread and TppWorkerThread are deadlocked. The UI is
still responsive since the Host thread is unaffected, but trying to stop
the game or close Dolphin normally will fail since EmuThread is unable
to stop.
Without this, there was a bug where if you turned the device's screen
off and on again while in the advanced mapping dialog, the input
indicators would stop updating. This is because turning the screen on
again causes devices to refresh, which causes all devices to be
recreated, leaving the AdvancedMappingControlViewHolders stuck
referencing controls belonging to devices that are no longer being
updated.
Verify a touchpad is present before polling it for input. Without this
check the Debug log is spammed with the message "error: Parameter
'touchpad' is invalid" if you have a controller without a touchpad.
One would think every touchpad supports at least 1 finger, but in case
there's some weird edge case check the finger count to be sure.
This is an Android continuation of bc95c00. We now call
InputDetector::Update immediately after receiving an input event from
Android instead of periodically calling it in a sleep loop. This
improves detection of very short inputs, which are especially likely to
occur for volume buttons on phones (or at least on my phone) if you
don't intentionally keep them held down.
