Switching keyboard AND mouse (as a pair) between computers using only the three Easy-Switch multi-device F-keys

[imfatant]

Just as I was going to pen my own lengthy question about this topic on Stack Exchange's Superuser site (albeit that particular question and its answer implies the use of of strictly official Logitech software), I spotted that someone had already asked the question very succinctly there:

Question and (single) answer on Superuser (dated 2022/2023): https://superuser.com/questions/1703762/sync-logitech-keyboard-and-mouse-connection-when-i-switch-devices

Official answer direct from Logitech: https://support.logi.com/hc/en-us/articles/1500008089162-Can-I-switch-my-mouse-and-keyboard-at-the-same-time-using-one-Easy-Switch-button

So my question here is - perhaps can Solaar help me do this? Or is there a clever workaround? And please note I'm not really talking about the official mouse-based so-called Flow feature here; I'm talking about using the three white Easy-Switch multi-device F-keys on my Logitech K780 keyboard.

This issue has been plaguing me for days, so all information and advice would be GREATLY appreciated.

I should mention that I'd ideally like to be switching between two Raspberry Pi 5 boxes running various flavours of Linux and my main Intel-based Windows 10 desktop computer (each, naturally, equipped with its own Unifying Receiver) which no doubt complicates matters further...

-- Imf

[pfps]

This is indeed possible as long as you can divert the keys. You divert the keys and write Solaar rules that switch the keyboard and mouse. You have to be running something on the other machine to switch back and maybe the Logitech software has an incompatible solution. I've never tried with Windows as one of the targets, but I have done this between two Linux boxes. I haven't had a setup where I wanted to do this for a while so the rules might not be the best for the current version of Solaar.

Here are two versions of the rules that I have used. The keyboard is a Craft, which has three separate switching keys. It is important to trigger the rules on key release.

- Key: [Host Switch Channel 2, released]
- Rule:
  - Active: 198E3EB8
  - Set: [43DAF041, change-host, 1]
  - Set: [198E3EB8, change-host, 1]
  - Execute: [notify-send, Switched keyboard and mouse to idefix]
- Execute: [notify-send, Mouse not active]
- Set: [43DAF041, change-host, 1]
- Execute: [notify-send, Switched keyboard to idefix. Mouse not active, it will have
      to be switched manually]
...
---
- Key: [Host Switch Channel 3, released]
- Set: [43DAF041, change-host, 2]
- Set: [198E3EB8, change-host, 2]
- Execute: [notify-send, Switched to other]
...

[pfps]

It is also possible to implement a Flow-like solution if your system has something like active corners. Just create a shell script that uses the Solaar CLI to switch the keyboard and mouse and trigger it from the active corner.

This might integrate better with a Windows machine in the works as it does not require diverting any keys.

[pfps]

It should have been easy for Logitech to do something like what the rules do. I don't understand why they didn't, except maybe that they really like the Flow solution.

[rloutrel]

I did something similar: 1 Ubuntu, 1 Fedora and 1 windows.

Linux

The solution with the rule editor, visually:
Spoiler: the configuration here is broken, because I have a new Keyboard and I did not update it my rules yet. But I should have to replace 'MX Keys' by 'MX KEYS B', and I should double the mice actions (I have several mice).

Windows

I used bat/vbs scripts (I do not remember, and I do not use it anymore), triggered by a key that I bound in the logitech software. Unfortunately, it did not work for the 3 Host Switch button, so I used the "lock" key, but... I always switch back to one of the linux. You would have to pick a second one.

The vbs was an extra layer between the bind and the bat because I could not trigger the bat directly. Do not ask my why, I forgot...

With the script, I triggered https://github.com/todbot/hidapitester .
File: Switch_to_1.bat

rem source https://github.com/marcelhoffs/input-switcher
rem --send-output A,B,C,D,E,F,G
rem 
rem A = always 0x10, although Solaar seems to use 0x11.
rem B = This is the number of the device that is linked to the Unifying receiver: 0x01 for the first device (the keyboard), 0x02 for the second device (the mouse). 0x00 Is supposed to be the Bluetooth device, but I haven't tested that.
rem C = ? => 0x09 for the keyboard, 0x0a for the mouse
rem D = ? => 0x1e for the keyboard, 0x1b for the mouse
rem E = This is the channel to switch to: 0x00 for channel 1, 0x01 for channel 2 (and I guess 0x02 for channel 3)
rem F = always 0x00.
rem G = always 0x00

rem Switch MX Anywhere 3 to channel 1
.\hidapitester.exe --vidpid 046D:C52B --usage 0x0001 --usagePage 0xFF00 --open --length 7 --send-output 0x10,0x01,0x0A,0x1B,0x00,0x00,0x00

rem Switch MX Keys to channel 1
.\hidapitester.exe --vidpid 046D:C52B --usage 0x0001 --usagePage 0xFF00 --open --length 7 --send-output 0x10,0x02,0x09,0x1E,0x00,0x00,0x00

[imfatant]

First, wow, thanks guys! That is so helpful.

I still have a few little questions, one of which is regarding the 42-logitech-unify-permissions.rules files (of which there are two very slightly different versions depending on whether one is using X11 or Wayland). If I understand the Solaar documentation correctly:

One places the X11 version in /etc/udev/rules.d
OR
One places the Wayland version in /etc/udev/rules.d-uinput

Two queries arise out of this:

1. Can one install them BOTH on the same system (let's say out of pure laziness), or will this cause conflict?
2. I tried out installing Solaar on one of my Pi 5s (which happens to be running the latest official Raspi OS Bookworm Debian image) using the direct and simple sudo apt install solaar method. However, I can't find where it put either of these files. Is this because this step of the installation MUST be done manually regardless, or for another reason?

[pfps]

You only need one udev rule and it should almost certainly go in /etc/udev/rules.d
The Wayland rule has everything that the X11 rule has plus ability to write to uinput. You only need this extra if you are running Wayland and it is a bit of a security risk.

Packages for Solaar should also put the udev rule in the correct place. If this package doesn't you should talk to whoever created the package.