There was a bug that caused MemoryView to indirectly cause a segfault;
the simplest way to reproduce it is 1) start a game; 2) stop the game;
3) click on the Refresh button and watch Dolphin segfault.
This commit fixes it by only calling PowerPC::HostIsRAMAddress when
emulation is running.
It doesn't make much sense to prefix g_ to static variables and for
some to be completely unprefixed.
Also renames a lot of other variables for the new conventions
This fixes an issue where the Bluetooth info section could be fully
filled up by syncing 5 Wiimotes in passthrough mode then switching to
emulated Bluetooth; emulated Wiimotes were then unable to be used.
The "real" SYSCONF section is now backed up before being replaced with
a blank section that the emulated BT adapter can always fill with 5
Wiimotes without issues.
This backup is restored by the passthrough code, instead of during
the Bluetooth mode switch because this should be done regardless of the
user interface, and even without UI (if the config file is edited
manually).
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.
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==
Because of the way this works, randomly overwriting the handler
when loading a savestate will break things because of the
self-modifying nature of the handler.
GeckoCodes require address hooks which don't correspond to any
symbol in the symbol table. The hooks get deleted when repatching
the game because they did not persist across calls to
HLE::PatchFunctions.
Dolphin emulates GeckoCodes by fiddling with the CPU state when a
VI Interrupt occurs. The problem with this is that we don't know
where the PC is so it's non-deterministic and not necessarily
suitable for use with the codehandler.
There are two options: Patch the game like Gecko OS either directly
or using HLE::Patch, or use a trampoline so we can branch from any
PC even if it would otherwise not be valid. The problem with Gecko OS
patches is there are 10 of them and they have to be configured
manually (i.e. Game INIs to would need to have a [Core]GeckoHookType
property).
HLE_Misc::GeckoReturnTrampoline enables the Code Handler to be
entered from anywhere, the trampoline restores all the registers that
had to be secretly saved to the stack.
If the installation fails because codehandler.bin is missing or
unusable then Dolphin will try again every single frame even though
it's highly unlikely a disk file will have changed. Better to just
fail once then only try again when the active code set is changed.
Suppresses generating 60 log messages per second.
Turns out one of the magic numbers was very magic. The gameid is
an ad-hoc comm protocol with HLE_Misc to control the number of times
the ICache is reset.
The code table builder cuts off the end of codes that won't fit
after already writing part of it. That seems quite unlikely to
work the way anyone would find useful since the codes can contain
actual PPC instructions.
shuffle2