mirror of
https://github.com/feschber/lan-mouse.git
synced 2026-03-13 00:00:53 +03:00
51 lines
2.6 KiB
Markdown
51 lines
2.6 KiB
Markdown
# Lan Mouse Share
|
|
Goal of this project is to be an open-source replacement for tools like [Synergy](https://symless.com/synergy) or [Share Mouse](https://www.sharemouse.com/de/).
|
|
Currently on wayland is supported but I will take a look at xorg, windows & MacOS in the future.
|
|
|
|
## Very much alpha state
|
|
The protocols used for the virtual mouse and virtual keyboard drivers are currently unstable and only supported by wlroots:
|
|
[zwlr\_virtual\_pointer\_manager\_v1](wlr-virtual-pointer-unstable-v1)
|
|
[virtual-keyboard-unstable-v1](https://wayland.app/protocols/virtual-keyboard-unstable-v1)
|
|
|
|
Currently the mouse moves in a circle when receiving a(ny) udp packet on port 42069.
|
|
|
|
## TODO
|
|
- [x] Capture the actual mouse events on the server side via a wayland client and send them to the client
|
|
- [x] Mouse grabbing
|
|
- [ ] Window with absolute position (wlr\_layer\_shell?)
|
|
- [x] DNS resolving
|
|
- [ ] Multiple IP addresses -> check which one is reachable
|
|
- [ ] [WIP] Keyboard support
|
|
- [ ] [WIP] Scrollwheel support
|
|
- [x] Button support
|
|
- [ ] Merge server and client -> Both client and server can send and receive events depending on what mouse is used where
|
|
- [ ] Liveness tracking (automatically ungrab mouse when client unreachable)
|
|
- [ ] Clipboard support
|
|
- [ ] Graphical frontend (gtk?)
|
|
- [ ] *Encrytion* -> likely DTLS
|
|
- [ ]
|
|
|
|
## Protocol considerations
|
|
Currently UDP is used exclusively for all events sent and / or received.
|
|
The most bandwidth is taken up by mouse events. A typical office mouse has a polling rate of 125Hz
|
|
while gaming mice typically have a much higher polling rate of 1000Hz.
|
|
A mouse Event consists of 21 Bytes:
|
|
- 1 Byte for the event type enum,
|
|
- 4 Bytes (u32) for the timestamp,
|
|
- 8 Bytes (f64) for dx,
|
|
- 8 Bytes (f64) for dy.
|
|
Additionally the IP header with 20 Bytes and the udp header with 8 Bytes take up another 28 Byte.
|
|
So in total there is 49 * 1000 Bytes/s for a 1000Hz gaming mouse.
|
|
This makes for a bandwidth requirement of 392 kbit/s in total _even_ for a high end gaming mouse.
|
|
So bandwidth is a non-issue.
|
|
|
|
In the future to support clipboard contents the easiest solution to not block
|
|
mouse events while receiving e.g. a large file is probably to send these via tcp simultaneously.
|
|
This way we dont need to implement any congestion control and leave this up to tcp.
|
|
|
|
|
|
## Security
|
|
Sending key and mouse event data over the local network might not be the biggest security concern but in any public network it's QUITE a problem to basically broadcast your keystrokes.
|
|
- There should probably be an encryption layer using DTLS below the application to enable a secure link
|
|
- The keys could be generated via the graphical frontend
|