Lan Mouse: a Rust software KVM for sharing one keyboard and mouse across machines

What Lan Mouse does that a hardware KVM does not

A hardware KVM switch sits between your peripherals and your machines. Lan Mouse removes the switch: each computer stays connected to its own monitor and its own network cable, and the keyboard and mouse events travel over the LAN instead. The README describes the goal plainly, calling it an open-source alternative to proprietary tools such as Synergy 2/3 and Share Mouse, and to other open source tools including Deskflow and Input Leap. The target audience is anyone running two or more desktops side by side, typically a work laptop next to a personal machine, where buying a second set of peripherals or a physical switch is the alternative.

The project is published under GPL-3.0-or-later and is written in Rust. The README's own framing of that choice is that it is "blazingly fast™ because it's written in rust", which is marketing rather than a measurement. What the source tree does support is a modular structure: input-capture, input-emulation, input-event, lan-mouse-proto, lan-mouse-ipc, lan-mouse-cli and lan-mouse-gtk are separate workspace members, so capture and emulation are pluggable backends rather than one monolith. That is the design decision worth caring about, because it explains both the platform coverage and the caveats.

The capture, protocol and emulation pipeline

The workspace layout tells most of the story. A capture backend on the sending machine grabs input events, those events are serialised into the lan-mouse-proto format, sent over the network, and replayed on the receiving machine by an emulation backend. The two sides are independent: the README notes that support for other platforms is omitted automatically based on the active Rust toolchain, and that backends and frontends can be selected manually through cargo features. A build with only the layer-shell capture backend and the wlroots emulation backend is possible, which produces a much smaller binary for a single-compositor setup.

Networking uses TCP and UDP, per the repository topics, and all traffic is encrypted. The README states that Lan Mouse encrypts all network traffic using the DTLS implementation provided by WebRTC.rs, and that there are currently no mitigations in place for timing side-channel attacks. That second sentence is the project being honest about its threat model: DTLS gives you confidentiality against a passive listener on the LAN, not resistance to an adversary who can measure packet timing. The Cargo.toml pulls in webrtc-dtls, webrtc-util, rustls with the ring provider, and rcgen, which is consistent with generating certificates locally and negotiating DTLS without a central authority.

Configuration lives in config.toml at the repository root, alongside a de.feschber.LanMouse.desktop entry, a firewall/ directory with a firewalld service definition, and a service/ directory. The GTK frontend depends on gtk4-rs and libadwaita per the repository topics, and the README notes the project is "now with a gtk frontend", so the graphical configuration window is a newer addition rather than the original interface.

Installing on Arch, Fedora, Nix and macOS

Distribution packaging is the shortest path. On Arch Linux the package is in the official repositories, and a prerelease build tracking main is on the AUR:

pacman -S lan-mouse
paru -S lan-mouse-git

The first command installs the released version; the second installs the AUR package that follows the main branch. On Fedora, after enabling the Terra repository, the README gives a single command:

sudo dnf install lan-mouse

For Nix and NixOS, the README points to nixpkgs and to the flake documentation under nix/README.md rather than printing a command, so check that file for the current flake usage. On macOS the README describes downloading the Intel or ARM package from the releases page, unzipping it, and clearing the quarantine attribute before launching:

xattr -rd com.apple.quarantine "Lan Mouse.app"

After launching, macOS builds run as a menu bar app with no Dock icon, and you must grant accessibility permissions in System Preferences. That permission is not optional: without it the emulation backend cannot inject events. On Windows, precompiled binaries are in the releases section and the README states the dependencies are included in the .zip file. If you prefer to build it yourself, cargo and nix both work:

cargo install lan-mouse
nix-build

cargo install places the binary in ~/.cargo/bin; nix-build leaves it in result/bin/lan-mouse. For a source build with only the backends you need, the README gives this example:

cargo build --no-default-features --features layer_shell_capture,wlr

That produces an executable with the layer-shell capture backend and the wlroots emulation backend only. The optional post-install steps, copying the binary to /usr/local/bin, installing the icon and desktop entry, and dropping firewall/lan-mouse.xml into /etc/firewalld/services, are listed in the README for firewalld users. First real use is then a two-machine exercise: start Lan Mouse on both hosts, add each machine as a peer in the GTK window, and move the pointer off the edge of one screen toward the other.

