Let's stop pretending that we support Triforce emulation.
Keeping this code around just in case someone will make
major improvements in the future isn't really worth it.
I'm keeping the Triforce game INIs so users will know that
the compatibility rating for Triforce games is 1 star (broken).
This changes Refresh() to use the existing scanning thread to scan for
devices, instead of running the scan on the UI thread and blocking it.
Also makes the UI thread not block when Continuous Scanning is disabled
and removes duplicated code.
Should fix issue 8992.
Under the hood:
* The scanning thread is now always active, even when continuous
scanning is disabled.
* The initialize code which waits for Wiimotes to be connected also
uses the scanning thread instead of scanning on yet another thread.
* The scanning thread now always checks for disconnected devices, to
avoid Dolphin thinking a Wiimote is still connected when it isn't. So
we now check if we need new Wiimotes or a Balance Board at scan time.
The Wii U Gamecube controller adapter setup has always been a bit weird. It tries to be as automatic as possible to make the user experience as easy
as possible.
The problem with this approach is that it brings a large disconnect in the user experience because you have the Gamecube controller setup with regular
gamepads and then for some reason below that you have a "direct connect" option which will cause the Gamecube Adapter to overwrite the regular inputs
if something was connected.
While this works and allows the user to only click one checkbox to get the device working, it breaks the user's experience because they don't really
know what "direct connect" means and won't look it up to figure out what it is. Just expecting the device to work (At least one occurence of this in
the IRC channel in the last week).
This way around also had the terrible nature of making the code more filthy than it needed to be. The GCAdapter namespace was parasitic and hooked in
to the regular GC Controller SI class to overwrite the data that it was getting from the default configuration.
Now instead we have a specific SIDevice class for the Wii U Gamecube adapter. This class is fairly simple and is a child of the regular SI Gamecube
Pad device and only reimplements what it needs to.
This also gives the ability to configure controllers individually, which allows the user to configure rumble individually per pad input.
Overall the code is cleaner, and it fits more in line with how the rest of Dolphin works.
The goal of this commit is to let people who experience driver issues
with libusb and windows disable the scanning thread (to avoid mouse
issues, keyboard issues, and audio issues).
Also disable the rumble setting when the adapter driver is not detected,
and don’t do anything if libusb can’t init for some reason.
Static strings can not be translated until wxLocale is initialised.
This reverts commit 0004b6004b.
Conflicts:
Source/Core/DolphinWX/VideoConfigDiag.cpp
This scanning thread either polls libusb or checks every 500ms for a
change depending on host capabilities. The GC Adapter can now be plugged
and unplugged at any time when dolphin is open, it will be used if the
direct connect option is set.
The libusb driver must be installed on the adapter (e.g. zadig can be used to install the driver in Windows). GameCube pad controllers are supported and will override the current input device assigned to the port. GameCube controller buttons are auto-configured and cannot be re-assigned. Rumble is supported. Hotplug is supported while playing a game. If a controller is unplugged from the adapter, Dolphin will fallback to using the host input device on that port. If a port on the adapter is unused, Dolphin will use the host input device for that port, allowing a mixture of host input devices and controllers connected to the adapter.
The adapter support can be disabled in the Controllers config if the OS driver is preferred (allowing the pad buttons to be reconfigured).
One adapter per system is supported.
JosJuice