Scroll issue with DP 1.2 Dual Monitor KVM and Logitech MX Master 2S mouse

I recently purchased the DP 1.2 dual monitor KVM and it’s been working great for everything except my Macbook (but that’s a separate story) and, surprisingly enough, my Logitech mouse.

I have a Logitech MX Master 2S mouse that I’m using via its USB adapter. Most of its functionality works great over the KVM, except there’s this odd behavior where every time I switch machines the scroll speed gets reduced to a crawl (it kinda still scrolls, but not practically so). Turning the mouse on and off remedies the issue, but it’s somewhat annoying. As far as I can tell, this seems to occur pretty consistently regardless what the actual computer is (I’ve got a Windows machine, a Linux machine, and a Macbook, and the scroll issue occurs with all of them when I switch from one of the others). Does anyone know why something like this would happen? Is there any way to remedy it?

One last try… Anyone run into something like this? It’s got me scratching my head.

Driver version mismatch between hosts? Gotta run the same protocol on both computers or it confuses the mouse.

I have the same mouse but not the KVM, is it due to the mouses infinite scroll where it can unlock the wheel? I know it has software to adjust that for Win and Mac but not Linux.

I have no idea whynit would not work with Win and Mac properly though.

The mouse also has 3 wireless conections to cycle through one USB and 2 Bluetooth usually, could the dongle be getting confused when it switches OS, unfortunately it cand be used worked to.see if that helps and the USB port on the mouse itself is only for charging with no data.

There is actually now a utility for the mx but I forget the name :slight_smile:

And recent kernels have the better protocol implemented

1 Like

You mean the solaar utility for unify devices?
Or is there a specific one for the MX?

@wendell Ok, so I experimented a bit more, and it seems like this only occurs if I have the mouse’s wireless received connected to a one of the HID ports. If I connect to one of the USB3 ports, everything works perfectly, so I suspect it’s probably not a driver issue.

Unfortunately, there are only 2 USB3 ports on the KVM as far as I can tell, and I have a webcam and some headphones that I’ve got connected. The webcam and headphones don’t seem to work at all through the HID ports, which I suppose is expected?

I also tried getting a few other mice to test out (a Razer Basilisk X and a Logitech M705), and to my surprise, they don’t work at all when connected to an HID port, whereas the Logitech MX Master at least mostly functions.

Are the HID ports not appropriate for mouse usage?

The logitech mx master works fine on the hid ports. That’s the one I use myself. However, I am not using the mx master software on any of the connected ports.

You can try touble-tappiing numlock to try a bus reset. If that fixes it, it is yet more evidence to confirm its a software issue.

Without realizing it your diagnostics confirm it’s a software issue because the usb3 ports don’t try to mess with the device; they just reset and reconnect it whereas hid is a kind of passthrough where the device never really gets a reset. The logitech mx is by default using an 8 byte protocol but with the software uses a 20 byte protocol. Both protocols are understood by the kvm but if one host uses one protocol and the other uses the other, it leads to exactly what you’ve observed.

Try the numlock thing. Otherwise an externally powered USB3 hub would give you a bit more usb3 connectivity.

As for other devices not working on hid, double check device manager. the usb2 hub is a hub connected to usb3 root port, which sometimes doesn’t enumerate upstream. This might show up in device manager.

1 Like

Triple-tapping numlock doesn’t appear to do anything, unfortunately.

Not sure what I should be looking for in device manager, but I should also mention that they weren’t working for both Linux and Windows machines that I have connected.

I meant the numlock thing with the MX connected. It won’t help with the other mice because they’re farther away from normal hid than the MX

Yes, to clarify, I tried the numlock thing with the MX, not the other mice.

you may have to un/replug the receiver on each machine in turn – start with machine 1 then do the numlock thing, then try machine 2 with the numlock and switch back to machine 1. If the kvm thinks the device has been misbehaving, you may need to powercycle the kvm as well. Mostly these states are a result of user action, not anything the kvm is doing wrong…

The last time I went through it about a month ago, if you loaded the mx drivers in windows, with the logitech bloatware, and used something like this: GitHub - PixlOne/logiops: An unofficial userspace driver for HID++ Logitech devices (I think but not sure solar might also support enabling the advanced mode) so that both machines are using the same protocol with the receiver, then switching between machines was still working and pretty smooth.

I was somewhat disturbed on a new machine that windows 10 seemed to auto install something to harass me to install the logitech bloatware, so there may be a factor like that in play.

Failing that, an externally powered usb hub from a reputable brand like anker would probably also fix you up.

also double check your receiver firmware is up to date. there have been some dud versions here and there.

I see, thanks for the input. I tried the in-turn numlock thing with both machines, and no dice. Just to be clear, I don’t think I’ve installed any MX specific drivers beyond what comes default with the OSes, but I suppose something funky could’ve happened. And regarding logiops, I had actually tried tried setting it up earlier on my Linux machine in the hopes that it’d correct any driver issues, but it didn’t help.

I tried connecting a small hub, and thankfully it seems to work well so far. Out of curiosity, what’s the rationale behind having ~4 HID ports and only 2 USB3 ports? My understanding is that it’s useful for KVM-specific hotkeys, but it seems like you’d only need 1-2 for a keyboard (and… maybe something else?), whereas normal USB ports seem like they’d be more useful for most other peripherals? But I’m probably missing something.

usually the hid ports do work for other low speed devices.

Every now and again on the motherboard the host port is itself not a root port but part of a hub built into the motherboard. double check usb resource allocation by looking at the tree of devices to confirm. that might be why some devices (other than the mx) are not working on hid ports. ymmv on hid ports, for sure. make sure the hub is powered externally or you run the risk of a hub drawing over current and eventually taking out the usb ports on the kvm. a lot of cheap usb hubs don’t manage the current properly and permit overcurrent situations

We had done so many tests with many KVM switches for sharing Unifying Receiver HID devices (keyboard or mouse). It’s confirmed only the USB DDM class KVM switches can fully support Logitech Unifying Device sharing and taking the advantage of using just single Unifying Receiver dongle to pair up to 6 HID devices. So for USB DDM class KVM switch, you only need to plug in one Unifying Receiver dongle to one of the USB DDM ports.

Level1tech’s KVM switch lines are not USB DDM class KVM switches.

Not so fast. It works fine on the l1 KVm without ddm, too. The root problem is that the unifying receiver can speak both an 8 or 20 byte protocol.

If you use a KVm like an aten it prevents the host computers from seeing that it is a Logitech and the drivers never load. Always 8 bytes protocol.

Then"native" mode of the unifying receiver uses a 20 byte protocol. You can explicitly support this protocol and manage it via ddm and protocol juggling or lock the device to the simpler protocol.

L1 KVm on USb3 ports takes the dumb approach and just toggles the port off and on so it resets the receiver. Or any other USB device connected.

So I wouldn’t say it can’t work, it does, lots of people here use the unifying receiver without issue. It just works different than it would with true aten style ddm

FWIW, I’m experiencing the same exact problem with my MX Ergo. Google brought me here. Found any fixes yet?

I also have an MX 575, and don’t recall experiencing the issue with that device - or if I had, I just didn’t notice.

Yes the fix is use a usb3 port as described above?

This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.