Device change button does not affect other connected devices

[metrailer]

When using the device switch button on the MX Keys the MX Master 3 does not also switch devices or vice versa. Providing this option allows better swapping between devices.

[davidschreiber]

Agreed, this feature would be great. Needing to lift the MX Masters 2s is a tedious process.

[bfoster27]

Also agree! I hate picking up my mouse and pushing the button every time I want to switch.

One sort-of workaround is using "Flow" to switch devices, but my experience is it still has a lot of bugs. I use the "ctrl+screen edge" option so I don't switch devices on accident by moving the mouse too far. Sometimes it will switch anyway when my mouse moves to the edge of the screen (seems to be an issue mostly when computer(s) is/are waking up). Other times it will only switch one device - mouse or keyboard - but not both. I'd say it works the way it should (move mouse to edge of screen while pressing "ctrl" key, switch mouse and keyboard to other device) about 60% of the time, which is why I usually just hit the "1", "2", or "3" button (using 3 computers) on the keyboard and would prefer to be able to just hit this key to switch my keyboard and mouse!!

[davidschreiber]

The sad truth is, that it's just a neglected driver for the MX Masters 2s and the Craft keyboard. The fact that Flow allows switching of both devices to a different computer (and indeed it does this as one would expect) shows that it is possible, and that syncing mouse and keyboard switching is just not implemented in the computer's driver.

[bfoster27]

Right. All of the functionality is already there - it just needs to be utilized in the user interface. I can't imagine it would be too difficult to have a checkbox or something in the "Options" software to switch both mouse and keyboard when the 1, 2, or 3 toggle buttons are used to switch devices.

Any idea if this is a custom option that could be implemented fairly easily?

[davidschreiber]

I have been doing some raw command line sniffing of the USB commands sent by the Logitech software to the unifying receiver, and could switch both Craft keyboard and MX Masters 2S mouse (which are connected using the same unifying receiver) to any other channel(1, 2, or 3).

For sniffing I used busdog: https://github.com/djpnewton/busdog
For sending raw USB commands I used USB-HID-Tool: https://github.com/OpenAcousticDevices/USB-HID-Tool

I never did USB development, or protocol decoding, so my skills are fairly low on that end, but I'm still documenting what I found out so far.

The logitech driver uses simple commands to the unifying receiver, that encode the index of the device connected to the unifying receiver (in my case 1 being the keyboard, and 2 being the mouse), as well as some commands.

For example, this is one example for a command sent to the device:

0x10 0x01 0x09 0x3a 0x00 0x00 0x00

As far as I have seen, all commands start with 0x10 as the first byte. This is followed by one byte marking the device index (in case of the example 0x01). I would have expected the index to be 0-based, but in my case it was 1-based instead. I haven't checked it for other unifying receivers or computers yet, so it might be my specific setup (connected and disconnected quite often since I have the receiver).

The next 2 bytes are different for each command. I assume that these two bytes encode the actual command, and I have been able to identify at least some commands:

Channel switching

0x0810 through 0x081f cause the receiving device to switch channel (1,2,3). The command is followed by 1 byte parameter, which encodes the channel to select using a 0-based number:

10 [device index] 08 10 [channel index] 00 00 00

I haven't figured out why Logitech uses a range of commands for switching, as I could spot no difference in behavior between any of the commands.

For example, my computer sending this command, will make my keyboard (index 2) switch to the first channel:

.\usbhidtool.exe 0x046D 0xC52B 0x10 0x02 0x08 0x10 0x00 0x00 0x00

And this command switches my keyboard to the second channel instead:

.\usbhidtool.exe 0x046D 0xC52B 0x10 0x02 0x08 0x10 0x01 0x00 0x00

(The first two arguments to the tool are the VID and PID of the USB interface or endpoint, and not part of the protocol itself.)

Here's another example, switching my mouse (index 1) to the first channel (channel index 0):

.\usbhidtool.exe 0x046D 0xC52B 0x10 0x01 0x08 0x10 0x00 0x00 0x00

When Flow switches my mouse and keyboard, among other things, it sends two commands to the unifying receiver:

10 01 08 1f 01 00 00
10 02 08 1e 01 00 00

The first one switches my mouse to channel 2 (my other computer), the second command switches my keyboard.

From everything I learned today, it should indeed be possible to write a small "driver extension" that switches devices at the same time.

[davidschreiber]

Just for the sake of completeness, another command I deciphered is some kind of channel description. When sending this, the selected device will return a description of the device that is connected to the given channel:

10 02 09 3e 00 00 00

