Why your Logitech keyboard types the wrong keys after a KVM switch

When a Logitech MX Keys types the wrong keys after a KVM switch, the keyboard is still in the platform mode the previous computer used. That mode lives in the keyboard's firmware, not in macOS or Windows, and the keyboard keeps one value per Easy-Switch channel. A KVM hands the same receiver, on the same channel, to a different computer, so the keyboard has no reason to change, and ⌘ goes on behaving as Alt until you hold Fn+O or Fn+P. The studio's Logitech Layout Auto Switcher writes that same setting for you each time the keyboard arrives on a machine.

This is not your input language. Arabic appearing where you expected English is a separate setting on the computer, with a separate fix, covered further down.

Three faults that look the same

Before changing anything, work out which problem you actually have. They all show up as "the keyboard types the wrong thing", and only one of them is the platform mode.

The first row is the subject of this post. The third has nothing to do with layouts at all. The middle row is covered in its own section below.

What Fn+O and Fn+P actually change

Logitech's support article on multi-device, multi-OS keyboards documents the two combinations: Fn+O "swaps PC layout to Mac layout" and Fn+P "swaps Mac layout to PC layout". You hold the keys until the LED on the current Easy-Switch channel lights again, which is the keyboard's confirmation.

Those combinations are not handled by macOS or Windows. They write a value inside the keyboard, and the keyboard then sends different key codes for the same physical keys. That is why the legends on an MX Keys carry both names, opt with start and cmd with alt: which one is live depends on the mode, not on the computer.

The same value can be written over USB, using Logitech's HID++ 2.0 protocol. The feature is 0x4531, named MULTIPLATFORM. One caveat belongs here: Logitech does not publish a specification for it. Its public cpg-docs repository holds exactly one HID++ 2.0 feature page, 0x0000-IRoot.rst. What is known about 0x4531 comes from two other places:

• Solaar, the Linux device manager, which defines MULTIPLATFORM = 0x4531 and exposes it as a setting labelled "Set OS".
• Frames captured from real hardware, an MX Keys S on a Logi Bolt receiver, written up in the Layout Auto Switcher protocol notes.

A patch posted to the Linux kernel mailing list proposes support for the same feature, and describes it as letting a device "select a platform profile that determines how the device firmware behaves for a specific operating system".

The write itself

In the captured frames, function 3 of the feature, setHostPlatform(hostIndex, platformIndex), sets the mode, and function 2 reads it back. A host index of 0xFF means "whichever Easy-Switch host is active now". Switching an MX Keys S to its Windows platform looks like this, with 0x10 being the index that keyboard assigned to the feature:

→  11 05 10 3E FF 00                     setHostPlatform(current, 0)
←  11 05 10 3E ...                       ack
 
→  11 05 10 2E FF                        read back
←  11 05 10 2E 00 01 00 03 00 ...        platform 0, source 3

The platform numbers are not fixed across models. The keyboard publishes its own table. On the MX Keys S, platform 0 covers Android, Linux and Windows, platform 1 is macOS, 2 is iOS and 3 is ChromeOS. Older keyboards that predate 0x4531, such as some Craft and K-series models, expose 0x4530 DUALPLATFORM instead, with two buckets: iOS and macOS, or Android and Windows.

Measured on that MX Keys S, the switch takes effect in 326 ms. The keyboard then re-publishes its HID descriptors, so any program that had it open must reconnect.

Why a KVM breaks it

Read the platform for each Easy-Switch host separately and the state turns out to be per channel, not global. From the same MX Keys S:

This is the part that matters. Per-channel storage works when each computer has a channel of its own: channel 1 for the Mac, channel 2 for the PC, each remembering its own mode. A KVM undoes that. The receiver plugs into the KVM, the KVM moves it from one computer to the other, and the keyboard never notices. It is still talking to the same receiver on the same channel, so it keeps the same platform value.

Press the KVM button and the PC receives a keyboard that is still in macOS mode. Nothing in the chain is broken. The keyboard is doing what it was told, by the last computer that told it anything.

Why Logi Options+ doesn't catch it

Options+ does drive this feature, and it has a setting, "Always keep the keyboard in Mac layout", that reads as if it should prevent exactly this. Measured on macOS with Options+ 2.6.941708 and that setting switched on, the protocol notes record:

