For thread safety, we shouldn't return any pointers or references that
can be used to mutate the state of the PPCSymbolDB. This should be the
final part of making PPCSymbolDB thread safe unless I've missed
something.
9395238 added locking in some PPCSymbolDB functions that access member
variables, but far from all. To ensure thread safety, this commit adds
the missing locking.
9395238 added a mutex to PPCSymbolDB, and made functions return with an
"empty" result if called while the mutex is locked. This new behavior
has the potential to affect not only less important call sites like the
symbol printing mentioned in a comment, but also the JIT deciding if it
should HLE a function.
A later commit in this pull request decreases the amount of lock
contention, reducing the performance impact of this commit.
Instead of creating many 128 KiB mappings, we can create a few large
mappings. On my Windows PC, this speeds up GameCube (FakeVMEM) game boot
times by about 200 ms and Wii game boot times by about 60 ms. Loading
savestates is also faster, by about 45 ms for GameCube (FakeVMEM) games
and 5 ms for Wii games. The impact is presumably smaller on other OSes
because Windows is particularly slow at creating mappings.
Without this, there was a bug where if you turned the device's screen
off and on again while in the advanced mapping dialog, the input
indicators would stop updating. This is because turning the screen on
again causes devices to refresh, which causes all devices to be
recreated, leaving the AdvancedMappingControlViewHolders stuck
referencing controls belonging to devices that are no longer being
updated.
This makes sure view holders get proper widths when they use
layout_width="match_parent". This becomes quite noticeable for
AdvancedMappingControlAdapter in the next commit, but I'm also
making the change for other adapters while I'm at it.
Google Play is now blocking distribution for Android TV unless we
explicitly set the android.hardware.microphone hardware feature as
android:required="false", because it's inferring
android.hardware.microphone from the android.permission.RECORD_AUDIO we
added for Wii Speak emulation, with android:required defaulting to true.
I was under the belief that setting android:required="false" on
android.permission.RECORD_AUDIO would solve this, but looking closer at
the definition of <uses-permission>, it doesn't actually support
android:required attributes, so that presumably has no effect.
This can reduce audio latency according to
https://developer.android.com/ndk/guides/audio/opensl/opensl-prog-notes#perform.
Previously we were using the hardcoded values of 48000 Hz and 256 frames
per buffer. The sample rate we use with this change is 48000 Hz on all
devices I'm aware of, but the buffer size does vary across devices.
Terminology note: The old code used the term "sample" to refer to what
Android refers to as a "frame". "Frame" is a clearer term to use for
this, so I've changed OpenSLESStream's terminology. One frame consists
of one sample per channel.
Not sure if we're ever going to want to have more than one of these at
the same time, but these global variables are a code smell nonetheless.
I'm also deleting the existing member variables because they were
unused.
If you already have a mapping set in the advanced mapping dialog and
want to change it, the easiest way to do it is to press Clear and then
select the new mapping from the list. But pressing Clear causes the
dialog to close, forcing you to open it again, which is inconvenient.
This commit makes it so the Clear button doesn't close the dialog.
On real hardware, stswi and stswx don't trigger any of the special
behavior for uncached unaligned writes that was implemented in 543ed8a.
This is confirmed by a hwtest (a new commit in
https://github.com/dolphin-emu/hwtests/pull/42).
This change fixes Dolphin's stswi and stswx implementations so they stop
triggering the special behavior, bringing them back to the behavior they
had before 543ed8a. No games are known to be affected, but Extrems has
reported that it affects homebrew they've made.
This fixes a memory leak that would occur when the Android frontend
calls LogManager::Init more than once in order to reload settings.
Note that the log window listener is now owned by LogManager instead of
by the frontend, making it consistent with the other log listeners.
Old cruft from when the Android code was loading INI files manually.
We don't have any handling for failing to load settings anymore.
This change also updates related comments to reflect how things actually
work nowadays.
Probably a copy-paste error from layout-ldrtl/list_item_setting.xml.
This error made it so a long setting name could overlap with the
checkbox next to it if Dolphin was running with right-to-left layout.
The incorrect ID was apparently also causing the app:lintVitalRelease
build task to fail. I guess we're not running that build task, because I
only heard of this from someone building Dolphin locally.
There's no guarantee that directory initialization has completed by this
point, so we can't safely use NativeLibrary.
I'm making this change because of a crash being reported in Google Play
Console. The exact way it's crashing is mysterious to me, so I'm not
sure if this commit fixes the crash, but I think this commit is
a reasonable change to make even if it doesn't fix the crash. Backtrace
from Google Play Console:
#00 pc 0x0000000000469074 /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (std::__ndk1::pair<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>> const, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>::pair[abi:nn180000]<char const* const&, char const* const&, 0>(char const* const&, char const* const&)) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#01 pc 0x0000000000468e9c /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (std::__ndk1::pair<std::__ndk1::__tree_iterator<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, std::__ndk1::__tree_node<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, void*>*, long>, bool> std::__ndk1::__tree<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, std::__ndk1::__map_value_compare<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, std::__ndk1::less<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>, true>, std::__ndk1::allocator<std::__ndk1::__value_type<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>>>>>::__emplace_unique_impl<char const* const&, char const* const&>(char const* const&, char const* const&)) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#02 pc 0x0000000000462f08 /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (Common::Log::LogManager::GetLogTypes()) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#03 pc 0x000000000044339c /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/lib/arm64/libmain.so (Java_org_dolphinemu_dolphinemu_NativeLibrary_GetLogTypeNames+56) (BuildId: 64cfebf5b574b6729ebc51799aa94ccc3238cbcc)
#04 pc 0x000000000031456c /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (art_jni_trampoline+108)
#05 pc 0x0000000000781508 /apex/com.android.art/lib64/libart.so (nterp_helper+152)
#06 pc 0x00000000002d94d4 /data/app/~~m0kqybFNfeqnDenQFc53XQ==/org.dolphinemu.dolphinemu-Mtaw0lU8DVUQbte2ZjBp3w==/base.apk (org.dolphinemu.dolphinemu.features.settings.ui.SettingsFragmentPresenter.<clinit>+16)
[...]
Extracted games contain a boot.bin file that contains the disc header.
These boot.bin files are considered valid volumes by Dolphin, since
Dolphin only checks the disc header to determine if something is a valid
GC/Wii disc. Running them doesn't make any sense, though.
boot.bin files used to not be scanned by Dolphin due to their file
extension, but .bin was added to the list of file extensions to scan for
in 494e2c0. To stop them from showing up in the game list, let's update
the ShouldHideFromGameList mechanism.
Different threads are adding and calling callbacks, so this should have
some locking. This is both to ensure thread safety when accessing
`s_callbacks` and to ensure that there won't be situations where a
callback gets called after it's removed.
`s_callback_guards` is also accessed from multiple threads and has
therefore been made atomic.
a1691a4 made it so analytics start events can only be generated when
starting the main activity. However, some users launch Dolphin's
emulation activity from a separate frontend application, bypassing
Dolphin's main activity. This change adjusts the logic so that start
events can be generated if any activity is started after 6 hours of
inactivity. This more closely matches the behavior we had before
a1691a4, while still ensuring duplicate start events aren't generated.
I've also fixed the inconsistent indentation in ActivityTracker.kt.
I've been playing Rock Band 3 recently and have experienced a bug where
sometimes if you disconnect and reconnect a USB microphone, the game
won't pick up on it connecting, not even it you disconnect and reconnect
it again. An investigation into what's going on inside Dolphin shows
that when the game triggers a call to OH0::DeviceOpen after the device
has been reinserted, Dolphin doesn't open the device because it's
already present in m_opened_devices.
Removing the device from m_opened_devices after calling OH0::TriggerHook
in OH0::OnDeviceChange resolves this specific issue in my testing. Doing
this matches us removing the device from m_opened_devices after calling
OH0::TriggerHook in OH0::DeviceClose, but I haven't looked at exactly
what real IOS does.
I have been able to reproduce a much rarer issue that has the same
symptoms on the surface but where OH0::DeviceOpen gets past its
m_opened_devices check. I'm currently not sure what the cause of this
remaining issue is.
71f654c added a new platform in the middle of the C++ platform enum
without updating the corresponding Android code, making the Android code
incorrectly treat Wii discs as WAD files, WAD files as DOL/ELF files,
and so on. This commit fixes the problem.
To be able to add the new Triforce entry into the Platform enum without
it leading to the UI getting an additional tab, I'm splitting the enum
into Platform and PlatformTab. Platform now exactly matches the C++
enum (previously it excluded ELFOrDOL), and PlatformTab has the same
content as the old Platform.
Some games open two USB interfaces, e.g. /dev/usb/oh0 and /dev/usb/hid.
This was causing us to run two scanning threads at once, using up more
CPU time for scanning than we need to.
Instead of having USBScanner create "hooks" as it scans for devices,
let's have USBScanner present a list of devices to USBHost and have
USBHost diff the new device list with its old device list to create the
hook calls instead. This gets rid of some complex edge cases that the
next commit otherwise would have to deal with, in particular regarding
toggling determinism and adding new USBHosts to a USBScanner.
Note: After adding the missing locking of m_devices_mutex, I had to move
the locking of m_hooks_mutex to avoid a random deadlock between the CPU
thread and USB scanning thread. (Either that or I would have to lock
m_devices_mutex before m_hooks_mutex.)
This gets rid of the ugly direct access to USBScanner::m_devices that
was introduced by the previous commit.
This also fixes a potential thread safety issue.
USB_HIDv4::TriggerDeviceChangeReply loops through m_devices and calls
GetDeviceEntry for each device. If USB_HIDv4::TriggerDeviceChangeReply
is called after a new device is added to m_devices but before hooks are
dispatched, GetDeviceEntry crashes, because the hook that's supposed to
update m_device_ids hasn't run yet. With this commit, this issue can no
longer happen, because USBHost::m_devices_mutex doesn't get unlocked in
between updating m_devices and dispatching the hooks.
When you use TimePlayed, you have to provide a game ID either when
creating the object or when calling GetTimePlayed on it. If you don't
provide a game ID when creating the object, function calls that don't
take a game ID will silently fail, except for Reload. This isn't very
obvious, and there's no strong benefit to storing the game ID inside
TimePlayed anyway (it just lets TimePlayed skip calling EscapeFileName),
so this commit removes the TimePlayed constructor that takes a game ID
and instead makes the functions that need game IDs always take a game ID
argument.
This lets you use PS3 Rock Band controllers with Wii Rock Band and
Guitar Hero games.
A normal user will probably never have any reason to disable this
behavior, but I figured maybe there's some person out there who would
like to disable it. (For instance, I know there's a mod for RB3 that's
trying to implement the same kind of cross-console controller
compatibility, and that can only be tested if the behavior I'm adding is
disabled.) So the behavior is controlled by an INI-only setting.
This is an Android continuation of bc95c00. We now call
InputDetector::Update immediately after receiving an input event from
Android instead of periodically calling it in a sleep loop. This
improves detection of very short inputs, which are especially likely to
occur for volume buttons on phones (or at least on my phone) if you
don't intentionally keep them held down.
bbf72e7 made a change where you can pass `false` to certain MemChecks
functions to get them to skip performing an "update" step. It was then
up to the caller to call the Update function later.
This commit changes the implementation so that, instead of the caller
passing in a boolean that controls whether a function calls Update, the
function now returns an object that on destruction will call Update.
Callers that are fine with Update being called right away can skip
storing the object in a variable and thereby call Update immediately,
and callers that want to call Update later can keep the object around.
This new design reduces the risk that someone will forget calling
Update.
JosJuice