rkvm shares one keyboard and mouse across several Linux machines

A KVM over the network, driven by raw keycodes

rkvm is described as a tool for sharing keyboard and mouse across multiple Linux machines, and it uses a client and server architecture where the server is the machine that owns the physical keyboard and mouse and relays events such as mouse movement and key presses to the clients. Switching between clients is done with a configurable keyboard shortcut, so the workflow is the one people already know from a hardware KVM switch, except the switch is now a network hop. The project is written in Rust, is MIT licensed, and the repository is not archived, with the last push on 2026-09-26. The release history is thinner than the push history: the latest tagged release is 0.6.1 from 2024-07-13, before 0.6.0 in December 2023 and 0.5.1 in October 2023. The topics list places it in keyboard, kvm, mouse and remote-management territory, and the homepage field is empty, so the README and the repository are the whole documentation.

Why keycodes and not characters

The README devotes a section to explaining why rkvm is not Barrier or Synergy, and the reason is concrete rather than ideological. The author's problem with those programs was his own Czech keyboard layout not being supported properly, and the explanation is about direction of translation: those programs send characters and then attempt to translate them back into keycodes. rkvm takes the opposite approach and sends raw keycodes only, so it makes no assumption about the layout in use. That matters beyond exotic layouts. Any layout where a key produces more than one character, or where characters are produced by combinations, breaks a character-based protocol in ways that are hard to debug, and the symptom is the sort of thing that gets misdiagnosed as a display server issue. The second difference is architectural. rkvm does not know or care about X, Wayland or any display server in use, because it reads and generates input events through the uinput API with libevdev. The listed features follow from this: TLS encryption by default backed by rustls, a display server agnostic design that in fact does not require a display server at all, and low overhead.

The workspace and where each responsibility sits

The Cargo.toml defines a workspace with resolver 2 and five members, and the README project structure section names the same five directories in the tree, which makes the split easy to read. rkvm-server holds the server application code, rkvm-client the client application code, rkvm-input handles reading from and writing to input devices, rkvm-net covers the network protocol encoding and decoding, and rkvm-certificate-gen is the certificate generation tool. Two technology choices are stated for the network layer: Bincode is used for encoding of messages on the network, and Tokio is the asynchronous runtime. Bincode is a compact binary encoding, which suits a protocol whose messages are mostly small event records, and Tokio gives both ends the same asynchronous task model so the server can hold several client connections while still forwarding input at a steady rate. The top level also carries switch-keys.md, which is where the binding and switching behaviour is documented, plus an example/ directory with client.toml and server.toml and a systemd/ directory with the unit files.

Building it and installing the pieces

The README recommends the AUR package if you can use it, and warns that the master branch can contain untested and breaking changes, so for regular use it recommends picking the latest release. The manual installation path is a Cargo build followed by copying the binaries and unit files into place.

$ cargo build --release
# cp target/release/rkvm-client /usr/bin/
# cp target/release/rkvm-server /usr/bin/
# cp target/release/rkvm-certificate-gen /usr/bin/ # Optional
# cp systemd/rkvm-client.service /usr/lib/systemd/system/
# cp systemd/rkvm-server.service /usr/lib/systemd/system/

The certificate generator is marked optional because you can bring your own certificate from another source. The build has prerequisites, and the README lists them plainly: the uinput Linux kernel module, which is enabled by default in most distributions and can be confirmed by checking that /dev/uinput exists, the libevdev development files installed with sudo apt install libevdev-dev on Debian and Ubuntu, and Clang and LLVM installed with sudo apt install clang. So the tool is not a statically linked binary you can drop anywhere; it needs a kernel interface, a development library and a C compiler toolchain present at build time.

Certificates, config files and the password

After installation you generate a certificate and private key with rkvm-certificate-gen, or supply your own. The server needs both, placed as /etc/rkvm/certificate.pem and /etc/rkvm/key.pem respectively, while the client needs only the certificate, at /etc/rkvm/certificate.pem. The config files are copied from the packaged examples, one per role.

  # cp /usr/share/rkvm/examples/server.toml /etc/rkvm/server.toml
  # cp /usr/share/rkvm/examples/client.toml /etc/rkvm/client.toml

The README warns not to edit the example configs, because they will be overwritten by your package manager, which is a practical warning for anyone on a distro that ships rkvm as a package rather than built from source. Two settings are called out for attention: change the password, and optionally reconfigure the network listen address and the key bindings for switching clients. Since the server is the machine holding the real input devices, those two values are the difference between a working setup and a dead one, and the switch binding is what lets you move the pointer back to the server machine from a client.

The failure mode to test for before you switch on the service

This is the part of the README that deserves the most attention, because rkvm-server grabs all input. The advice is to do a test run first, to make sure you will not end up unable to use your keyboard and mouse because your display server is not properly configured to receive input from rkvm. The mechanism is a shutdown timer.

  # rkvm-server /etc/rkvm/server.toml --shutdown-after 15

That command runs the server for 15 seconds, which gives you a window to confirm that input still reaches your display server before the service is left running indefinitely. Without the timer, a misconfigured server takes the keyboard with it and the machine becomes hard to recover from without a physical console. Once the test passes, the systemd units are enabled and started for each role.

  # systemctl enable rkvm-server
  # systemctl start rkvm-server

The client side uses the same pattern with rkvm-client. The units come from the systemd/ directory in the repository and are copied into /usr/lib/systemd/system/ during installation.

Where rkvm is the wrong choice

The README states the limitation plainly: Linux only. There is no Windows or macOS server, so a mixed desk with a Mac or a Windows laptop cannot use rkvm as the controlling side, which is a real constraint for anyone whose neighbours run different systems. The second point is that the author of rkvm himself says that if you want a working and stable solution for cross platform keyboard and mouse sharing, you should probably use Barrier or Synergy for the time being. That is worth repeating because it is the honest position of the author, not a hedge: rkvm is the better answer for a Linux only desk with awkward layouts, and the alternative is better for the mixed platform case, because it already speaks the other platforms. The third limitation is maintenance shape. The repository was pushed to on 2026-09-26, which is recent, but the last tagged release is 0.6.1 from 2024-07-13, so the recent work is on the master branch rather than in a shipped release, and the README explicitly warns that master can contain untested and breaking changes. That means a team that wants a pinned, reproducible deployment has to build a specific commit and own the upgrade decisions itself. The fourth is the security model. TLS with rustls protects the link between server and client, and the certificate is the trust anchor, but the server still injects input into the client machine as if it were a local keyboard, so the client trusts the server completely by design.

Editorial conclusion

Adopt rkvm if you run two or more Linux machines on one desk and your keyboard layout is not handled correctly by Barrier or Synergy, because rkvm sends raw keycodes and never translates characters back into keycodes, and it does not care whether you use X, Wayland or no display server. Do not adopt it if any machine in your setup runs macOS or Windows, since the README lists Linux only as the limitation and rkvm does not implement the server side for those platforms. Verify two things before you rely on it: that /dev/uinput exists on every machine, since the whole design depends on the uinput module, and that the released 0.6.1 binary rather than the master branch is what you deploy, because the README warns that master can contain untested and breaking changes. The practical first step is to build with cargo, then run rkvm-server with the --shutdown-after 15 flag so you can confirm your display server still receives keyboard and mouse input before the server takes over the devices.

Frequently asked questions

Official sources

1. htrefil/rkvm on GitHub
2. Issues
3. License: MIT
4. README
5. Releases