v2.3.0

2.3.0

Switching a computer off no longer causes the machines still running to fight you for your mouse. Alongside that, the interactive display now uses your terminal's own colours instead of painting a dark theme over them, and there's a project page at https://coddingtonbear.github.io/logitech-flow-kvm/ if you want to point someone at what this tool does.

At a glance

Features

• Terminal-native display — the TUI painted its own dark theme over whatever your terminal was set to
• r to resynchronise — nothing short of a restart made a client re-check its state on demand

Bug fixes

• Devices sent to a host that isn't there — turning off one computer left the others shoving your mouse at it every couple of seconds, forever

---

Features

Terminal-native display: the TUI painted its own theme over your terminal's

flow-server and flow-client rendered through Textual's default dark theme — its own background, its own foreground — so the display fought whatever colour scheme the terminal was already using, and looked wrong in a light one. The log pane also carried a border, scrollbars, and focus shading that a log doesn't need.

Both programs now use the terminal's own foreground and background, with colour kept only where it carries information: the status panel's border and the connected/disconnected markers. The log pane is just a log, word-wrapped to the real width of the widget — Textual's default 78-column minimum would previously overflow invisibly on a narrower terminal once the horizontal scrollbar was hidden. The pairing dialog's border rendered as broken half-blocks under the new theme, so it matches the status panel now.

r to resynchronise: a client had no way to re-check anything on demand

A client re-announces its devices and relearns where the leader is whenever its connection to the server is re-established, which covers essentially everything — but only on its own schedule. If you were watching the display and wanted it to happen now, the only lever was restarting the process.

Pressing r in flow-client's display re-announces every device this host can see and drops the reconnect backoff, so whatever state is stale gets refreshed immediately.

Bug fixes

Devices driven at a host that can't be reached

Turn off the machine running flow-server, and the client would keep telling your mouse to switch to it — once every couple of seconds, indefinitely. Pressing the button on the mouse to bring it back worked for about two seconds, and then it was gone again.

Where the leader device is comes from that device connecting to a host and that host reporting it, and that report had no expiry. A host that stopped existing therefore stayed a perfectly valid target to be driven at, and because a receiver can only push a device away and never pull one back, nothing but your own hand could undo it.

Knowledge of the leader's whereabouts now expires along with the connection that supplied it:

• A client stops acting on the leader's host once it can't reach the server. There's a ten-second grace period first, so a wifi blip or a server restart — both common, both self-healing — doesn't stall a switch you just asked for.
• The server retracts the leader's host when the client that reported it disconnects. This covers the case a client can't see for itself: some other machine unplugged while the leader was on it, leaving everyone else aiming at it.
• A host holding the leader never drives devices away from itself. Each client tracks the leader's presence from its own device notifications, which outranks anything the server tells it. Without this, a server process that outlived a network partition would hand back its pre-outage view before the client's own re-announcement had corrected it, and the followers would be flung at the host the leader had just left.

While this is in effect nothing moves, which leaves your devices on a host that demonstrably works. flow-client marks it in the status panel (Leader host 1 (unreachable -- holding devices here)), and both programs log entering and leaving the state.

Recovery needs nothing from you. When the missing machine comes back, every host re-announces the devices it can see, everyone relearns where the leader actually is, and switching resumes by itself — within about five seconds, since the reconnect backoff is now capped there rather than at thirty. If you don't want to wait, r in the client's display does it immediately, and so does pressing the host button on your keyboard: that's the same evidence arriving by the most direct route there is.

Upgrading

No migration, and mixed versions are safe: a 2.2.1 client ignores the one new event 2.3.0's server can send it, and carries on behaving exactly as it did before. You'll want every machine on 2.3.0 to actually get the fix above, but nothing breaks while you're getting there.

Full changelog: v2.2.1...v2.3.0