mouse/keyboard becomes unresponsive on USB KVM switch

[No0ne]

At the moment, the behaviour is:

1. If I want it to work, I have to set the KVM switch to make the input devices visible before I power on the PS/2 side. (It was always like this)
2. If I KVM switch away and back after it's started, the Logitech G203 Prodigy stops responding but the keyboard comes back fine.
3. If I KVM switch away and back again, there's at least a chance (I only tried it once) that I'll also lose the keyboard.

In any of those failure modes, un-plugging and re-plugging the USB side doesn't fix things and never has.

EDIT: Maybe I should look up which pin is RESET and solder on an alternative to the reset pushbutton buried under the level shifter.

Originally posted by @ssokolow in https://github.com/No0ne/ps2x2pico/issues/35#issuecomment-2067650032

[ssokolow]

I mentioned several comments later that further testing seems to indicate that the actual behaviour is simply "If I press a key or move the mouse before the USB device's initialization sequence completes, the ps2x2pico will ignore that USB device until I power-cycle the ps2x2pico, even if I disconnect and reconnect the USB device" and the three cases listed above were simply due to moving the mouse or pressing a key prematurely.

That is, all three listed cases appear to just be symptoms of the same "Oops. I touched the keyboard/mouse too soon and now the ps2x2pico's handling of that type of input device is broken until I power cycle the ps2x2pico".

[No0ne]

Please post a diagram which devices are connected how, thanks!

[ssokolow]

Here you go. The KVM switch is one of those ultra-simple $10 USB/VGA KVM switches off eBay where the USB side is just a "device sharing hub" (i.e. a USB hub with a pushbutton that unplugs the host-side cable from one of its physical inputs and plugs it into the other)

[No0ne]

Ah I always thought this was a PS/2 KVM switch :D so debugging the PS/2 side won't do much here. This seems to be an issue with the TinyUSB library used by the Pico-SDK. Just checked in the Pico-SDK the library isn't updated yet and we are still on the same version as in ps2x2pico-1.0.

Please record the serial output of GPIO0 while switching the KVM and/or pressing keys too early. Currently I only have debugging messages for mount/unmount USB devices, I can add more if I don't have a clue after your posting.

[ssokolow]

As I suspected, I think there's some kind of race condition involved, because it took several tries before I managed to get it to happen.

(On a related note, do you know if a Pico's GPIO pins would go through any potentially problematic states (eg. ones that would be hazardous to the connected motherboard's PS/2 power fuse) if I were to wire up a Reset pushbutton between RUN and GND and use that instead of holding down the PC's power button for 5 seconds to recover from "neither keyboard nor mouse is responding"?)

Under normal operating conditions, this is what I get from KVM-switching to and then away from it:

HID device address = 1, instance = 0 is mounted
HID Interface Protocol = Keyboard
HID device address = 1, instance = 1 is mounted
HID Interface Protocol = Mouse
HID device address = 2, instance = 0 is mounted
HID Interface Protocol = Mouse
HID device address = 2, instance = 1 is mounted
HID device address = 1, instance = 0 is unmounted
HID device address = 1, instance = 1 is unmounted
HID device address = 2, instance = 0 is unmounted
HID device address = 2, instance = 1 is unmounted

When I managed to get the mouse to fail to come up, switching to it and then away looked like this:

HID device address = 1, instance = 0 is mounted
HID Interface Protocol = Keyboard
HID device address = 1, instance = 1 is mounted
HID Interface Protocol = Mouse
HID device address = 1, instance = 0 is unmounted
HID device address = 1, instance = 1 is unmounted

I then decided to double-check, so I quit and then restarted the terminal to clear it so I couldn't get confused about where the cut line was, and then got this from the next switch to and from which also didn't work (exact same hardware and procedure):

ps2x2pico-1.0
HID device address = 1, instance = 0 is mounted
HID Interface Protocol = Keyboard
HID device address = 1, instance = 0 is unmounted
HID device address = 1, instance = 1 is unmounted

