DeskHop: a Raspberry Pi Pico KVM that switches desktops when the mouse crosses the screen edge

The problem DeskHop solves, and the desk it assumes

The README opens with the author's own workflow: two computers, one keyboard and mouse, and a series of USB switching boxes from Amazon that were slow to switch and clumsy to operate. DeskHop is the replacement. It is an intermediary device that holds a connection to both computers at once and decides where to forward mouse and keystrokes, so there is no re-enumeration delay on the host side and no software installed on either machine.

The intended user is specific. You have two desktops or laptops on one desk, you are comfortable building a small board (the README puts components under 15 euro), and you want switching to be a physical gesture rather than a button press. Keyboard follows mouse and vice versa, so dragging the pointer to the other monitor moves input with it. The README also claims full galvanic isolation between outputs, which matters if the two machines are on different power circuits or one is a work laptop you do not want electrically tied to your personal tower.

How the mouse crosses the monitor boundary

The mechanism is the interesting part. DeskHop is a USB host to your keyboard and mouse and a USB device to both computers. To make the pointer appear to jump between screens, the mouse HID report descriptor it presents was changed to absolute coordinates, while the reports arriving from the physical mouse are still relative movements. Firmware accumulates those deltas internally to keep an accurate position tally.

When the accumulated position tries to leave the monitor area in the direction of the other monitor, the firmware keeps Y and swaps the maximum X for a minimum X, then flips the outputs. The cursor appears at the same height on the other screen. The switch itself happens at the moment one arrow stops moving and the other starts, which is why the README describes it as having no noticeable delay. This is a design that depends on knowing your monitor geometry; it is not a generic pointer-routing protocol.

Keyboard hotkeys, LED feedback and the per-machine state

On the keyboard side DeskHop polls the keyboard as a USB host and watches the HID report for a preconfigured hotkey, which the README gives as usually Ctrl + Caps Lock. When it sees that combination it forwards subsequent characters to the other output. Keyboard LEDs can be repurposed as an indicator of which output is active, and the firmware remembers LED state per computer so caps lock or num lock is where you left it when you come back.

Several secondary combos are documented. Right ctrl + right alt toggles a slow-mouse mode for fine work such as dragging a video slider. Right ctrl + k locks you to the current screen so you cannot leave it by accident. Right ctrl + l locks both computers at once, and the README notes you must first configure the OS shortcut for each output in config, because the lock shortcuts differ between operating systems. That config dependency is easy to miss: the lock-both feature is only as good as the per-output shortcut you set.

Building DeskHop from source on Debian or Ubuntu

The project bundles a minimal pico-sdk and tinyusb to avoid version mismatch and path problems, so you do not download the full SDK. On Debian or Ubuntu the README lists the prerequisites:

apt update
apt install \
    build-essential \
    cmake \
    gcc-arm-none-eabi \
    libnewlib-arm-none-eabi \
    python3

With those installed, the build is two cmake commands from the repository root:

cmake -S . -B build
cmake --build build

The README also documents a container path for reproducible builds, and a separate step for the web configuration UI:

docker-compose -f misc/docker.yml run --rm build_container

Rebuilding the webconfig requires running ./render.py inside webconfig/ with jinja2 installed. Rebuilding the disk image is a separate script in disk/, and it needs dosfstools for mkdosfs. If you would rather not build at all, releases ship a single universal .uf2 image since version 0.6; you copy that file to the device rather than compiling anything.

Flashing firmware and the config-mode upgrade path

Firmware 0.6 and later can be upgraded without opening the case. Press left ctrl + right shift + c + o together. The keyboard's host computer reboots and appears as a USB drive named DESKHOP. Copy the .uf2 file to it. The device verifies the image, flashes, reboots, then upgrades the second board; the LED blinks during the operation. The README warns that this is not a real USB drive and you cannot use it to copy files.

The fallback is the ROM bootloader: hold the on-board button while connecting each Pico and copy the .uf2 to the drive that appears. Images after 0.6 support holding the button without unplugging power, but hold-while-plugging always works. Debug builds compiled with DH_DEBUG_CDC_FLASH=ON add a third route, a CDC serial command that resets the device into bootloader mode as an RPI-RP2 drive:

echo -n 'flash' > /dev/tty.usbmodem11104

That last option is explicitly aimed at development workflows, not at end users, and the README does not document any rollback path if a flash goes wrong.

Gaming mode is the honest admission that absolute coordinates break things

The most useful limitation is stated by the project itself. Some games do not work correctly with absolute mouse mode, and the same applies to various virtual machines and unsupported operating systems. Gaming mode, toggled with left ctrl + right shift + g, locks you to the current screen and makes the mouse behave as a standard relative mouse again.

Read that as a boundary rather than a feature. While gaming mode is on, the drag-to-switch gesture is unavailable; you are pinned to one machine. Anyone whose main use is a game that captures the pointer will spend most of their time in gaming mode, which removes the headline behaviour. The same applies to remote desktop and VM sessions where the guest expects relative input. DeskHop is a convenience layer for ordinary desktop use, and it says so.

How DeskHop differs from software KVM tools

The closest comparison people make is with software KVM and clipboard-sharing tools such as Deskflow, which run on each machine and move input over the network. The difference in approach is total: Deskflow installs on both hosts and needs them reachable over the network, and it can move clipboard content and files. DeskHop installs nothing, works across Linux, macOS and Windows because it presents standard USB HID to each host, and keeps the two machines galvanically isolated. In exchange it moves no files and no clipboard, needs two RP2040 boards plus a PCB and case, and occupies USB ports on both machines.

If your two machines cannot see each other on a network, or one is locked down so you cannot install software, DeskHop is the option that still works. If you want to copy a file from one desktop to the other, it is the wrong tool, and no amount of configuration changes that.

Maintenance, licence and what DeskHop costs you over time

DeskHop is licensed GPL-3.0 and is certified open source hardware, with the OSHWA certification linked from the README. The last push to the default branch was on 2026-09-21, one day before this writing, and the most recent release is v0.79 from 2026-09-13. The release cadence visible in the repository is roughly a few releases a year, with v0.77 in January 2026 and v0.78 in June 2026. That is a hobby-scale cadence, and the upgrade path through config mode is manual: you press a key combination and copy a file yourself.

For a GPL-3.0 hardware project, the practical implication is that if you modify the firmware and distribute a device running it, the licence's source-disclosure terms apply to what you ship. Building one for your own desk carries no such obligation. The README does not describe a support channel, a warranty, or a compatibility matrix beyond the three operating systems it names, so treat firmware updates as something you schedule rather than something that arrives.

Editorial conclusion

DeskHop suits people with two machines on one desk who are willing to solder two RP2040 boards, print or buy a case, and flash firmware by copying a .uf2 file. It is the wrong choice if you need file transfer between machines, more than two outputs, or a product with a support contract: the README describes a DIY device, the user manual is a PDF in misc/, and there is no vendor behind it. Before buying parts, open misc/user-manual.pdf and confirm the hotkey list (right ctrl + right alt for slow mouse, right ctrl + k for switch lock, left ctrl + right shift + g for gaming mode) matches the keyboards you actually own, since the config sets OS-specific shortcuts per output.

Frequently asked questions

Official sources

1. hrvach/deskhop on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases