This reverts commit 2999634f29.
The physicalInputProfile mapping maps the touchpad to left thumbstick now, as the 2nd generation Siri Remote has both touchpad and cardinal direction D-Pad functionality
* Moving forward and backward don't clear the current binding
* Use the tertiary face button to delete the current binding
* More small improvements to make navigation more intuitive
Automatically map controllers as gamepads when using the GCController framework and prefer the physicalInputProfile when possible.
Testing with macOS 13.4.1, macOS 14.1.1, iOS 15.7.4, tvOS 17.1:
* iBuffalo Classic USB Gamepad (macOS only)
* Logitech F310 (macOS only)
* Apple TV remote (tvOS only)
* Nimbus MFi controller
* PS4 DualShock controller
* PS5 DualSense controller
* Xbox Series X controller
* Xbox Elite Series 2 controller
* Nintendo Switch Pro controller
* Nintendo Switch Joy-Con controllers
This specifically deals with two threads closing the same device at the same
time, and a thread trying to reopen the device as it's still in process of
being closed. This can happen in normal usage if a device is disconnected:
the OS might send a disconnect event, while the device thread also attempts
to manage a disconnect as system calls start to report failure.
This effort is necessary because we have to release the device lock during
close to allow the device thread to unblock and cleanly shutdown. But the
good news is that all the places that call ClosePhysicalAudioDevice can now
safely hold the device lock on entry, and that one function will manage the
lock tapdancing.
Otherwise, a disconnect/default change on another thread may cause the
device pointer to become invalid by the time the management thread runs the
task.
This can be used to work around issues where the Apple GCController driver doesn't work for some controllers but there's no way to know which GCController maps to which IOKit device.
This mouse actually enumerates as a gamepad with 2 axes, 8 buttons and a hat.
We'll ignore it like the other ROG mice, unless someone specifically wants to use it as a gamepad.
The hash table can be recursively locked from the same thread, which can cause issues with RWLocks, as locking them recursively can result in undefined behavior or deadlocks. Use a mutex instead, as it can be safely recursively locked.