mirror of
https://github.com/feschber/lan-mouse.git
synced 2026-03-07 11:59:59 +03:00
a2d2e904f8
* support for cmdline args and better error handling * make config.toml optional * dont abuse panic for error handling * update doc * more panics removed * more unwraps removed
78 lines
2.5 KiB
Markdown
78 lines
2.5 KiB
Markdown
# General Software Architecture
|
|
|
|
## Events
|
|
|
|
Each instance of lan-mouse can emit and receive events, where
|
|
an event is either a mouse or keyboard event for now.
|
|
|
|
The general Architecture is shown in the following flow chart:
|
|
```mermaid
|
|
graph TD
|
|
A[Wayland Backend] -->|WaylandEvent| D{Input}
|
|
B[X11 Backend] -->|X11Event| D{Input}
|
|
C[Windows Backend] -->|WindowsEvent| D{Input}
|
|
D -->|Abstract Event| E[Emitter]
|
|
E -->|Udp Event| F[Receiver]
|
|
F -->|Abstract Event| G{Dispatcher}
|
|
G -->|Wayland Event| H[Wayland Backend]
|
|
G -->|X11 Event| I[X11 Backend]
|
|
G -->|Windows Event| J[Windows Backend]
|
|
```
|
|
|
|
### Input
|
|
The input component is responsible for translating inputs from a given backend
|
|
to a standardized format and passing them to the event emitter.
|
|
|
|
### Emitter
|
|
The event emitter serializes events and sends them over the network
|
|
to the correct client.
|
|
|
|
### Receiver
|
|
The receiver receives events over the network and deserializes them into
|
|
the standardized event format.
|
|
|
|
### Dispatcher
|
|
The dispatcher component takes events from the event receiver and passes them
|
|
to the correct backend corresponding to the type of client.
|
|
|
|
|
|
## Requests
|
|
|
|
// TODO this currently works differently
|
|
|
|
Aside from events, requests can be sent via a simple protocol.
|
|
For this, a simple tcp server is listening on the same port as the udp
|
|
event receiver and accepts requests for connecting to a device or to
|
|
request the keymap of a device.
|
|
|
|
```mermaid
|
|
sequenceDiagram
|
|
Alice->>+Bob: Request Connection (secret)
|
|
Bob-->>-Alice: Ack (Keyboard Layout)
|
|
```
|
|
|
|
## Problems
|
|
The general Idea is to have a bidirectional connection by default, meaning
|
|
any connected device can not only receive events but also send events back.
|
|
|
|
This way when connecting e.g. a PC to a Laptop, either device can be used
|
|
to control the other.
|
|
|
|
It needs to be ensured, that whenever a device is controlled the controlled
|
|
device does not transmit the events back to the original sender.
|
|
Otherwise events are multiplied and either one of the instances crashes.
|
|
|
|
To keep the implementation of input backends simple this needs to be handled
|
|
on the server level.
|
|
|
|
## Device State - Active and Inactive
|
|
To solve this problem, each device can be in exactly two states:
|
|
|
|
Either events are sent or received.
|
|
|
|
This ensures that
|
|
- a) Events can never result in a feedback loop.
|
|
- b) As soon as a virtual input enters another client, lan-mouse will stop receiving events,
|
|
which ensures clients can only be controlled directly and not indirectly through other clients.
|
|
|