Hacker News Reader

Comment by galdan | Hacker News Reader

Lan Mouse is a mouse and keyboard sharing software similar to universal-control on Apple devices. It allows for using multiple pcs with a single set of mouse and keyboard. This is also known as a Software KVM switch.

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.

View on HN

> proprietary tools like Synergy

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.

You can also use its forked version here: https://github.com/debauchee/barrier

I use this between my Windows, Mac and Wayland(Sway) computers.

Barrier is succeeded by input-leap

https://github.com/input-leap/input-leap

It... doesn't work with wayland? At least not as far as I've been able to get working

Hmm I could be mistaken, perhaps it was when I still was on X..

Yes, you are right. I probably should have stated that more clearly. (I did mention input-leap though, which is a fork of synergy 1.x as far as I'm aware)

Honest question:

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).

I am a part-time rust programmer at best, and it was my understanding of the Rust design that it goes something like "Systems programming and memory safety without sacrificing performance" not "automatically faster", unless you compare only to "memory safety without performance guarantees" e.g., Python, JS/CLI, Java, etc. It seems to me that Go lives in this same domain where it intersects networked systems programming.

Yes, it's meant satirical (mostly). Simply because its rust and people say rust is "blazingly fast".

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).

OK. Thanks for clarifying. That makes sense, sorry for being humorless!

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.

Yeah I was planning to do some RTT measurements at some point but have not gotten round to implementing it. Would be great to have that directly in the ui as well!

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 used to run synergy back in the pentium III days, the trick was to change the windows service priority to real time - once that was done there was no noticeable mouse lag.

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.

You might take some inspiration (or some code) from https://github.com/htrefil/rkvm

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)

Definitely going to take a look! I wanted to have the seemless movement to different PCs experience so that's why I can't read events directly from evdev. For emulating it would probably be quite useful! And maybe also in conjunction with the current methods...

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.

Another honest question. Given the availability of way better options like zmq, nng, etc, why do people still reach for raw udp/tcp?

Maybe read this as "I recommend ..."

udp is supported everywhere and also in the rust standard library as well as tokio. zmq and nng from what I can tell are both implemented on top of the transportation layer and use tcp under the hood.

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.

I would recommend the addition of a cheeky ™ after "blazingly fast".

way ahead of you :)

Reply on news.ycombinator.com