mirror of
https://github.com/feschber/lan-mouse.git
synced 2026-03-07 20:09:59 +03:00
84 lines
2.8 KiB
Markdown
84 lines
2.8 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:
|
|
|
|
Events can only be sent to active clients.
|
|
Events can only be received from inactive clients.
|
|
|
|
Active denotes that a particular device is controlled by the local pc.
|
|
|
|
Any event received from an active device is ignored unless it is a state change request.
|
|
In this case the device is marked as inactive and no further events are sent to the device.
|
|
|
|
The received events are then processed until a further state change to active
|
|
is requested (when the corresponding layer surface is entered).
|
|
|
|
**In short:** The invariance "each client either sends or receives events" must
|
|
always be true.
|