* Netplay Stuff
## PROTOCOL FALLBACK
In order to support older clients a protocol fallback system was introduced.
The host will no longer send its header automatically after a TCP connection is established, instead, it awaits for the client to send his before determining which protocol this connection is going to operate on.
Netplay has now two protocols, a low protocol and a high protocol; the low protocol is the minimum protocol it supports, while the high protocol is the highest protocol it can operate on.
To fully support older clients, a hack was necessary: sending the high protocol in the unused client's header salt field, while keeping the protocol field to the low protocol. Without this hack we would only be able to support older clients if a newer client was the host.
Any future system can make use of this system by checking connection->netplay_protocol, which is available for both the client and host.
## NETPLAY CHAT
Starting with protocol 6, netplay chat is available through the new NETPLAY_CMD_PLAYER_CHAT command.
Limitations of the command code, which causes a disconnection on unknown commands, makes this system not possible on protocol 5.
Protocol 5 connections can neither send nor receive chat, but other netplay operations are unaffected.
Clients send chat as a string to the server, and it's the server's sole responsability to relay chat messages.
As of now, sending chat uses RetroArch's input menu, while the display of on-screen chat uses a widget overlay and RetroArch's notifications as a fallback.
If a new overlay and/or input system is desired, no backwards compatibility changes need to be made.
Only clients in playing mode (as opposed to spectating mode) can send and receive chat.
## SETTINGS SHARING
Some settings are better used when both host and clients share the same configuration.
As of protocol 6, the following settings will be shared from host to clients (without altering a client's configuration file): input latency frames and allow pausing.
## NETPLAY TUNNEL/MITM
With the current MITM system being defunct (at least as of 1.9.X), a new system was in order to solve most if not all of the problems with the current system.
This new system uses a tunneling approach, which is similar to most VPN and tunneling services around.
Tunnel commands:
RATS[unique id] (RetroArch Tunnel Session) - 16 bytes -> When this command is sent with a zeroed unique id, the tunnel server interprets this as a netplay host wanting to create a new session, in this case, the same command is returned to the host, but now with its unique session id. When a client needs to connect to a host, this command is sent with the unique session id of the host, causing the tunnel server to send a RATL command to the host.
RATL[unique id] (RetroArch Tunnel Link) - 16 bytes -> The tunnel server sends this command to the host when a client wants to connect to the host. Once the host receives this command, it establishes a new connection to the tunnel server, sending this command together with the client's unique id through this new connection, causing the tunnel server to link this connection to the connection of the client.
RATP (RetroArch Tunnel Ping) - 4 bytes -> The tunnel server sends this command to verify that the host, whom the session belongs to, is still around. The host replies with the same command. A session is closed if the tunnel server can not verify that the host is alive.
Operations:
Host -> Instead of listening and accepting connections, it connects to the tunnel server, requests a new session and then monitor this connection for new linking requests. Once a request is received, it establishes a new connection to the tunnel server for linking with a client. The tunnel server's address and port are obtained by querying the lobby server. The host will publish its session id together with the rest of its info to the lobby server.
Client -> It connects to the tunnel server and then sends the session id of the host it wants to connect to. A host's session id is obtained from the json data sent by the lobby server.
Improvements (from current MITM system):
No longer a risk of TCP port exhaustion; we only use one port now at the tunnel server.
Very little cpu usage. About 95% net I/O bound now.
Future backwards compatible with any and all changes to netplay as it no longer runs any netplay logic at MITM servers.
No longer operates the host in client mode, which was a source of many of the current problems.
Cleaner and more maintainable system and code.
Notable functions:
netplay_mitm_query -> Grabs the tunnel's address and port from the lobby server.
init_tcp_socket -> Handles the creation and operation mode of the TCP socket based on whether it's host, host+MITM or client.
handle_mitm_connection -> Creates and completes linking connections and replies to ping commands (only 1 of each per call to not affect performance).
## MISC
Ping Limiter: If a client's estimated latency to the server is higher than this value, connection will be dropped just before finishing the netplay handshake.
Ping Counter: A ping counter (similar to the FPS one) can be shown in the bottom right corner of the screen, if you are connected to a host.
LAN Discovery: Refactored and moved to its own "Refresh Netplay LAN List" button.
## FIXES
Many minor fixes to the current netplay implementation are also included.
* Remove NETPLAY_TEST_BUILD
* convert abs mouse from screen to viewport coordinates; fix relative mouse code to work in screen mode
* C89 compatibility
* revert accidental include
* Allow parallel compilation in PS2
* Allow to compile with griffin or common compilation in PS2
* Enable dummy core to be used in other platforms
* Use threads in YML config
* Add the compilation to PS2 in GitHub Actions
== DETAILS
So, the reason the gamepad was getting deregistered was
because adapter free code wasn't properly handling null-interface
adapters, causing the gamepad to match erroneously and get
deregistered.
This doesn't fix the weird "Generic SNES USB" detection issue,
but it should make it non-fatal.
Co-authored-by: Nathan Strong <nstrong@tripwire.com>
== DETAILS
The problem was caused by changing the driver lookup point. The deferred
lookup resulted in the WIIU trying to treat the keyboard as a gamepad which ...
didn't work.
This change short-circuits at the connection event by ignoring mouse &
keyboard connection events.
Tested this with a dev build.
Co-authored-by: Nathan Strong <nstrong@tripwire.com>
* Any pad can control the menu
== DETAILS
I am not sure I've quite got it so that any pad can *open* the
menu, but I do have it so any pad can control it.
- split out the input processing into a separate method
- track down and squish some hairy bugs that boiled down to
bad pointer math
- it looks like `menu_driver.c` has a mix of line endings, so I
ran it through `dos2unix` so it has consistent line endings
again.
- verified that this change did not impact actual cores
* optimize out cumulative_bits
* Incorporate PR feedback
Many thanks to @jdgleaver for providing these optimizations.
* apply one more optimization
* Move more state to runloop state
* remove unused variable
* Cleanup
* Move more state to runloop_state
* Remove unused variable
* Cleanups
* move input_remapping functions over to input_driver.c
* Some buildfixes
== DETAILS
The crashes he reported in the gbatemp thread are due to iface
being null (since it's an unsupported device) and unchecked
iface dereferences.
== DETAILS
- only call disconnect when we're actually disconnecting a remote
(e.g. read errors or remote goes to sleep).
- clean up some compile warnings introduced by others (mainly
unused variables)
== DETAILS
Put the finishing touches on getting the DS3 to work on Mac OSX.
Basically, there's some differences in the HID interface bewtween
wiiu and osx where OSX expects the first byte of the report to be
the report ID, while wiiu expects that byte to be trimmed off.
I was able to put this behavior in the respective HID
implementations, which eliminated the confusing packet offset
ifdefs.
And, I was able to get the LEDs working again.
== DETAILS
The DS3 driver previously only worked with the Wii U HID implementation.
I adapted this driver from the Linux driver for the DS3. It's not quite
100%--I haven't got the LEDs to work properly--but it's functional.
Going to continue tweaking it to see if I can get the LEDs to work.
== DETAILS
- rewrote the HID deregistration algorithm; it should no longer
cause issues when dealing with multiple pads of the same HID/VID
combo
- fix initialization bug that caused wiimotes to fail to register
without an accessory attached
== DETAILS
The GCA uses a weird HID class that our current filters don't
catch, so we add it.
Needed to do a small amount of tweaking on the GCA driver to
account for iohidmanager weirdness.
== DETAILS
The HID drivers in `input/connect/` were missing an implementation
for button(), so I added it. The only exception is the wii driver,
which is really complicated and more than I wanted to try to tackle--
especially since WIIU has its own wiimote drivers.
== DETAILS
Use a little trickery to ensure the GCA driver continues working
with other HID implementation.
I've expanded the joypad implementation to support multi-pad devices.
However, this requires changes to each HID implementation to actually
function.
I've made the necessary changes for WIIU, but I don't have the means
of making the change in the other HID implementations.
So, I've built in a backwards-compatibilty mode for the driver.
The trick is to have an identifier byte at the top of both data structs
that the driver returns. We can then use that byte to determine which
of the structs has been passed to the pad functions and act accordingly.
In the GCA case, for non-wiiu platforms, it will simply expose port 1
of the GCA and the other 3 ports do nothing.
== DETAILS
cause of crash: trying to deference init when it's null
the reason it was going into deregister: the HID/VID lookup was
failing because it wasn't getting initialized first
cause of 2nd crash: the "end of pad list" method looked for an entry
with a magic value, so we add an end marker
== DETAILS
I'm going to need to re-implement the abstraction between HID device
and gamepad; the changes here lay down some foundation for that work.
- reduce logging priority of some statements I modified while debugging
- factor out the pad driver lookup into its own method
- fix so the pad driver list isn't re-initialized every invocation
- add the button() method for the GCA driver
== DETAILS
When I first implemented the Wii U HID architecture, I ended up
having to design my own implementation because, at the time, I did
not have a way to read the HID device string to allow the existing
code to successfully detect the gamepad.
After spending some time experimenting, I've figured out how to
do this. And that means I can better align the HID driver with other
platforms.
change summary:
- create a single state structure for all three sub-types of wiiu pads
(kpad, wpad, and hid)
- eliminate confusing duplicate pad lists
- eliminate confusing duplicate HID pad drivers (ds3, gamecube
adapter, etc)
- ensure the ds3 driver still works
* re add this after failed rebase
* update
* temp fix for device friendly naming as it is for testing
* add device friendly names in the appropiate place
* add/remove hotplug dev to ra input mouse port list
Co-authored-by: grant2258 <you@example.com>
== DETAILS
File this one under "I'm not sure how this ever worked."
I mean, it did (in 1.8.8). I'm not sure what changed, but ultimately what I did was
a bunch of comparative testing against 1.8.8:
- I confirmed the packet data was still being read successfully
- I confirmed that the axis value being passed into pad->get_axis() had
not changed
- I confirmed the work done in `gamepad_read_axis_data()` was working the same
between 1.8.8 and master
With the only difference between 1.8.8 and current being the return value from
`gamepad_read_axis_data()`, I just rewrote the method to work properly, and
also fixed up the default axis mapping.
I tested this with a sixaxis controller and GCA, configuring the analog-to-digital
control override to use the right stick.
twinaphex