From e93ec6f3ce7505074282943222d601aa142a8e6e Mon Sep 17 00:00:00 2001 From: Ferdinand Schober Date: Mon, 13 Feb 2023 19:13:22 +0100 Subject: [PATCH 1/4] Update README.md --- README.md | 45 ++++++++++++++++++++++++++++++++------------- 1 file changed, 32 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index f67de0c..f620b6b 100644 --- a/README.md +++ b/README.md @@ -2,12 +2,27 @@ 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. -## 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) +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. + +# 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 | + ## 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 +37,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 provides [libei](https://gitlab.freedesktop.org/libinput/libei) which might be a better approach in general (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,7 +74,7 @@ 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 @@ -63,8 +83,7 @@ Each event is sent as one single datagram so in case a packet is lost the event **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. -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. +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 +106,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 From 985419c829c38634eb5011940481f410de4a5c43 Mon Sep 17 00:00:00 2001 From: Ferdinand Schober Date: Mon, 13 Feb 2023 19:14:17 +0100 Subject: [PATCH 2/4] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f620b6b..b443f02 100644 --- a/README.md +++ b/README.md @@ -43,7 +43,7 @@ The [wlr_layer_shell protocol](https://wayland.app/protocols/wlr-layer-shell-uns ~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 provides [libei](https://gitlab.freedesktop.org/libinput/libei) which might be a better approach in general (TODO). +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 From 9cbb6a5fec1d0a9e7b614bde7a4e7d9f21c641e8 Mon Sep 17 00:00:00 2001 From: Ferdinand Schober Date: Mon, 13 Feb 2023 19:17:48 +0100 Subject: [PATCH 3/4] Update README.md --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index b443f02..e94856e 100644 --- a/README.md +++ b/README.md @@ -79,9 +79,11 @@ cargo run ## 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. +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. + **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. +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. From 3d8bef42e223cb7c221d6bc466e2a5a7f04cf50c Mon Sep 17 00:00:00 2001 From: Ferdinand Schober Date: Mon, 13 Feb 2023 19:23:25 +0100 Subject: [PATCH 4/4] Update README.md --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index e94856e..748d0f3 100644 --- a/README.md +++ b/README.md @@ -1,11 +1,12 @@ # 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 | @@ -15,6 +16,7 @@ Of course ***blazingly fast™*** and stable, because it's written in rust. | 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) | ## Wayland compositor support