jfedor2
Issues when switching computers using a KVM
Hello, I found this repo and gave it a shot. Everything has worked great, but today as I tried to change inputs in my KVM (TESmart HKS402-P23-USBK) and I have the device (singe rasperry pi pico) connected to one of the standard USB connectors (vs the ones where the KVM intercepts the HID inputs for special hotkeys that it uses), and everything works fine until I try to switch from one PC to another. The device becomes unresponsive until I remove the mouse's dongle (Kensington Expert Mouse Wireless Trackball) from the rasperry pi and put it back in.
I'm still pretty new to using custom boards with these custom boards, but it seems like there could be some sort of setting or something that could "reset" the connection from the USB dongle?
We've had similar reports (#146) in the past, I didn't get around to investigating it properly yet. My guess was that the device plugged into HID Remapper goes into suspend while the switch is happening and we fail to wake it up afterwards.
Not 100% sure what the difference is, but I tried out the two rasperry pi configuration, and that seems to be working to keep the connection while it switches
This would actually be consistent with my hypothesis. On the single Pico variant when we stop getting SOF packets from the host, we stop sending them to the device that's plugged in, which I think is causing it to go into suspend. On the dual Pico variant as long as the second Pico is powered, the device plugged into it doesn't see a difference, even if the first Pico is temporarily disconnected from its host. But I would have to look into it to confirm and come up with some solution.
You can try this test build and see if it makes a difference:
https://github.com/jfedor2/hid-remapper/actions/runs/12225991612
It would be awesone to use hid remapper as kvm being able to use a hotkey for switch target device
It would be awesone to use hid remapper as kvm being able to use a hotkey for switch target device
I have a project derived from HID Remapper that does this, but I haven't been keeping it up to date:
https://github.com/jfedor2/screen-hopper
It would be awesone to use hid remapper as kvm being able to use a hotkey for switch target device
I have a project derived from HID Remapper that does this, but I haven't been keeping it up to date:
https://github.com/jfedor2/screen-hopper
wow! this is great! sad not maintained...
in my case hotkey is more convenient because I work with 4 displays
I was thinking about any kind of daisy-chain with hid-remappers for reach this behavior
It would be awesone to use hid remapper as kvm being able to use a hotkey for switch target device
I have a project derived from HID Remapper that does this, but I haven't been keeping it up to date:
https://github.com/jfedor2/screen-hopper
Any plans to update screen-hopper and merge the improvements of hid-remapper there?
Any plans to update screen-hopper and merge the improvements of hid-remapper there?
No immediate plans but it would be nice.
@jfedor2 how about add the hability to connect boards using I2C and be able to send all events throught one of these boards. The change of the target could be triggered with a button or a hotkey.
This way HID remapper would be working just like a ~kvm~ hid switcher
Hi @jfedor2,
I am using a wireless Elecom Huge with a level1tech KM switch. I have hid remapper set up using the recommended Adafruit RP2040 running the latest u2f file and plugged in to the HID port on the KM switch. I tried both a macro and just mapping buttons separately but when pressing ctrl+ctrl+0 to switch to a second PC, the remapper freezes and stops taking inputs and then seems to reset itself and all is well again. The input does not change to the second computer though after the combination is run. If I press ctrl+ctrl via hid remapper and then 0 via a second HID compliant keyboard the input will switch successfully to the second PC (both PCs are running the latest updates on Windows 11).
Any idea what the issue could be? Is there more troubleshooting or logs I can do to provide you with more information?
As a note, something I keep coming across when researching the L1T KM switch is that it perfectly adheres to the HID standard and that most issues arise from the source device not adhering properly. Not sure if that helps at all.
Here is my config just in case:
{ "version": 17, "unmapped_passthrough_layers": [ 0, 1, 2, 3, 4, 5, 6, 7 ], "partial_scroll_timeout": 1000000, "tap_hold_threshold": 200000, "interval_override": 0, "mappings": [ { "target_usage": "0x000700e0", "source_usage": "0x00090006", "scaling": 1000, "layers": [ 0 ], "sticky": false, "tap": false, "hold": false, "source_port": 0, "target_port": 0 }, { "target_usage": "0x00070027", "source_usage": "0x00090007", "scaling": 1000, "layers": [ 0 ], "sticky": false, "tap": false, "hold": false, "source_port": 0, "target_port": 0 }, { "target_usage": "0xfff20004", "source_usage": "0x00090008", "scaling": 1000, "layers": [ 0 ], "sticky": false, "tap": false, "hold": false, "source_port": 0, "target_port": 0 } ], "macros": [ [ [ "0x000700e0", "0x000700e0", "0x0007001e" ] ], [ [ "0x000700e0", "0x000700e0", "0x0007001f" ] ], [ [ "0x000700e0", "0x000700e0", "0x00070027" ] ], [ [ "0x000700e0" ], [], [ "0x000700e0" ], [], [ "0x00070027" ] ], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [] ], "expressions": [ "", "", "", "", "", "", "", "" ], "gpio_debounce_time_ms": 5, "our_descriptor_number": 0, "ignore_auth_dev_inputs": false, "macro_entry_duration": 100, "gpio_output_mode": 0, "quirks": [], "input_labels": 0 }
Edit: As a small update, I plugged the working HID compliant keyboard into the remapper and tried the same ctrl+ctrl+0 combination. The combo does not work and I experienced the same freezing issue. This confirms that its an issue between hid remapper and the KM and not a source device issue.
@mccore
So just to be clear, you connect a keyboard to an HID Remapper that's plugged into the switch and you manually press Control, Control, 0, with no macros or anything, and it triggers the issue?
So just to be clear, you connect a keyboard to an HID Remapper that's plugged into the switch and you manually press Control, Control, 0, with no macros or anything, and it triggers the issue?
That is correct @jfedor2.
That is correct @jfedor2.
And when you connect HID Remapper and the keyboard both directly to the switch and do the switching command from the keyboard, what happens?
That is correct @jfedor2.
And when you connect HID Remapper and the keyboard both directly to the switch and do the switching command from the keyboard, what happens?
The input switches correctly which means the command worked. The HID remapper also continues to work albeit with a small delay because the USB devices are switching over to the second PC. The HID remapper does not freeze like I have been describing in this scenario.
@jfedor2 I also just made a dual pico version of this because I saw a comment in another issue that a dual pico setup might help with a KVM setup because switching hosts should only affect one of the two picos. Unfortunately, I get the same behavior as with the RP2040. Additionally, when I use the switching key combination with the dual picos the LED on both goes solid green for a second before turning off. That second is when the remapper freezes and then goes back to working.
@jfedor2 any ideas on the issue with my KVM? Anything I can do to help provide you with logs or more troubleshooting?
I don't have a theory here. If the act of switching somehow causes some weird behavior in HID Remapper, why does it matter if the switch was triggered from it or from another device? If the switch sees the switch command coming from HID Remapper, why doesn't it switch ports, regardless of what weird behavior it triggers in HID Remapper?
Hi @jfedor2,
I went searching for some more data/answers and have a possible theory. I'll admit though, this is nowhere near my area of expertise so its possible that I'm completely wrong.
I downloaded USB Device Tree Viewer to get the full device reports of both the HID remapper as well as the keyboard that works for switching between the KM host devices (aka between computers). That produced the attached full devices reports. I also took the two "HID Keyboard Device" portions from the respective "USB Input Device" sections and created this diffchecker output. The thing that stands out most to me in that output is that the keyboard that works with the KM switch hotkeys has support for the D1 power state whereas the HID remapper does not.
In the D1 power state the USB bus cannot force devices to lose context whereas in the D2 state (which the remapper uses) the USB bus can. I am not entirely sure what that context is or if it even matters.
My theory is that when HID Remapper sends the hotkey combo to the KM switch that it enters D2 state which loses context and that causes an issue whereas the generic keyboard I am using enters D1 state which does not lose context and so no issue happens with the KM switch and the hotkey combo works successfully thus switching inputs.
A second theory I had was that the port on the KM switch only supports USB 1.1 which is what the working keyboard uses whereas the HID Remapper is using USB 2.0 and falling back to USB 1.1. I don't see how that could cause an issue since USB is backwards compatible but I figured I would mention that.
Maybe all of this is completely incorrect and I look like an idiot. Hopefully the information I provided will at least help in diagnosing the issue even if I am entirely wrong.
Does any of this help?
Source for power state information.
RP2040 HID Remapper 8U9H USB Composite Device.txt Darfon USB+PS2 Keyboard USB Composite Device.txt
Edit: I plugged in a wireless keyboard/mouse combo that I have which also works with the KM switch to change inputs/computers using the hotkey. I have uploaded that device report as well. It follows the same state trend and USB 1.1 version as mentioned above. I think its valuable though because it shows that a device can be plugged in the HID port on the switch that presents as both a keyboard and a mouse and still work thus pointing to an issue with HID Remapper.
CEFLA SCRL Mini Keyboard USB Composite Device.txt
These are not USB concepts. The difference is the keyboard supports wakeup from suspend.