Since all FS access will go through the new FS interface (PR #6421)
in order to keep track of metadata properly, there is no need to return
absolute paths anymore.
In fact, returning host paths is a roadblock to using the FS interface.
This starts the migration work by adding a way to get paths that are
relative to the Wii NAND instead of always getting absolute paths
on the host FS.
To prepare for future changes, this commit also makes returned paths
canonical by removing the trailing slash when it's unneeded.
Eventually, once everything has been migrated to the new interface,
we can remove the "from" parameter.
Use the newly added GetSystemDefaultInterfaceOrFallback() to return
actual information for the default interface, not just dummy
interface details.
This also fixes GetInterfaceOpt(0x4003) and gethostid() returning
inconsistent information. Prior to this change, GetInterfaceOpt(0x4003)
would return 10.0.1.30 and gethostid would give a totally unrelated IP.
This adds unit tests for the Wii filesystem now that the filesystem
interface is neatly separated from the IPC code.
Basic FS functionality is tested, in addition to problematic usages and
edge cases that Dolphin used to handle incorrectly (which of course
broke emulated software).
These tests should make it quite a bit harder to introduce regressions.
Issues that are covered by the tests in particular:
* Metadata: issue 10234 (though tests are commented out for now because
Dolphin doesn't support NAND images yet so it can't track metadata);
* EOF seeks/reads: https://github.com/dolphin-emu/dolphin/pull/4942
* Read/write operations from multiple handles: see issue 2917, 5232 and
8702 and https://github.com/dolphin-emu/dolphin/pull/2649
Xlib has really terrible headers that declare non-namespaced
macros and typedefs for common words.
Just wasted 10 minutes trying to figure out why a unit test failed
to build before I remembered it was Xrandr.h conflicting with our
enum class members again.
To fix the issue, this removes the Display* parameter from the
EnableScreensaver function (which was unused) so we don't have
to include Xrandr.h anymore.
Just re-disassembled STM and found out I have made a mistake when
I changed STM stuff back in 2016.
I accidentally made STM reset the event hook on close when it should
have been done in the destructor (i.e. when IOS gets reset on console).
Verified in IDA that STM just `IOS_ResourceReply(request, IOS_OK)`
without ever resetting the hook.
It's not common code that could be reused for, say, Citra;
it's absolutely specific to Wii emulation and only used by the Dolphin
core, so let's move it there.
Another reason for doing this is to avoid having Common depend on Core.
It was discovered that some titles rely on filesystem metadata to work
properly. Currently, in master they either simply won't find their
save files (for example Bolt) or will complain about the Wii system
memory being corrupted (on first use or every time depending on
the title).
In order to even be able to keep track of file metadata, we first need
to eliminate all direct accesses to the NAND and make all kinds of
operations go through the filesystem code added in PR 6421.
This commit starts the migration process by making SysConf use
the new FS interface.
This used to be necessary for properly cleaning up the FS state because
the old FS implementation used static state and only performed cleanup
in the close function, not in the destructor.
Now that the static state is gone, we do not need to close devices
manually anymore.
This was necessary to work around a FS timing issue which caused small
writes to take much longer than they should.
Now that we emulate timings for the FS module including its file cache,
we don't need to maintain this workaround anymore.
Return a FileHandle which will automatically close the FD when
the handle goes out of scope. For the rare cases where this behaviour
is undesirable, the FD can be released from the handle.
This is the large change in the branch.
This lets us use either the host filesystem or (in the future) a NAND
image exactly the same way, and make sure the IPC emulation code
behaves identically. Less duplicated code.
Note that "FileIO" and "FS" were merged, because it actually doesn't
make a lot of sense to split them: IOS handles requests for both
/dev/fs and files in the same resource manager, and as it turns out,
/dev/fs commands can *also* be sent to non /dev/fs file descriptors!
If we kept /dev/fs and files split, there would be no way to
emulate that correctly. I'm not aware of anything that does that (yet?)
but I think it's important to be correct.
Now that we have a proper filesystem interface, it makes more sense
to return it instead of the emulated IOS device (which isn't
really usable for any purpose other than emulated IPC).
Extract the existing FS code into a HostBackend implementing
the filesystem interface.
Compared to the original code, this uses less static state.
The open host files map is now a member variable
as it should have been. Filesystem handles are now also easier
to savestate. Some variable names and log messages were cleaned up.
Nothing else has been changed.
Add a new FileSystem class that can be used to perform operations
on the emulated Wii filesystem.
This will allow separating the IPC code (reading from and writing to
memory to handle IOS FS commands) and the actual filesystem code
in a much better way.
This also paves the way for implementing another filesystem backend
in the future -- NAND images for more complete emulation, including
filesystem metadata like permissions or file orders, which some games
and homebrew actually care about -- without needing to make any more
changes to the other parts of the codebase, in addition to making
filesystem behaviour tests easier to write.
This adds a lightweight, easy to use std::variant wrapper intended to
be used as a return type for functions that can return either a result
or an error code.
A search box is a common UI element. We don't need to explicitly tell
the user that they need to type a search term. Also,
Let's use the common "Search <items>..." placeholder text instead
and make the string shorter for localisation.
This prevents Dolphin from crashing when the emulated software crashes.
AFAIK, there is absolutely no performance to enabling this with the
x64 JIT.
Eventually, we should probably just remove bMMU
(https://github.com/dolphin-emu/dolphin/pull/1831). We can't do that
yet because of the ARM JIT.
A very basic hardware test shows that the ARMMSG doesn't change until
IOS replies. (People could have disassembled IOS to verify this too...)
Console:
sending request at 00034640 - ARMMSG 133e0fa0
00000000000000000000000000000010(ack) - ARMMSG 133e0fa0
00000000000000000000000000000100(reply) - ARMMSG 00034640
Dolphin, prior to this fix:
sending request (00034640) - ARMMSG 133e0fa0
00000000000000000000000000000011(ack) - ARMMSG 00034640
00000000000000000000000000000100(reply) - ARMMSG 00034640
Dolphin, after this fix:
sending request at 00034640 - ARMMSG 133e0fa0
00000000000000000000000000000011(ack) - ARMMSG 133e0fa0
00000000000000000000000000000100(reply) - ARMMSG 00034640
(Yes, note that the X1 bit is still set. This is a bug that I will
fix in the next commit.)
The IPC interrupt is triggered when IY1/IY2 is set and Y1/Y2 is written
to even when this results in clearing the bit.
This shouldn't change anything in practice but it's a difference
that Dolphin wasn't taking into account, which made me waste some time
when I was writing a hwtest :/
This adjusts IOS IPC timing to be closer to actual hardware:
* Emulate the IPC interrupt delay. On a real Wii, from the point of
view of the PPC, the IPC interrupt appears to fire about 100 TB ticks
after Y1/Y2 is seen.
* Fix the IPC acknowledgement delay. Dolphin was much, much too fast.
* Fix Device::GetDefaultReply to return more reasonable delays. Again,
Dolphin was way too fast. We now use a more realistic, average reply
time for most requests.
Note: the previous result from https://dolp.in/pr6374 is flawed.
GetTicketViews definitely takes more than 25µs to reply.
The reason the reply delay was so low is because an invalid
parameter was passed to the libogc wrapper, which causes it to
immediately return an error code (-4100).
* Fix the response delay for various replies that come from the kernel:
fd table full, unknown resource manager / device, invalid fd,
unknown IPC command.
Source: https://github.com/leoetlino/hwtests/blob/af320e4/iostest/ipc_timing.cpp
Work around a dcache issue by preventing the game from doing
something pointless.
The game's DVD read function writes 0x87654321 to the entire read
buffer and 0x12345678 to the last 4 bytes. It then calls DVDReadAsync()
and without waiting for the read to complete at all, it checks if the
last 4 bytes are still 0x12345678. If they are, then the game fails.
The check always passes on console because DVDReadAsync() calls
issueCommand(), which calls DCInvalidateRange(read_buffer) (dcbi).
Dolphin cannot emulate this without an extremely significant
performance hit.
This commit changes devices to always return IPCCommandResult rather
than just a return code for Open() and Close() in order to be able
to better emulate reply timing.
In hindsight, I should have considered we would want to emulate
timing when I cleaned up the device interface, but alas.
This rectifies that mistake.
Whenever udev_monitor_receive_device() returns a non-null pointer,
the device must be unref'd after use with udev_device_unref().
We previously missed some unref calls for non-evdev devices.
It's not guaranteed that the eventfd is smaller than the monitor fd,
because fds are not always monotonically allocated. To select()
correctly in all cases, use the max between the monitor fd and eventfd.
Some homebrew expect exception handlers to be present -- which is
almost always the case on console, since most of the time homebrew are
launched from either a libogc or SDK title) -- and break if they are
not. To fix this, we just need to include default, dummy handlers.
Set HID0, HID4, GPR1 to values that are used by libogc for
initialisation. This makes boots more similar to a launch
from the HBC or another loader, since normally the registers
have already been initialised by the loader.
This fixes a crash in homebrew that assume GPR1 points to a correct
location and attempt to use it before initialising registers.
Currently, a simple typo in the system name will trigger an assert
message that complains about a "programming error". This is not
user friendly and misleading.
So this changes GetSystemFromName to return an std::optional, which
allows for callers to check whether the system exists and handle
failures better.
Manually convert each argument to a UTF-8 std::string, because the
implicit conversion for wxCmdLineArgsArray to char** calls ToAscii
(which is obviously undesired).
Fixes https://bugs.dolphin-emu.org/issues/10274
Unlike VEN, the endpoint is determined by the value at 8-12.
If it's non-zero, HID submits the request to the interrupt OUT
endpoint. Otherwise, the request is submitted to the IN endpoint.
This commit changes HIDv5 to keep track of endpoints (like IOS does)
and use them when submitting interrupt transfers.
This implements /dev/usb/hid v5, found in IOS57, IOS58 and IOS59.
This is an initial implementation that ignores some differences
with VEN because I lack understanding of what IOS is actually doing
sometimes. These are documented on the WiiBrew article:
https://wiibrew.org/wiki//dev/usb/hid_(v5)
One major difference that this implementation handles is about IDs.
It turns out Nintendo has decided to include the interface number in
the top byte of HIDv5 device IDs, unlike VEN -- even though everything
else about ioctl 1 is otherwise the same!
USBv5 IOS resource managers share most of their code. Some ioctls
are even completely the same! So let's separate the common code
from the VEN specific stuff to make HIDv5 easier to implement.
The descriptor copy code is not actually the same in HIDv4 and VEN,
so it did not make a lot of sense to put it in USB/Common.cpp.
Separate and move it to HIDv4 and VEN.
This cleanup is important because there are even more differences
between HIDv4 and HIDv5.
Fix the device ID struct to reflect the actual structure used by IOS.
It turns out that offset 2 is the internal device index. The reason
that field seemed to be "0x1e - interface_number" is that IOS only
keeps track of 32 devices and always looks for free entries from
the end of the internal array. With each USB interface being exposed
as a separate USBv5 device, "0x1e - interface_number" was mostly
correct... but wrong!
We also made the assumption that the interface number can be
identified from just a USBV5 device ID, which is definitely not true.
VEN (and HID) keep track of the interface number in the internal struct
instead of "reconstructing" it from the device ID (which is normally
not possible if we were generating IDs correctly)
This commit fixes all of these inaccuracies.
It is not possible to tell whether DLC contents are supposed to be
present on the NAND or not, because they're treated as "optional".
So this commit changes the NAND check to not consider missing
contents for DLC titles as an issue.
Use std::string(cstring, strnlen(cstring, max_length)) instead of
trying to remove extra null characters manually, which is a bit
ugly and error prone.
And indeed, the original code contained a bug which would cause
extra NULLs to not be removed at all if the string did not
end with a NULL -- causing issues down the road when constructing
paths for sub-entries.
Léo Lam