We're allowed (by the standard) to forward declare types within
std::vector, so we can replace direct includes with forward declarations
and then include the types where they're directly needed.
While we're at it, we can remove an unused inclusion of <cstring>, given
nothing in the header uses anything from it. This also revealed an
indirect inclusion, which this also resolves.
Previously u32 was being used for part of the interface and unsigned int
was being used for other parts. This makes the interface fully consistent by
using only one type.
We opt for u32 here given they communicate the same thing (for platforms
we care about where int is 32-bit), while also being less to read.
While we're at it, we can also default the constructor and destructor of
inheriting classes in their respective cpp file to prevent the
construction and destruction of non-trivial types being inlined into
other regions of code.
This was in DolphinWX but not DolphinQt. It's useful for telling if
users who post screenshots have an up-to-date version of Dolphin.
The old implementation of this prepended the version in DolphinWX code
rather than Core code, but I thought it'd be simpler to do it in Core.
This isn't as serious as copying global INIs into user game INIs,
but still not good. We want to be able to remove settings from
default game INIs and have those removals apply.
IOLinux.cpp should include <sys/select.h> as it uses select() functionality.
On certain platforms it's included implicitly by other headers, which is why
it compiled before. This makes it also work on musl platforms.
libusb transfer callbacks might be called immediately during transfer
submission in some cases. (libusb doesn't even specify what thread
the callback is invoked on.) In other words, it is possible to reach
the transfer callback from the CPU thread, and not just from the
USB event handling thread.
So CoreTiming::FromThread::NON_CPU is incorrect and should instead
be ANY.
Unfortunately, it appears that using libusb's synchronous transfer API
from several threads causes nasty race conditions in event handling and
can lead to deadlocks, despite the fact that libusb's synchronous API
is documented to be perfectly fine to use from several threads (only
the manual polling functionality is supposed to require special
precautions).
Since usbdk was the only real reason for using a single libusb context
and since usbdk (currently) has so many issues with Dolphin, I think
dropping support for it in order to fix other backends is acceptable.
Lioncash