...but, this time, a third attempt brought it back to normal function and GPIO0 output:

HID device address = 1, instance = 0 is mounted
HID Interface Protocol = Keyboard
HID device address = 1, instance = 1 is mounted
HID Interface Protocol = Mouse
HID device address = 2, instance = 0 is mounted
HID Interface Protocol = Mouse
HID device address = 2, instance = 1 is mounted
HID device address = 1, instance = 0 is unmounted
HID device address = 1, instance = 1 is unmounted
HID device address = 2, instance = 0 is unmounted
HID device address = 2, instance = 1 is unmounted

I'll try for just the keyboard now.

[ssokolow]

It occurs to me that I'll also need to test with the Gateway mouse to make sure what I captured wasn't how the ps2x2pico sees the kind of firmware crash that Logitech mouse is capable of when being KVM switched on one of my slightly smarter KVM switches that speaks enough USB HID to watch whether the scroll lock LED has been blinked as a "switch inputs" signal.

(Not that I'd expect it to be. When that happens, it's more "the mouse comes up fine but then becomes unresponsive after maybe 30 seconds".)

[ssokolow]

OK, it looks like the keyboard depends on something I'm consistently doing in the non-problem-causing way when I try for a regimented test routine.

It's about time for me to go to bed, but I'll leave GPIO0 hooked up and just use the thing for a few days and see what the log says when I stumble over it again.

[ssokolow]

I wound up getting side-tracked and delayed, and, as a side-effect, managed to capture the something that will hopefully be of use.

When it stops responding for both keyboard and mouse, it re-displays the "blank line, ps2x2pico-1.0, blank line header and then stops outputting stuff on GPIO0.

EDIT: Never mind. The "then stops outputting" part was because the cheapo test clip slipped off. The header being redisplayed did happen though. In fact, it happened on more than one occasion.

[No0ne]

Ok thats definitely a TinyUSB issue. I don't know how to upgrade to the latest version within the Pico-SDK, maybe this would fix it.

The initialization message only appears after a powercycle or a panic (triggered by TinyUSB).

You can always wire a reset button to RUN/GND. Electrically this does nothing to the PS/2 lines as they can only be shorted to GND or not (aka pulled high).

[bstrobel]

For me the adapter works perfectly when I connect a keyboard directly to the USB port or when I use a passive USB 2.0 Hub and connect mouse and keyboard. So far so good.

I also have a 4x1 4K HDMI/USB 3.0 KVM Switch (China brand, bought from Amazon). When I connect the adapter to this switch no keyboard or mouse input is registered by the PS/2 PC. No matter what I try. But the adapter is not dead. The PS/2 PC recognizes a keyboard (but no mouse) when booting. It prints the infamous "Keyboard not found. Press \<F1> to continue" message if there is no keyboard connected.

I attached a serial terminal to GPIO0 and all I get is a line with "ps2x2pico-1.0" and nothing else. Looks like the adapter hangs. (Just to clarify, I get a lot of debug messages when I connect the passive hub and everything is working.)

So this sounds like another or the same TinyUSB issue. What do you think? Is there any hope that this can be fixed in the near future? Because the KVM switch is what I need to connect it to.

Just to let you know, I'm happy to help you debug and fix this issue.

[No0ne]

Yes sounds like the same TinyUSB issue, I'll check if I can update this in Pico-SDK.

[bstrobel]

I checked out tinyusb from github and configured the project to use it (master branch). There is definitely progress but it doesn't really solve all the problems.

Now I get debug messages when switching back and forth and after some switching the keyboard suddenly works. But not the mouse. The mouse is an old Logitech M705, so nothing fancy btw.

[bstrobel]

The pico sdk and cmake are new to me. So maybe I let you know what I did.

• Moved pico-sdk/lib/tinyusb to some other place
• Cloned git@github.com:hathach/tinyusb.git in pico-sdk/lib
• Edited ps2x2pico.c to #include "bsp/rp2040/board.h" instead of #include "bsp/board.h"

Sounds sound to me but maybe I'm missing something like specific configurations for the Pico or so.

[bstrobel]

And more news. The mouse is not working in Norton Commander but it is working in Windows 98 on the same PC (a Socket 7 PC with an Intel 430VX chipset and a VIA VT82C42N keyboard controller btw, in case you want to know). And it was working in NC when connected using a passive hub. Not sure what happens here but I will investigate more.

Once it is working on my KVM switch it keeps working not matter how often I switch back and forth. So to me it seems we are 80% there and I'm quite happy with the progress. I will call it a makers day for now but will investigate more in the next days.

[No0ne]

Thanks for the effort! Can you please provide the uf2 for @ssokolow to test with his KVM switch, I don't have the time right now to compile it, thanks!

[bstrobel]

@ssokolow Here it is: ps2x2pico.zip

[ssokolow]

Thanks. A bunch of things came up over the last couple of days, so it may take me a couple more before I can reasonably justify testing it.

(On Saturday, I broke my Win98SE install and then discovered that my copy of PowerQuest Drive Image 2.0 would hang mid-way through restoring it. This morning, I woke up to find the KVM switch being non-responsive. etc.)

On the plus side, if the KVM switch has gone bad, I at least know it shouldn't have been the cause of this, since I never experienced this behaviour with the other PC connected to it, and I do have a 4-input unit of the same type I can replace it with (It's a 2-input unit.) ...and I believe i tested with the keyboard directly connected at least once.

(And, Re: #37, the corrupted Windows 98 SE shouldn't be a problem since I shouldn't need to be able to boot all the way into it to test Ctrl+Alt+Delete with F12 held down.)

...I just can't reasonably justify putting testing this at the top of the priority list for another day or two.

EDIT: Worst case, I plug in the original PS/2 keyboard long enough to change the BIOS boot order and then get out my USB DVD Rewriter and boot Damn Small Linux to do testing, or expedite getting it added to the netboot menu and boot it that way.

[ssokolow]

Sorry for going silent. I'm still here, I just had a bunch of stuff blindside me. (Mostly spring cleaning/home maintenance stuff I'd forgotten I set reminders for, but also a bit of other things like losing today (Saturday) to a terrible night's sleep.)

I'll get to this as soon as I can spare the time to diagnose/replace the cheap Chinese KVM switch and re-verify the problem behaviour with whatever I boot the t5530 into before flashing the new firmware.

[No0ne]

No stress, this is after all a voluntary freetime project. I'm also currently out of time to work on it, to be continued

[No0ne]

please retry this issue with the latest fix from here: https://github.com/No0ne/ps2x2pico/issues/37#issuecomment-2119247095 it is also built with the latest tinyusb 0.16.0 release

[ssokolow]

please retry this issue with the latest fix from here: #37 (comment) it is also built with the latest tinyusb 0.16.0 release

This will take a little longer than my response in that one, because I haven't reinstalled the Win98SE install I messed up on the t5530 yet, but I'll try to make time to get that done over the course of the next few days (my kingdom for better driver slipstreaming) and use the ps2x2pico to drive the process. The KVM-switching back and forth between it and whatever I'm doing on my main system should serve as a good test.

[ssokolow]

OK, I've already managed to induce the mouse to become non-responsive, so it looks like it's not solved.

[ssokolow]

I think it might actually be worse now. I'm finding the Logitech mouse non-responsive after a KVM switch away and back, even when I do wait for the "I've initialized" LED animation to finish.

(I haven't tested with other mice yet and it is technically a different KVM switch, given the old one died, so it's possible it wasn't the firmware verison change that did it. I was just doing some netbooting to re-partitioning the drive using my PartitionMagic boot disk .)

[ssokolow]

Speaking of which, if you want to test it locally like you did with the t5530, this is the $15 CAD USB/VGA KVM switch I'm currently using and the one I was using before was the 2-port version.

There's a ton of them on eBay, Aliexpress, Amazon Marketplace, and anywhere else Chinese drop-shippers congregate.

[ssokolow]

I just noticed something that may be relevant. The first time I move the mouse after netbooting into Damn Small Linux 4.4.10 with the ps2x2pico and the t5530-fix.zip firmware , it thinks I pressed the right mouse button at the instant the first motion is received.

It also seems to be pretty consistent that every following time I KVM back to it with that firmware, the mouse no longer responds.

It's getting late, but I'll try to do some tests tomorrow to see if I can narrow in on what conditions cause that effect. (eg. try a different mouse, try a native PS/2 mouse and a USB mouse plugged in direct as control samples, etc.)

[ssokolow]

Interesting. The mouse refusing to come back after a KVM switch away and back, even if I wait before touching it, is specific to Damn Small Linux. Windows 98 SE appears to be behaving better, in that, so far, I haven't managed to get either input device to become unresponsive due to over-eager use of them after hitting the switch button.

[No0ne]

Thanks for testing, did you also observe the serial debug output? I also ordered the same KVM switch for testing, to be continued.

[ssokolow]

I haven't hooked the serial up yet, because I didn't want to be doing too many things at once and I was a bit excited about the progress I was making to identify the ideal driver versions and configurations to solve some blue-screen issues on Windows 98SE. (2.5 down, 0.5 to go... as in there's a simple fix for the third but I need to figure out how to keep it from breaking something else.)

I'm not sure if I'll get to it tomorrow, given that I have some other "within the next few days" things I have to give a timeslice to, but I'll let you know as soon as I do.

[ssokolow]

Huh. There's an interesting behaviour. If WinAMP is playing music on Windows 98SE and I KVM switch away, audio playback freezes for a split second. I wonder what the ps2x2pico is sending over the PS/2 ports when it experiences a USB disconnect.

EDIT: ...and apparently when Windows puts the monitor to sleep, and again when the monitor's non-disable-able "auto-switch inputs upon loss of signal" switches the input, but not when I hot-plug a USB input device.

Given that this desk's VGA/USB KVM is only acting as a switchable USB hub feeding into my DVI/USB KVM switch and not actually switching the VGA signal, that suggests that the hitch is some kind of thing Windows 98SE does whenever some kind of driver state reconfiguration occurs in something not originally designed with hot-plug in mind.

[ssokolow]

Oh, one other tip for the t5530. There are a few DOs and DON'T for avoiding Windows 98SE blue screens so, if you decide to use it for that now that you've got one, read this conversation I had with another t5530 owner where we identified which driver versions or BIOS settings can cause blue-screening.

[No0ne]

I'm still waiting for the KVM switch to arrive, its already in shipping.

[ssokolow]

No worries. It's been a busy time for me anyway.

I've also ordered parts for more ps2x2picos and received a few more thin clients (an HP t5710, a Wyse Cx0, and an IGEL-3/2) so, once the last pending parts arrive (more USB C to B cables to plug YD-RP2040s into KVM switches without worrying about whether any OTG adapters I source will grip the plugs firmly), I'll build some more ps2x2picos (and take a photo of the less drastic way to bridge those contacts on the YD-RP2040) and try one out with them and also with my AST Adventure! 210 and my Lenovo 3000 J Series.

(Yeah, my Cx0 and Lenovo 3000 J Series run Windows XP, but they have PS/2 ports and I seem to remember the latter's BIOS either not supporting entering the setup via USB keyboard or not wanting to do so when the keyboard is connected through a USB hub such as the one in these KVM switches.)

Speaking of the Cx0, I've proven to my satisfaction that, if a thin client lacks drivers for anything older than Windows XP, it's still possible, with the help of the Inexperience Patcher, to approximate Windows 98SE's look and feel closely enough for it to not feel "uncanny valley".

[No0ne]

I've received the KVM switch and can confirm its a TinyUSB library issue, to be continued...