Where Lan Mouse breaks down

The caveats section is the most important part of the README, and it is blunt. X11 only has support for input emulation, which means an X11 machine can receive input but cannot send it. If your main desktop is still on X11, Lan Mouse is the wrong tool for the sending side regardless of how well it installs.

On Sway and other wlroots compositors without libei support, modifier events are not handled on the client side, so CTRL, SHIFT, ALT and SUPER do not work when the sending device is not using the layer-shell backend. That is a functional gap, not a cosmetic one: keyboard shortcuts are most of what people do with a shared keyboard. Wayfire users need a recent version, newer than October 23rd, and must add shortcuts-inhibit to the plugin list in their Wayfire configuration or input capture will not work at all. On Windows, the mouse cursor is invisible when sending input to a Windows system that has no real mouse connected. That last one is easy to dismiss and hard to live with, because you lose the visual reference for where the pointer is.

There is also a security caveat the README states directly: there are currently no mitigations in place for timing side-channel attacks. And there is a scope limit worth naming. Clipboard sharing is not described anywhere in the README, so if synchronising the clipboard between machines is a requirement, Lan Mouse does not document that capability and you should not assume it.

How it differs from Input Leap and Deskflow

The README names both Deskflow and Input Leap, the latter described as a Synergy fork, as the other open source tools in this space. The practical difference is the backend model. Input Leap and Deskflow inherit a long lineage from Synergy, and their input handling was built around X11 and later extended toward Wayland. Lan Mouse was written for Wayland compositors first: the topics list wayland, wayland-client, wlroots and hyprland, and the capture backends are named after Wayland mechanisms such as layer-shell rather than after X11 extensions.

That shows up in the caveat list. Lan Mouse treats X11 as a receive-only platform, which is the opposite of the historical arrangement in the Synergy lineage, where X11 was the primary target. If your fleet is mostly X11, Input Leap or Deskflow is the more natural fit. If your fleet is GNOME 45 or newer, KDE Plasma 6.1 or newer, Sway 1.8 or newer, Hyprland or Wayfire, Lan Mouse's backend set maps onto those compositors directly. The Rust implementation and the cargo feature flags are a second difference: you can build a binary containing only the backends your machines use, which is not the packaging model of the older C++ tools.

Maintenance, licensing and what upgrades cost you

The repository is not archived, and the last push was on 2026-09-21. Recent releases are tagged with commit hashes rather than version numbers, for example main-7441c08, main-b81c595 and main-17d64ca, all within the last few days of that push. Those tags follow the main branch rather than a stabilised release line, and the AUR package lan-mouse-git is described as the prerelease version following main. If you install from the official Arch repository or from Fedora's Terra repository, you get a packaged release; if you install lan-mouse-git or build from source, you are tracking main and should expect the interface and configuration to move.

The licence is GPL-3.0-or-later, and Cargo.toml declares it as such. That matters if you intend to redistribute a modified binary or ship it inside a product: the GPL's source-availability terms attach to derivative works. Nothing here is legal advice, and the specific obligations depend on how you distribute. For internal use across your own machines, the licence is not a practical obstacle. The upgrade cost is tied to the release model rather than to the licence: because releases are tagged by commit, there is no changelog-driven upgrade path described in the repository, so pinning a packaged version from your distribution is the lower-variance option.

Editorial conclusion

Adopt Lan Mouse when every machine in the setup runs a current Wayland compositor, Windows or macOS, and you want a GPL-3.0 implementation you can compile yourself with a GTK configuration window. Do not adopt it if any participating machine is X11 and needs to send input, if you need clipboard sync, or if you need a solution for Android or iOS rather than the proof-of-concept mobile app. Before rolling it out, check the caveats section for your compositor, confirm that a real mouse is attached to any Windows machine that will receive input, and verify that the layer-shell capture backend is available on the sending side if you rely on modifier keys.

Frequently asked questions

Official sources

1. feschber/lan-mouse on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases