4

I'm using a KVM-switch like setup to share my keyboard and mouse between a Windows machine and a Linux machine.

I have a Logitech Mouse and Corsair (K95-RGB) Keyboard (ironically both devices made and optimized for windows with only windows-side official driver support...) and the problem is that when I switch the devices from Windows (or offline) to Linux, Linux picks up that the devices are plugged in and activates them immediately, I can use the devices within 1 second no matter how recently I last switched or which state the devices were in previously.

When I switch from Linux (or offline) to Windows, Windows can take an awful amount of time to first detect the devices, and another awful lot of time to actually enable them...

According to my Windows clock (I counted), roughly 38 seconds for device detection (powering on), and another 17 seconds (update: on a re-test later on I found the mouse activating in ~15s and keyboard 5 secs later, or in ~20s) for device activation (e.g. for the driver to kick in properly, so from the time I switch to windows I waited 55 seconds before I could use the devices) this time was the same for both my Keyboard and Mouse despite using separate driver software and being completely different devices.

So what takes Linux effectively around 1 second to do, windows takes up to 1 minute to do, usually in the range of 40-60 seconds based on my experience over roughly half a month.

To further clarify things. The first 35-40 seconds that Windows takes to power on/detect the devices only happens if the devices were recently disconnected. Basically what is happening is that when I disconnect the devices (switch away from Windows) windows takes 35-40 seconds to acknowledge that the devices have been disconnected (making the device disconnected sound). If I switch back to windows after this point, the devices are detected/powered on immediately, but still take a good 15-20 seconds to be usable (for the drivers to work).

Question #1 is whether I can somehow hasten the driver enablement for the devices after they have been detected and powered on? (Maybe somehow prevent the drivers from being unloaded completely in the first place? Or offload them to a RAMDisk for faster load? Something else?)

Question #2. Can I somehow reduce the time(out?) before Windows disconnects the devices after they have been unplugged (switched to another computer)? I'd prefer this to be as close to instant as possible.

Extra Info:

My setup is as follows (from computer to devices)

  1. USB 2.0 Port
  2. USB 1.X USB Switch
  3. USB 2.0, 4 Port Manhattan Powered USB Hub
    1. Corsair K95-RGB Keyboard (uses 2 USB Ports, one for extra power)
    2. Logitech G402 Hyperion Fury Mouse
    3. Wacom CTH-680 Tablet.

Tests:

I tested the same switch/hub setup on Linux and in the UEFI BIOS, none of the issues on Windows were observed (except that the keyboard and keyboard alone takes a few seconds to be re-detected by the ckb driver, what this means is that macro/extra keys don't work until after a few seconds on Linux for the keyboard. Otherwise everything works perfectly in <1s)

I decided to test plugging my mouse alone directly in since it's the easiest and on the first connect it exhibited a similar behavior of a roughly ~50 second wait before the mouse was usable (much of this time was again waiting for it to be detected and powered in the first place). If I repeated this test afterwards by unplugging the mouse and plugging it back in, it was instantly activated/usable, and similarly if I unplugged it then and plugged it into the already active USB hub, it was again instantly activated. But if I used the switch to turn the devices off/on it reverts to the same pattern as before. (Plug and play works best if you are not disconnecting/reconnecting an entire hub with several devices connected)

I tried switching the usb switch off of windows, waiting for Windows to disconnect the devices (~40s) and playing the device disconnect sound, at which point I switched back to windows, device detection was instant but driver load still took 15-20 seconds. (Wacom untested) mouse and keyboard become usable at the exact same time despite the keyboard driver being seemingly more complex and should probably be taking longer to load than the mouse (it's kind of like no device can work until all the devices connected to the hub have had their drivers loaded, may just be coincidence though).

I tried booting in safe mode (generic drivers only), in here the device disconnect still took ~40s but the driver activation after detection took <1s for the mouse and <5s for the keyboard (much faster than the ~17s for both; but in light of this I decided to re-test the activation time after detection for both devices after booting out of safe mode, and true enough, this time the keyboard took around 5 seconds longer than the mouse to load the drivers (mouse ~15s, keyboard ~20s).

I ran another test after uninstalling the Corsair Utility Engine (keyboard drivers) the keyboard did not initialize any faster (still took ~20s). After a restart, the keyboard would activate almost as fast as it did in safe mode. I then re-installed the Corsair Utility Engine and tried again, and with the corsair drivers active it was fast again. I rebooted, and things went back to the way they were before. I uninstalled the corsair utility engine again, and despite it being uninstalled, the keyboard does not initialize fast anymore. Further testing lead me to conclude that I can uninstall the corsair specific keyboard drivers and use the generic ones instead (with the corsair utility engine still running and activating the leds) and this gives me enough speed boost so that driver enablement takes 5s (mouse) and ~10s (keyboard), however this solution is not an option for me since it means my keyboard would not function correctly.

Improve this question
25
  • If you plug them directly into the PC, into the same ports the KVM is plugged into, does this behavior still exhibit itself?
    – Ramhound
    Commented Apr 13, 2016 at 17:23
  • @Ramhound I should probably clarify my setup, I have a USB (1.0) switch which I connected to a USB (2.0, 4 port, powered) hub which my devices (USB 2.0) are connected to. I decided to test plugging my mouse alone directly in since it's the easiest (keyboard uses 2 ports) and it exhibited a similar behavior of a roughly 40 second wait before the mouse was usable. I wouldn't be surprised if the duration this is taking windows is partly because it may be trying to first detect and activate the USB Hub before it goes on activating the HIDs I've got plugged into it (extending the time by like 20s)
    – Cestarian
    Commented Apr 13, 2016 at 17:30
  • Your keyboard uses 2 USB ports? Once you did this initial test, did you repeat the test, Windows is suppose to create a catalog of USB devices based on the port.
    – Ramhound
    Commented Apr 13, 2016 at 17:33
  • @Ramhound yes, I have a Corsair K95-RGB keyboard, it needs one port for power, one port for HID, the plugs are interchangeable (e.g. either one can act as input and power or just power based on the order in which they are plugged in) I did not repeat the test, but let me do so now... Yes, I plugged the mouse (this time into another port) and it was activated almost instantly this time (<2s). Funny thing, afterwards I plug it back into the hub, and it is again activated almost instantly, we might be on to a solution... Or on the right path anyways.
    – Cestarian
    Commented Apr 13, 2016 at 17:40
  • 3
    I suspect the problem is the Switch itself not the keyboard and mouse. The delay is to be expected, but it sounds like, the switch is behaving like an entirely new device each time you switch between the connected PCs Alternative is very the problem with just the mouse, I suspect the keyboard, is causing the problems with relation to mouse taking 60 seconds to internalize.
    – Ramhound
    Commented Apr 13, 2016 at 17:47

3 Answers 3

Reset to default
0

Summary of the above comments :

  • The problematic devices are namely the mouse and the keyboard.
  • Deleting their drivers and resorting to the Windows generic drivers has much improved the switch time.
  • The remaining problem is that the keyboard generic driver cannot handle special keys, for which I have counseled the use of SharpKeys and/or AutoHotkey to map them to useful functions.
  • Keep an eye on the Corsair downloads page for newer updates
  • Trying to get in touch with Corsair’s Customer Service may (or may not) help.
Improve this answer
6
  • Well, you're forgetting one part of the question. Reducing (or removing) the timeout between device physical disconnects and the time windows registers the disconnect.
    – Cestarian
    Commented Apr 18, 2016 at 23:33
  • also I (very) highly doubt that sharpkeys or autohotkey can be used to map G keys. Normally on keyboards like these, the G keys either do not register keystrokes at all, or register a pre-determined keystroke (like F1-F12) but not unique ones. They can't substitute for a real driver, the driver needs to stand the hardware code given from each individual keypress, and generic drivers do not understand "G1-G18" or "MR, M1, M2 and M3". They would if the manufacturer mapped them to different keys (like say F13-F24..) but they generally don't do this.
    – Cestarian
    Commented Apr 18, 2016 at 23:45
  • Switching lag-time: To reduce you need to change the KVM. There exists a technology called DDM (Dynamic Device Mapping) which is supposed to reduce the lag, but they are usually costly (example). I have no experience with it and don't know how well it works.
    – harrymc
    Commented Apr 19, 2016 at 6:47
  • Keys mapping : That depends on the keyboard. The usual case is for the keyboard to generate a scan-code that is interpreted by the third-party driver. I don't know your keyboard, but I believe it would require the cooperation of Microsoft to integrate so deeply into Windows as to totally handle the keyboard. A scan-code is much simpler to handle in software.
    – harrymc
    Commented Apr 19, 2016 at 6:55
  • It's a driver problem - I believe that Linux drivers are more generic . A more evolved KVM will fake the continuing presence of the devices so there is zero lag. I can delete this answer if you don't see it as helpful.
    – harrymc
    Commented Apr 19, 2016 at 11:32
0

There are reports of a reduced reconnect time if you shut off the Allow computer to turn off this device to save power under Device Manager - Properties - Power of the two USB devices.

It's worth a try, but Windows just likes to take its sweet time.

Improve this answer
2
  • I already tried this, the only devices where I could toggle this option was for the USB Hubs, not the devices themselves. It seemed to have no effect. I'm trying it again to confirm, but not expecting much. (I turned it off for all usb hubs) Update: Yeah, no effect whatsoever.
    – Cestarian
    Commented Apr 21, 2016 at 19:46
  • As the devices don't sleep, but rather disappear, this setting should not apply.
    – harrymc
    Commented Apr 22, 2016 at 5:45
0

I've just found out that Windows 10 does not have this issue, it typically switches over instantly for me. My issue was mostly in relation to Windows 7 though so this is not a complete answer but I guess I'll just have to use Windows 10 for a while until I can dump Windows completely... just one more driver that needs fixing...

But yeah there's that. If you're on Windows 7 and facing the same issue, know that downgrading to Windows 10 could potentially solve it.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .