Level1 KVM: Linux guest's keyboard and mouse randomly stop working

I hope this is the right spot for a question like this, if not, please feel free to move it somewhere else.

I have the 4-port dual-display DP 1.2 KVM from Level1 (PAAG-E3124A).

First of all, I am very happy with it, great device. But, apparently, a Linux VM I run, isn’t.

I have three ports in use on the KVM:

  1. host, it uses a USB-port that is separate from the VMs port’s IOMMU groups
  2. Linux guest with passed thru GPU, USB-C passed thru from GPU
  3. Windows guest with passed thru GPU and USB from host (the only controller in it’s own IOMMU group)

Keyboard and mouse are connected via the HID ports, the rear USB 3 connects the monitors USB hub.

The host and guests all run fine, aside from one little problem with the Linux guest:

Its mouse and/or keyboard randomly, but frequent, stop working, like they freeze. If I use a model with some sort of LED lighting it will stay on, so power is there. Fun fact: I can communicate with the KVM → ctrl-ctrl-number works for switching to a different console. And mouse and keyboard will work just beautifully on the other ports.

However, switching back and forth will not unfreeze the Linux guests mouse or keyboard. This can only be achieved by unplugging it from the KVM and plugging it in again while KVM is set to the guests port.

I tried various things, like different kernels for the guest, disabling usb-autosuspend, even acpi. I tried connecting the mouse/keyboard to the USB 3 ports in the KVM(can’t switch there but still freezes). Makes no difference.

udevadm monitor does not see the “event”, as any other log doesn’t. As far as the guest is concerned, nothing happens. It seems as if KVM and the USB controller just don’t speak any more → but only for mouse and keyboard, a conference speaker or webcam connected via the KVM simultaneously work just fine and keep working even if keyboard/mouse don’t. So there is communication between the connected devices and the USB controller, and it does work.

Now, someone suggested it could be related to mouse-emulation(?) on the KVM, and here lies my question:

Is this the case? How can I switch it off or on? How can go about further debugging this issue?
And, does anybody have a PDF from the manual for the KVM? I can’t find the printed one that was included :-/

Sorry for the long winded text, but I tried to describe it as best as possible.

1 Like

I’m experiencing an somewhat related issue with my keyboard when using HID passthrough, where it stops sending key events to my windows guest but can still control KVM with ctrl+ctrl. However, it does recover after swapping back and forth.

I have to physically unplug an plug in the keyboard and/or mouse to make it work again. Switching consoles does not resurrect it - though the other consoles work fine.

Windows as a guest somewhat handles it better, still freezes from time to time, but manages to recover on its own after a few seconds. So that’s better, but not great either.

I have to stress that this only happens with the USB port from the GPU, host USB and passed through controllers from the mobo do not have this problem.

It seems to be almost gone - didn‘t show up today at all - after switching Windows from the game-ready to the creator-driver.

So I assume ist has to do with the driver? So xhci on Linux? I am no programmer and have no clue how to debug this. Maybe someone can point out some things to try?

Interesting. I had some trouble like this with logitech stuff early on. Once the driver loads if goes to a 20 byte usb protocol.

If ctrl ctrl still works it means the software on the computer side messed with the hid-ness of the key board.

So try uninstalling drivers for the keyboard or switch to basic drivers


Make sure all pcs have same drivers/version .

Usb3 ports can be used which bypasses any messing with the peripherals the KVm might do at a possible cost of not hotkey switching.

Hmm there are no drivers for the keyboard, it’s a very basic mechanical keyboard which doesn’t need any drivers - Sharkoon prurewriter RGB (that is controlled by hotkeys, only). The mouse a Roccat Kone Aimo, which, once setup in Windows, retains its settings on-device, very cool.

I don’t think the KVM is at fault here, since USB 3 ports behave exactly the same. But still, it would be interesting to know what the cause for that is.

The whole thing also only happens with the USB-C port on the GPU, so I ordered a 1-slot WX5100 (main reason for the model: it was available) and a PCIe 1x USB card to try if that solves it. That would squeeze in instead of the 2-slot card.

I have only ever seen similar symptoms one time from a sketch usb a to b cable. got any usb debugging tools or logging going on to see l? If the keyboard works to the KVm but not pc that could also fit

No I don’t have any debugging tools or logging - that’s a little out of my wheelhouse. But, I did buy a bunch of brand new cables (Cable Matters Part. No. 201007-BLK-2m-EU) before putting this all togehter - and I swapped them around already. Same story.

1 Like

have you tried only the keyboard? I saw another case once where a webcam was causing the port on the computer to crash. Moving usb ports on the host computer fixed that one, though, and it sounded like you already tried that. Still, I’ve seen some bad engineering on usb web cams… so…?

As a matter of fact, I have. The only two other devices on USB are a Logitech C920 webcam and a Logitech P710e conference speaker.

They webcam and speaker connect through the USB hub of an Alienware AW3420DW to the the USB 3 port on the back of the KVM. But I did also try it out with just the mouse and keyboard on the HID ports (as well as USB3).

Moving USB ports on the host is kinda tricky, since the mobos sole USB controller within its own IOMMU group is assigned to the Windows VM. That’s kinda the reason I put the 2080 in there, because it provided that additional USB controller for the Linux VM.

I’ll know more, maybe Wednesday, when the new parts arrive.

1 Like

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