diff --git a/README.md b/README.md index f67de0c..748d0f3 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,30 @@ # 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 only wayland is supported but I will take a look at xorg, windows & MacOS in the future. +Goal of this project is to be an open-source replacement for proprietary tools like [Synergy](https://symless.com/synergy), [Share Mouse](https://www.sharemouse.com/de/). + +Focus lies on performance and a clean, manageable implementation that can easily be expanded to support additional backends like e.g. Android, iOS, ... . + +Of course ***blazingly fast™*** and stable, because it's written in rust. + +For an alternative (with slightly different goals) you may check out [Input Leap](https://github.com/input-leap). + +# OS Support + +| Backend | Event Receiving | Event Emitting | +|---------------------------|--------------------------|--------------------------------------| +| Wayland (wlroots) | :heavy_check_mark: | :heavy_check_mark: | +| Wayland (KDE) | WIP | :heavy_check_mark: | +| Wayland (Gnome) | TODO (libei support) | TODO (wlr-layer-shell not supported) | +| X11 | WIP | TODO | +| Windows | WIP | TODO | +| MacOS | TODO (I dont own a Mac) | TODO (I dont own a Mac) | -## Very much unstable -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) ## Wayland compositor support +Wayland support for consuming and producing input-events currently relies on unstable wayland protocols: +- [zwlr\_virtual\_pointer\_manager\_v1](wlr-virtual-pointer-unstable-v1) is required to display surfaces on screen edges -> not supported by Gnome +- [virtual-keyboard-unstable-v1](https://wayland.app/protocols/virtual-keyboard-unstable-v1) and [wlr-virtual-pointer-unstable-v1](https://wayland.app/protocols/wlr-virtual-pointer-unstable-v1) are used to emulate input on wlroots compositors +- [kde-fake-input](https://wayland.app/protocols/kde-fake-input) is used to emulate input in KDE (WIP) + | Required Protocols (Event Emitting) | Sway | Kwin | Gnome | |----------------------------------------|--------------------|----------------------|----------------------| | pointer-constraints-unstable-v1 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | @@ -22,18 +39,23 @@ The protocols used for the virtual mouse and virtual keyboard drivers are curren | fake-input | :x: | :heavy_check_mark: | :x: | +The [wlr_layer_shell protocol](https://wayland.app/protocols/wlr-layer-shell-unstable-v1) will likely [never be implemented in Gnome](https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1141), so a Gnome-Shell extension is probably the way to go here. -Also the [wlr_layer_shell protocol](https://wayland.app/protocols/wlr-layer-shell-unstable-v1) is currently not available on Gnome and may very well [never be](https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1141). - -Likely [libei](https://gitlab.freedesktop.org/libinput/libei) will be the better choice going forward after all. -I will implement it as an alternative backend as soon as I have the time. ~In order for layershell surfaces to be able to lock the pointer using the pointer\_constraints protocol [this patch](https://github.com/swaywm/sway/pull/7178) needs to be applied to sway.~ (this works natively on sway versions >= 1.8) +For the receiving end, Gnome uses [libei](https://gitlab.freedesktop.org/libinput/libei) for input emulation, which might be the better approach in general moving forward (TODO). + + ## Build and run First configure the client / server in `config.toml`. (A misconfiguration currently does not produce a very informative error message) +Build only +```sh +cargo build +``` + Run ```sh cargo run @@ -54,17 +76,18 @@ cargo run - [ ] Liveness tracking (automatically ungrab mouse when client unreachable) - [ ] Clipboard support - [ ] Graphical frontend (gtk?) -- [ ] *Encrytion* -> likely DTLS +- [ ] *Encrytion* - [ ] Gnome Shell Extension (layer shell is not supported) ## Protocol considerations Currently *all* mouse and keyboard events are sent via **UDP** for performance reasons. -Each event is sent as one single datagram so in case a packet is lost the event will simly be discarded, which is likely not much of a concern. -**UDP** also has the additional benefit that no reconnection logic is required. -So any client can just go offline and it will simply start working again as soon as it comes back online. +Each event is sent as one single datagram, currently without any acknowledgement to guarantee 0% packet loss. +This means, any packet that is lost results in a discarded mouse / key event, which is ignored for now. -Additionally all server instances (in the future everything will be a server) host a tcp server where critical data, that needs to be send reliably (e.g. the keymap from the server or clipboard contents in the future) can be requested via a tcp connection. -For each request a new connection is established so clients can simply retry if a connection is interrupted. +**UDP** also has the additional benefit that no reconnection logic is required. +Any client can just go offline and it will simply start working again as soon as it comes back online. + +Additionally a tcp server is hosted for data that needs to be sent reliably (e.g. the keymap from the server or clipboard contents in the future) can be requested via a tcp connection. ## Bandwidth considerations The most bandwidth is taken up by mouse events. A typical office mouse has a polling rate of 125Hz @@ -87,5 +110,5 @@ In the future this can be used for e.g. clipboard contents as well. ## Security Sending key and mouse event data over the local network might not be the biggest security concern but in any public network or business environment 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 +- There should probably be an encryption layer below the application to enable a secure link +- The encryption keys could be generated by the graphical frontend