LAN Mouse: Mouse and keyboard sharing software
github.com
github.com
It's a shame to see each Wayland DE become it's own incompatible thing. Even the lan-mouse readme's OS support table separates them as if they were their own OSes. Good luck in your very complex multi-faceted endeavour.
The main motivation was really to learn more about wayland at that point.
Then later I started to expand the project to support additional backends for e.g. Windows and MacOS (which currently only support input emulation) and of course Libei to get Gnome working as well (and likely KDE in the future).
For input emulation there is also support for the xdg-remote-desktop-portal which seems to be the only option for emulating input on KDE wayland until libei is supported there.
Input Capture using Libei is WIP since the whole project and particularly also the Rust bindings are in a pretty early state right now (thank you so much ids1024 for providing the reis libei bindings, if you are reading this!)
I agree, it's a shame that Wayland is so fragmented among the different DEs. Especially wlr-layer-shell support would be very nice to see on the Gnome Side (it was much easier to work with than libei!...) but I'm pretty sure that's not going to happen.
On the other hand I must also say that supporting wayland through the mentioned interfaces was a more pleasant experience than supporting Xorg with hacks like Xtst (Except for the broken implementation of the remote desktop interface in xdg-desktop-portal-kde maybe, which left me with permanently stuck keys several times...) and I'm still figuring out input capture which is likely also going to rely on more hacks than the wayland side of things.
I have also played with the idea of writing some sort of wlroots -> libei bridge that implements an eis server using the mentioned wlroots specific protocols. This would reduce the amount of backends required in lan-mouse but add an additional layer of indirection between the application and the compositor, so I'm not sure its such a great idea. For the foreseeable future, I will definitely keep support for everything within lan-mouse itself.
The primary target is Wayland on Linux but Windows and MacOS and Linux on Xorg have partial support as well (see below for more details).
Goal of this project is to be an open-source replacement for proprietary tools like Synergy, Share Mouse.
Focus lies on performance and a clean, manageable implementation that can easily be expanded to support additional backends like e.g. Android, iOS, ... .
blazingly fast™ because it's written in rust.
Synergy 1.x still exists and is completely open source. It compiles and works on desktop OSes from 1998 to 2024. Synergy 2 is the commercialized one.
I use this between my Windows, Mac and Wayland(Sway) computers.
Is the "blazingly fast" tagline satirical? Like, how would I compare the "fastness" of this implementation? I assume latency? Is Rust as a language choice the predominant minimizer of latency or is the dividing line between systems-level stuff (C, Rust, Cpp) or optimized networking (Go, etc) versus higher level stuff (python, etc).
It still is quite fast though I would say (I have not compared it to anything else though).
While moving a 1000Hz polling rate mouse, the cpu usage is about 2% of a single core on my machine (according to htop). It also uses udp to get the lowest possible latency (which e.g. barrier / input-leap does not afaik).
If you're looking to prove seriousness of the speed, I don't think CPU %, polling rate, or UDP-guesstimates are what you want. You probably want RTT measurements, which for I/O with mice via LAN is probably a little wonky to get and I guess will be dominated by network.
You could instrument your code and get latency b/w UI callback / USB poll and the time the packet hits the OS buffer / is written out (and reverse on receiver side). That's kind of the only meaningful metric that matters for I/O code and would ignore network effects, and here CPU time is a hard proxy to use.
As you said, I was thinking to get capture->send latency and receive->emulate latency and subtracting that from the RTT to get an estimate of both network and system latency (without the compositing / presentation latency of course which is likely the largest part without some 500hz monitor).
I was using windows and a sun box, the windows box had to be the one with the mouse/keyboard connected so ctrl-alt-delete would work.
I've used it and it works pretty well, is written in rust, and it has one big advantage - by emulating the keyboard and mouse at the linux evdev layer it avoids touching any of the desktop-specific apis. (It also has encryption, though over TCP so has issues with managing connections. I think your choice of UDP was a good one)
As for encryption I'm planning to use https://crates.io/crates/webrtc-dtls.
Udp also has the advantage of not needing to reconnect, which already makes it possible to switch between Wi-Fi and Ethernet seamlessly.
Maybe read this as "I recommend ..."
Udp also has other advantages besides speed. - Its session less, so any device going offline can simply come back online without needing to reestablish a tcp handshake. - The udp header is also substantially smaller than a tcp segment header (8 Bytes vs >= 20 Bytes). Not a huge difference but adds up to at least 12 KiB/s with a packet rate of 1000Hz and that is without the (potential) overhead of additional protocols like zmq or nng on top.
In this particular scenario the reliability of tcp is also not really necessary in my opinion.
I think overall it may be worth investigating if there is a noticeable difference.
All connections are via LAN. The display of the terminals on the host is not included.
I think even if you encrypted the UDP packets you may still be vulnerable to timing side channel attacks:
https://www.usenix.org/conference/10th-usenix-security-sympo...