This adds hotplugging support to the evdev input backend. We use
libudev to monitor changes to input devices in a separate thread.
Removed devices are removed from the devices list, and new devices
are added to the list.
The effect is that controllers are usable immediately after plugging
them without having to manually refresh devices (if they were
configured to be used, of course).
Changes UpdateInput() to skip if we can't lock the mutex, instead of
potentially blocking the CPU thread and causing a short but noticeable
frame drop.
This adds RemoveDevice() to ControllerInterface, fixes ExpressionParser
and some other code to support device removals without crashing,
and adds an IsValid() method to Device, to prepare for hotplugging.
This adds RegisterHotplugCallback() to register a callback which will
be invoked by the input backends' hotplug threads when there is a new
device, so that Core (GCKeyboard, GCPad, Wiimote, Hotkey) can reload
the configuration without adding a dependency to Core from InputCommon.
This makes the device ID assigning code common to all backends, by
moving it to AddDevice() instead of copy-pasting or replicating
the logic in the backends.
Also, to prepare for hotplugging, instead of relying on a name usage
count, the new ID assigning system always starts from ID 0 and tries
to assign the first ID that is not used.
Small cleanup by using std::shared_ptr and getting rid of
ciface.Devices() which just returned the m_devices (which defeats the
point of making m_devices protected).
Incidentally, this should make the code safer when we have
different threads accessing devices in the future (for hotplug?).
A lot of code use Device references directly so there is
no easy way to remove FindDevice() and make those unique_ptrs.
Previously, the devices vector would be passed to all backends. They
would then manually push_back to it to add new devices. This was fine
but caused issues when trying to add synchronisation.
Instead, backends now call AddDevice() to fill m_devices so that it is
not accessible from the outside.
Currently only works on unix, but can be extended to other systems. Can
also be extended to do wiimotes.
Searches the Pipes folder for readable named pipes and creates a dolphin
input device out of them. Send controller inputs to the game by writing
to the file. Commands are described in Pipes.h.
Using SDL_INIT_JOYSTICK implies SDL_INIT_EVENTS which installs a signal
handler for SIGINT and SIGTERM. There will be a way to prevent this in
2.0.4 but for now we'll need to handle SDL_QUIT.
- Simplified the locking mechanism when controllers were updated
- Reloaded the config of the controls instead of re-initialising the control plugins
- Fixed controls being unresponsive after the Refresh button was pressed
- Disables the hotkeys while the controller config is open
I'm not sure when this nonsense of forcing locking the mutex when it's
already taken should have ever taken effect, but let's be thankful it
isn't now. That was a badly worded sentence.
Initialize now just takes the handle directly. Reinitialize is added because it is much more straightforward in comparison to doing the Shutdown-Initialize manually.
Yes, this is a fancy new feature, but our Wayland support was
particularly bitrotten, and ideally this would be handled by a platform
layer like SDL. If not, we can always add this back in when GLInterface
has caught up. We might be able to even support wxWidgets and GL
together with subsurfaces!
It was broken by e15ec56bf0 because it wasn't deemed important. However chances are people will eventually start using Dolphin on that configuration, so we shouldn't frivolously drop compatibility without good reason.
Léo Lam