In this case, my keyboard (02) is asked to return description of channel 00 (the first byte after the 2-byte command identifier. The command identifier for this is 0x093e. In my case, the keyboard answers with this (among other stuff that follows):

Hex                                                          	Ascii	
11 02 09 3e 00 00 44 45 53 4b 54 4f 50 2d 46 53 4b 49 33 45	...>..DESKTOP-FSKI3E

That's the name of my desktop machine, which is mapped to channel 2. The first byte of the message is 11 and is always the same when any device responds to a command (seems like 10 means in and 11 means out, or such).

[TobiasAbbenseth]

Did anyone solve this issue? I do have a MX Keys and a MX Vertical and i would like to switch my devices with a single touch on the mx keys button.

[davidschreiber]

I haven't followed up on this after my initial experiments. While this is definitely just a driver issue (or at least can be easily fixed via the driver) it doesn't seem Logitech has scheduled any work on fixing this for the higher end product lineup right now.

[dnlw07]

@davidschreiber
I followed your instruction and in my case keyboard switch to second channel has following hex number:

10 02 41 04 71 61 40

unfortunately while I am trying to send the command using USB-HID-Tool:

usbhidtool 0x046D 0xC52B 0x10 0x02 0x41 0x04 0x71 0x61 0x40

I receive following errors:

ERROR: device not connected

and on my second laptop:

ERROR: incorrect response from the device

Could you please tell me what I am doing wrong?

Have you complied USB-HID-Tool using Microsoft Visual C++ Build Tools or just used pre-compiled usbhidtool.exe files downloaded from Github repository?

[vladubogdan]

@davidschreiber
I followed your instruction and in my case keyboard switch to second channel has following hex number:

10 02 41 04 71 61 40

unfortunately while I am trying to send the command using USB-HID-Tool:

usbhidtool 0x046D 0xC52B 0x10 0x02 0x41 0x04 0x71 0x61 0x40

I receive following errors:

ERROR: device not connected

and on my second laptop:

ERROR: incorrect response from the device

Could you please tell me what I am doing wrong?

Have you complied USB-HID-Tool using Microsoft Visual C++ Build Tools or just used pre-compiled usbhidtool.exe files downloaded from Github repository?

Have the same issue, on both mac and windows. Would be nice to know how to make it work. Thx!

[9000h]

Hi,
nice research but Logitech should give the community a hand and should soon add at least Linux support as they advertise it but there is nothing like options or flow.
I was under the impression there is proper support for Linux and now I found out the mx keys/craft do not really fit my needs.
CU

[Devod-co-uk]

@dnlw07 and @vladubogdan

usbhidtool 0x046D 0xC52B 0x10 0x02 0x41 0x04 0x71 0x61 0x40
The second and third part: 0x046D 0xC52B relate to your devices VID and PID.
You will need to work these out on your computer and change them.
I know it's not a full explanation of finding your VID PID:
https://interworks.com/blog/ijahanshahi/2014/07/18/identify-vid-pid-usb-device/#:~:text=Identify%20the%20PID%20VID%20of%20a%20USB%20Device&text=Under%20the%20Property%20drop%2Ddown,be%20displayed%20on%20the%20screen.

Thank you @davidschreiber

[dnlw07]

@Devod-co-uk

thanks for the tip. I have checked PID and VID and actually are the same values in my case.

I used different tool called hidapitester (instead of USB-HID-Tool proposed by @davidschreiber).
Now I am able to connect the MX keyboard and send the output, however the command does not switch the channel.

command I send:

hidapitester --vidpid 046D:C52B --open --length 7 --send-output 0x10,0x03,0x09,0x1c,0x01,0x00,0x00

output I receive:

Opening device, vid/pid: 0x046D/0xC52B
Writing output report of 7-bytes...wrote -1 bytes:
 10 03 41 04 71 8A 40
Closing device

I also wrote a python script, but also without result:

import hid
import time


# try opening a device, then perform write and read
try:
    # print("\nOpening the device:")

    h = hid.device()
    h.open(0x046D, 0xC52B) # VendorID/ProductID

    print("Manufacturer: %s" % h.get_manufacturer_string())
    print("Product: %s" % h.get_product_string())
    # print("Serial No: %s" % h.get_serial_number_string())

    # enable non-blocking mode
    h.set_nonblocking(1)

    # write some data to the device
    print("\nWrite the data")

    code = [10, 3, 41, 4, 71, 61, 40]

    h.write(code)

    # wait
    time.sleep(0.05)

    # read back the answer
    print("\nRead the data:")
    while True:
        d = h.read(64)
        # d = h.read(20)
        if d:
            print(d)
        else:
            break

    print("Closing the device")
    h.close()

except IOError as ex:
    print(ex)

Is anyone who also tried to play with that?

[altvnv]

@dnlw07 have played with it for a couple of hours. Finally got a script that switches between two devices using a Logitech Unifying adapter (I think it can be done via bluetooth connection as well).

It was done by sending the hex data I've got from Solaar change-host execution for each host-device combinations (e.g. switch keyboard from first to second device and vice versa).