Update README.md

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