if the configured local pad is none, it will make dolphin behave
incorrectly (due to the game expecting inputs from the device while it
doesn’t exist).
Remote devices would always enter an error path and get disconnected
from the gamecube, breaking netplay in the process.
Culprit is still InGamePadToLocalPad
if it was used in netplay, it would read memory out of bounds
(due to the mapping method returning 4 if the device was remote) which
was 0 more often than not, causing the device in this position to be a konga.
(which may or not be the gcadapter due to the swap between local and
ingame controllers)
Introduced in 6e13496d8, pads would get assigned to their netplay
position, which breaks assumptions. With this behavior, the SI devices
should be mapped properly.
if a pad or wiimote number was outside bounds (e.g. 42353543232),
it would still have been read from the array, which could lead to
inappropriate consequences, like a segfault.
So that it contains the current commit and not an arbitrary date that
may or may not be up-to-date. This will cause tears as people will not
be able to use netplay with one diverging commit that does not touch
anything related. On the other hand, users can’t be trusted.
The goal of this commit is to let people who experience driver issues
with libusb and windows disable the scanning thread (to avoid mouse
issues, keyboard issues, and audio issues).
Also disable the rumble setting when the adapter driver is not detected,
and don’t do anything if libusb can’t init for some reason.
This scanning thread either polls libusb or checks every 500ms for a
change depending on host capabilities. The GC Adapter can now be plugged
and unplugged at any time when dolphin is open, it will be used if the
direct connect option is set.
With some specific, STUN-hostile routers, the netplay client can get
stuck forever while trying to connect to the stun server. This adds a
5 seconds (much more than should be necessary if it works) timer until
a failure is registered and the attempt stops.
Otherwise, it would work but any async sending would be delayed by 4ms or
wait until the next packet was received.
Also increase the client timeout to 250ms, since enet_host_service is now
really interrupted.
Add std::unique_ptr<sf::Packet> objects to a queue instead of functions,
makes things easier to read, and avoids headaches while checking the
lifetime of the concerned objects.
If we successfully detach the kernel driver from the interface, we
should continue instead of aborting the setup.
And we should not use libusb_handle_events(), as the API says it is only
for backwards compatibility. Additionally, if the adapter thread is not
active, dolphin will take 60 seconds to close because the
libusb_handle_events() timeout is hardcoded to 60 seconds. Instead, use
libusb_handle_events_timeout_completed() with a timeout of 1 second.
Also, cancel the libusb transfers before the join(), to be able to close
the usb device without libusb screaming in the background (and
potentially crashing).
And finally, split the Init() and Shutdown() functions to avoid having
to init and exit libusb every time we neeed to detect the adapter.
mathieui