Homebrew programs seem to rely on getting a reply to the vendor
specific commands, without which Bluetooth initialisation will never
complete.
This vendor-specific command is typically used to patch the Wii's
Bluetooth module, so the replies are only faked when the passed through
adapter is not a Wii Bluetooth module.
This stores the address of paired devices and associated link keys.
It is needed because some adapters forget all stored link keys when
they are reset, which breaks pairings because the Wii relies on the
Bluetooth module to remember them.
It doesn't fix adapters that can't remember any link key
at all and always return 0 for the number of stored/written link keys.
For those adapters, there is no fix.
This also improves the usability of passthrough mode for adapters that
already work, since pairings will now keep working even if the link
keys get cleared by something else (for example by the host Bluetooth
stack).
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)
Apparently, Nintendo's Bluetooth stack expects the ACL packet buffer
size to be limited to 10.
Reporting anything higher than that could cause memory corruption,
which can result in warning messages in the logs ("event mismatch"),
and more annoyingly, random disconnects.
Thanks to shuffle2 for the fix!
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).
This moves the unordered_map used to store connected Wiimotes IDs to
WiimoteReal, and makes the ID insert/erase logic common so we don't
have to duplicate this code in scanner backends.
The Balance board detection logic is already implemented in a simpler
way in Wiimote::IsBalanceBoard() (since hidapi also needs it).
Therefore, IOWin now only needs to check if a device is a Wiimote.
This is intended to make reconnecting Wiimotes easier with a DolphinBar.
Unfortunately, this change isn't enough as it doesn't always catch
disconnections for Wiimotes connected with a DolphinBar.
But it's better than nothing and eventually a disconnection will be
detected when something tries to write to the Wiimote, instead of never.
There is no other solution as the DolphinBar always exposes 4 HIDs even
when the associated Wiimotes are not connected.
We could try to detect this using the fake input reports sent by the
DolphinBar, but this only works for the first HID (probably because of
a bug in the firmware?), so this method is not an option.
If FindWiimotes() took more time than the UI shutting down, the scanner
would try connecting a Wiimote and sending an event to the UI code
long after it has shut down, which causes a segfault.
This fixes the race by ignoring any found Wiimotes during shutdown.
Normally this would have never happened, but it is possible with hidapi
since Wiimotes can be connected before Dolphin starts.
wxWidgets causes a segfault if Host_ConnectWiimote is called and we try
to create an event from the Wiimote scanner thread while the GUI is
still initialising.
Based on ca0c2efe7a. Credits go to flacs.
However, unlike the original commit, hidapi does not completely replace
the current implementations, so we can still connect Wiimotes with 1+2
(without pairing).
Also, it is only used on Linux and OS X for now. This removes the
advantage of having only one implementation but there is no other
choice: using hidapi on Windows is currently impossible because
hid_write() is implemented in a way that won't work with Wiimotes.
Additionally:
* We now check for the device name in addition to the PID/VID so we can
support the Balance Board and maybe third-party Wiimotes too. This
doesn't achieve anything with the DolphinBar but it does with hidraw.
* Added a check to not connect to the same device more than once.
Should fix a possible reference to deleted framebuffers, as well as fixing
the issues with the render area being correct if the game's source area
changes, or auto-scaling is enabled.
Same thing but allows both GeckoCode and Code to be utilized directly
without predicates for equality/inequality in stardard algorithms
The size check for std::vectors is unnecessary, as this is built into std::vector's operator==
Léo Lam