A Logitech Unifying or Bolt receiver behind a KVM switch: what works

A Logitech Unifying or Bolt receiver behind a KVM switch will type on almost any port the KVM offers. What changes from port to port is everything else. A KVM's dedicated keyboard and mouse ports usually emulate a generic keyboard and mouse, which keeps the KVM's hotkeys working and hides the receiver from the computer. Its plain USB 2.0 or 3.0 ports behave like a switched hub and hand the whole receiver over, which is what Logi Options+, Solaar and any layout tool need, at the cost of the KVM's keyboard hotkeys.

That choice decides whether software can talk to the keyboard at all. The studio's Logitech Layout Auto Switcher, which corrects a keyboard's Mac or Windows mode after a KVM switch, is in the same position: it works with the receiver on a hub port and cannot reach the keyboard through an emulated one. What follows is the wiring: the two kinds of port, how to tell which one you are on, and the alternatives.

Two kinds of USB port on one KVM

Most desktop KVMs carry two sets of USB sockets, and the manuals rarely explain the difference. TESmart's support pages are unusually direct about it. Its article on typing delay and repeated keys says the USB 2.0/3.0 ports "lack dedicated chips, so connecting the keyboard and mouse to these ports essentially mirrors a direct connection to the computer". Its KVM FAQ gives the price: "using the USB 2.0/3.0 port will disallow keyboard hotkeys for switching. Only dedicated keyboard/mouse ports have hotkey functionality."

A July 2026 TESmart post on wireless mouse lag describes what the dedicated ports do: they "may use KVM USB HID emulation. Instead of exposing the exact physical device to each computer, the KVM presents a basic keyboard or mouse identity." A shared USB port, by contrast, "usually behaves more like a switched USB hub. The complete receiver is assigned to the active computer, allowing the operating system to enumerate its available interfaces." The same post names the symptom Logitech owners see on an emulated port: "The keyboard works but Logi Options+ cannot detect the device."

The last row comes from a user, not a vendor: the reporter of the Solaar issue below describes the TESmart's emulation as being "for not always reconnecting devices when switching".

Why software needs the receiver, not a keyboard

Typing is plain USB HID. Button remapping, battery level, the Easy-Switch host and the keyboard's Mac or Windows mode all go over HID++, Logitech's own protocol. A receiver carries it on a separate vendor-defined HID collection, usage page 0xFF00, beside the ordinary keyboard and mouse collections. The protocol notes in the Layout Auto Switcher repository list the details, and the agent's discovery code matches on exactly that collection with Logitech's vendor id, 0x046D.

An emulating port strips or rewrites that path, and two Solaar issues show what that looks like from the computer's side.

In issue #908, from 2020, a Unifying receiver behind a KVM appeared as a "Microsoft Wired Keyboard 600". The maintainer explained why Solaar could not use it: Solaar "sends and receives messages using Logitech-specific extensions to the HID protocol that need to be sent to or come from a Logitech receiver", and he doubted "the faked-up device will do the right thing for these messages".

Issue #2901, from June 2025, is more instructive because the reporter moved one receiver between two ports on the same TESmart KVM, a DKS402-E23. On the port marked for the mouse, the receiver enumerated as 046d:c62c "USB Receiver", reported HID++ 1.0 and answered every query with an error, so Solaar listed it as an unknown device. On another USB 2.0 port of the same KVM it enumerated as 046d:c52b "Unifying Receiver" and Solaar configured it. In lsusb -v output the hub port matched a direct connection; the mouse port differed in the product id. The maintainer's conclusion: "the KVM is providing its own information to Linux when using the mouse port", and Solaar cannot recover from that.

Two details are worth keeping. TESmart calls that mouse support "Pass through", yet the port still altered the receiver, so "pass-through" on a spec sheet is not proof that HID++ reaches the computer. And the reporter relays TESmart support's answer that the dedicated sockets carry added logic so hotkeys can work. Hotkeys or HID++: that is the trade.

What Logitech says

Logitech's position is stricter. Its Logi Bolt troubleshooting article lists "plugging the receiver into a USB hub or other unsupported device such as a KVM switch" as a likely cause of dropped connections, lag and devices that will not connect, and says the receiver "must be plugged directly into your computer". Its older per-product pages, such as the one for the K800, say that "manufacturers implement keyboard and mouse support in various, non-standard ways".

So any KVM is off Logitech's supported path, and the hub port is the closer of the two to what Logitech asks for.

Radio, not just data

TESmart's lag post also warns that "certain USB 3.x devices, connectors, and cables can produce radio-frequency noise in or near the 2.4GHz band", and suggests a short extension cable, which "changes the receiver's RF position without changing the USB data path". Logitech's Bolt article likewise says to move the receiver closer and keep other wireless devices away. A receiver that works on the hub port but drops keys has a radio problem, not a port problem.

