persistent pairing

[thisiscam]

• Hi

I was wondering if the library can be made to persist paired session? Currently I have to go to the paring switch menu to pair the simulated controller every time I made some change to the script.

One possibility would be to create a separate process that connects the controller, and use RPC for scripts to invoke the controller in that process. Is there a better approach?

[thisiscam]

#15 attempts to solve this.

There can be better solutions, since that I'm not exactly familiar with the joycon protocol

To test the implementation, run run_cmd_cli.py with -s flag, then in a separate terminal run

sudo python run_test_shared_controller_cli.py 

[thisiscam]

@mart1nro I'm replying here to your comment in #15.

I totally agree that this might not be desirable for inclusion in the library; however, I had to make changes to protocol.py and server.py to let the protocol supports interrup/pausing.
Those changes are relatively simple and maybe you can merge those?
The changes to command line interface is not necessary, and the new sharing.py can be something optional (I can create another repo for that).

I did some research into how to perform BT reconnection. To my understanding, we need a dedicated process for a paired bluetooth session, and we need to implement something like page scan, as mentioned here.

My question: is it correct that we need a dedicated process for this? because if so, my current approach will be necessary.

[thisiscam]

I was probably wrong. I just tried to manually reconnect to a transport._sock and it worked! The catch is that the connection needs to be properly closed in the initial paring session.

[mart1nro]

I just tried to manually reconnect to a transport._sock and it worked!

What exactly did you do?

[thisiscam]

Sorry, that didn't work (i.e. getting a running protocal).
I did the following:

• run cmd_cli.py to establish a paring
• copy switch's BT_ADDR (it's in the logging) and kill the cmd_cli.py
• open up a new python and try to connect a socket to that BT_ADDR

I do get a connection, but it appears that switch does not send anything back.
I think Switch probably requires some specific information in order to re-establish connection.

https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering/blob/master/bluetooth_hid_subcommands_notes.md#subcommand-0x06-set-hci-state-disconnectpagepairturn-off

[thisiscam]

thisiscam@d3fbd44

[mart1nro]

I added a pull request #16.
This makes it so, that pausing in the transport also affects input report modes.

An input report mode can be registered as a replacement reader in the transport. This makes some cleanup possible, if transport.close() is called, which I'm kinda neglecting at the moment.

Would those changes be enough to run your code?

Gonna do some testing and another review at a later date.

[thisiscam]

closing this issue. Resolved by #17