So Options+ corrects the platform once, when its agent starts, and not when the value changes. A KVM switch starts nothing. The other computer's Options+ has been running for hours, so it stays quiet and the keyboard keeps the mode the previous machine left it in. On a Windows machine with a different Options+ build, the notes record it reverting a change within half a second. That timing was not reproduced on macOS, so treat Options+ behaviour as version-dependent.

Your options

Give each computer its own channel

If you can live without the KVM for the keyboard, this is the cleanest fix, and it needs no software. Pair the receiver to one computer and connect the other over Bluetooth on a second channel, then switch with the keyboard's Easy-Switch keys. Each channel keeps its own platform. It is the answer that came up repeatedly in a ComputerBase forum thread from someone sharing an MX Keys between a PC and a MacBook through a KVM, where a poster running the receiver-plus-Bluetooth arrangement reported no problems with swapped letters. The cost is that the keyboard no longer follows the KVM button.

Hold the combination after every switch

Fn+O when you land on the Mac, Fn+P when you land on the PC. It works on every keyboard that supports it, and it is what everything else in this post automates. It is also the fallback if any tool gets it wrong.

Solaar, on Linux

If one of the machines runs Linux, Solaar can set the same value from its "Set OS" setting. It is a Linux program, so it covers that machine only.

An agent that reacts to the switch

The gap in all of the above is timing: something has to write the platform at the moment the keyboard arrives on a machine.

From the studio: That is what Layout Auto Switcher does. It is a small MIT-licensed agent for Windows and macOS that listens for the operating system's device-arrival notification and writes the same setHostPlatform value Fn+O or Fn+P would.

It does not remap keys, and it does not modify the firmware. Install it on both machines, each asserts only its own platform, and no administrator rights are needed.

irm https://raw.githubusercontent.com/abd3lraouf-studios/logitech-layout-auto-switcher/main/install.ps1 | iex

curl -fsSL https://raw.githubusercontent.com/abd3lraouf-studios/logitech-layout-auto-switcher/main/install.sh | bash

On macOS, opening the receiver needs Input Monitoring permission (System Settings, Privacy & Security). Without it the device is listed but will not open, which looks like a hardware fault and is not one.

Support goes by capability rather than a model list: any Logitech device that advertises 0x4531, or the older 0x4530, is driven, whether it is on a Bolt, Unifying, Nano or Lightspeed receiver or connected directly over Bluetooth or USB. It has been verified end to end on an MX Keys S through a Logi Bolt receiver behind a TESmart KVM. Other models should work by the same capability, but they have not been checked. The figures from the project README, measured on that setup:

Two cases need a word. If your KVM switches only video, or you move channels with the Easy-Switch keys, the receiver never unplugs and no arrival event fires. The agent then reacts to the keyboard announcing itself on reconnect, measured at about a second, with a re-check every 20 seconds as a backstop. And if each computer has its own receiver, there is no conflict to resolve. Each machine owns its own channel, and --claim-host N pins the agent to one.

To find out which of the three faults you have, run:

logiswitch doctor

It checks all three and names the one it finds.

Input language is a different setting

A keyboard in the right platform mode can still type Arabic letters when you wanted English. That is the computer's input source, and the keyboard has no say in it. Logitech's article on the Input Language Switch key describes that key as toggling between the input languages "active in your computer settings". The list lives on the computer.

Switch it there: ⌃Space on macOS, Alt+Shift or Win+Space on Windows. Nothing in this post, including the platform write, touches it. If the letters are right but ⌘ and Alt are swapped, it is the platform. If the letters themselves are from another alphabet, it is the input source.

Summary

• The wrong keys after a KVM switch come from the keyboard's firmware platform mode, not from macOS or Windows.
• The mode is stored per Easy-Switch channel, and a KVM moves one receiver on one channel between computers, so the keyboard keeps the last value.
• Fn+O and Fn+P write that value by hand. The HID++ feature behind them, 0x4531, has no public Logitech specification. What is known comes from Solaar and from captured frames.
• Options+ 2.6.941708 on macOS writes it once, at start-up, which a KVM switch never triggers.
• Separate channels fix it without software. An agent that reacts to the keyboard arriving fixes it while keeping the KVM.

Logitech Layout Auto Switcher is that agent: free, MIT-licensed, for Windows and macOS. Install it on both machines, and logiswitch doctor names which of the three faults you have.