How to tell which port you are on

Look at what the computer thinks is plugged in. The receiver should appear under its own name and ids: Solaar's base_usb.py lists the Bolt receiver as 0xC548 and the Unifying receiver as 0xC52B, both under vendor 0x046D.

On macOS, either of these lists every USB device with its vendor and product id:

ioreg -p IOUSB -l -w0 | grep -E '"USB Product Name"|"idVendor"|"idProduct"'
system_profiler SPUSBHostDataType

ioreg prints the ids in decimal: 1133 is 0x046D, 50504 is 0xC548 and 50475 is 0xC52B. On Linux, lsusb prints them in hex. On Windows, Device Manager's View menu has "Devices by connection", which shows the receiver under the KVM's hub.

If the receiver is missing and a KVM-branded or generic keyboard is listed instead, or the Logitech entry carries an unexpected product id, as in Solaar #2901, the port is emulating. Move the receiver to a USB 2.0 port and check again.

If Layout Auto Switcher is installed, logiswitch doctor answers the same question from the HID++ side. It prints each Logitech endpoint it found with its vendor and product id, or reports "no Logitech HID++ endpoint found" when nothing answered, and it tells a receiver with no keyboard behind it apart from no receiver at all.

The problem a hub port does not solve

With the receiver on a hub port, software can reach the keyboard again, and one KVM-specific fault remains. A Logitech keyboard stores its Mac or Windows mode per Easy-Switch channel, and the receiver occupies one channel. A KVM moves that receiver, on that channel, from one computer to the other, so the keyboard keeps the mode the previous computer left it in, and ⌘ arrives on Windows acting as Alt. The mechanism, the Fn+O and Fn+P combinations, and the HID++ feature behind them are covered in why your Logitech keyboard types the wrong keys after a KVM switch.

Logi Options+ will not catch it, even with its "Always keep the keyboard in Mac layout" setting on. Measured with Options+ 2.6.941708 on macOS, it corrected the platform once, about seven seconds after its agent started, and then left a wrong value alone for the 35 and 45 seconds it was watched. A KVM switch restarts nothing, so the setting does not hold across one. That measurement is in the protocol notes.

What does work is writing the platform at the moment the receiver arrives on a computer. On a hub port, the receiver really does unplug from one machine and plug into the other, so each operating system sees a device arrive, and that event is the trigger.

From the studio: Layout Auto Switcher listens for that arrival on Windows and macOS and writes the keyboard's platform for the machine it runs on, the same value Fn+O or Fn+P would set. It is verified end to end on an MX Keys S through a Logi Bolt receiver behind a TESmart KVM, where the switch takes 326 ms.

Its support is decided by capability, not by a model list: any device that advertises HID++ feature 0x4531, or the older 0x4530, is driven, whether it sits behind a Bolt, Unifying, Nano or Lightspeed receiver or is connected directly over Bluetooth or USB. The recorded profile of the test rig, in the repository's probe results, shows the receiver behind a TESmart DKS202-P24 enumerating under its own id, 046D:C548, with both HID++ collections visible. Other models are expected to work by the same capability check and have not been tested.

The other wiring choices

A receiver per computer, KVM for video only

Give each computer its own receiver, pair the keyboard to both on separate Easy-Switch channels, and let the KVM switch only the screens. Each channel then keeps its own platform, which removes the conflict at its root. The cost is that you switch the keyboard with its Easy-Switch key, separately from the KVM. No receiver unplugs in this arrangement, so there is no arrival event either. If you still run Layout Auto Switcher, it reacts to the keyboard announcing itself on the new channel, measured at 1.1 s on the MX Keys S, re-checks every 20 seconds as a backstop, and --claim-host N pins each machine to its own channel.

Bluetooth to one machine, the receiver to the other

TESmart's FAQ notes that its KVMs have no Bluetooth, so "any Bluetooth device will bypass the KVM and connect directly to the computers". That makes Bluetooth a channel of its own. One machine gets the receiver, the other gets Bluetooth, and each channel remembers its own platform. It is the arrangement suggested in a ComputerBase thread about sharing an MX Keys between a PC and a MacBook through a KVM, and like the option above, it gives up having the keyboard follow the KVM button.

The receiver on the dedicated keyboard port

This keeps the KVM's hotkeys and loses HID++. Typing works, but Options+, Solaar and Layout Auto Switcher may not see the device, so the platform can be changed only by hand, with Fn+O or Fn+P after every switch. If you rely on the hotkeys and need none of the software features, that is a fair trade. TESmart's FAQ also documents switching from the front-panel button and a remote, which stand in for the hotkeys on a hub port.

Start by moving the receiver to one of the KVM's USB 2.0 ports and confirming the computer lists it under its own id. If the modifier keys are then wrong after each switch, that is the platform mode, and the earlier post covers it in detail.