Making changes to ConfigManager.h has always been a pain, because
it means rebuilding half of Dolphin, since a lot of files depend on
and include this header.
However, it turns out some includes are unnecessary. This commit
removes ConfigManager includes from files which don't contain
SConfig or GPUDeterminismMode or GPU_DETERMINISM (which means the
ConfigManager include is not used).
(I've also had to get rid of some indirect includes.)
The ControllerConfigDiag design was getting confusing, so more
significant changes needed to be done.
Firstly, the GC controller and the Wiimote section layouts have been
aligned for consistency.
The Balance Board source chooser is a checkbox.
The "general settings" that affect the SYSCONF have been moved to the
Wii pane in the Config dialog. It makes more sense because those
affect the Wii's settings in the NAND, unlike the other options.
Another reason for moving it is that the Controller Config Dialog was
getting pretty crowded, and the whole section is disabled when
emulation is running, which is wasted space.
The Wiimotes section is now organised by two radio buttons. One is for
the Passthrough Mode, with sync/reset buttons under it; the other is
the emulated Bluetooth mode, which still has the regular Wiimote source
choosers, the Continuous Scanning controls and the Enable Speaker Data
option (which only applies to the emulated BT mode).
Hopefully this should make things a bit clearer and look cleaner.
(This is a monolithic commit because separating UI changes is hard)
This adds the ability to passthrough a whole Bluetooth adapter and skip
the majority of the Bluetooth emulation code. We use libusb to send HCI
commands, receive HCI events and transfer ACL data directly to the
first adapter that is found or to a specific adapter (if configured to)
This is possible because the Wii's Bluetooth module is actually just
a pretty standard Bluetooth adapter…
…except for two vendor-specific commands, for which replies are faked,
and also for the sync button. This adds a hotkey that works in the
exact same way as the sync button would on a Wii: it triggers an HCI
event, which emulated software interpret as a command to perform
a BT inquiry.
This commit also changes the UI code to expose passthrough mode
and WII_IPC_HLE to be a bit more thread safe (for the device map).
The 'revert' functionality is some very old left-over and isn't even working properly (read: could break Wiimote mapping). As no dialog features any cancel and revert functionality it is removed.
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.
