KVM Hotkeys Not Working With UHK80 #1143
Comments
|
The UHK 60 and UHK 80 use different USB firmware stacks, and the USB descriptors/reports probably differ somewhat, which is why you experienced a difference. Tailoring the descriptors to make them work with most KVM switches can be very time-consuming. I think it's a better strategy to implement 6KRO instead. @benedekkupper Feel free to provide more insight. |
|
Well we do have the 6KRO fallback option in place on UHK80 ( |
|
|
This fallback isn't done on the UHK60 yet. |
|
How much work is it? |
|
Here is an UHK80 firmware that uses 6KRO: https://github.com/UltimateHackingKeyboard/firmware/actions/runs/13520273276/artifacts/2648024398 |
|
Flashed that firmware on my UHK80 and it did not help with the KVM hotkeys for me. I'm not entirely surprised as the UHK60v1 has firmware that has NKRO and it works with the KVM. So I don't think the problem is something else about how USB is registered. I spent some time over the weekend trying to get the firmware building locally and was having some weird problems (not going to bring them up here because it's probably just me). But once I work that out I'll poke around more and see what I can figure out. If you have any suggestions I'm open to the suggestions. |
|
@benedekkupper What can be the culprit? The implementation of the descriptors? |
|
First of all I didn't link to the thread I made on the Level1Techs (manufacturer of the KVM) forum about this issue: I did some further research today. It seems that Wooting has also had problems with their keyboards working with the Level1Techs KVM (though it seems that their keyboards wouldn't work at all and the UHK80 does work, just the hotkeys are not recognized). You can see the Wooting thread here: In the Wooting thread they mentioned that they had too many "interfaces/endpoints" for the KVM to handle and they ended up providing an option to disable gamepad support to fix the problem. I don't think they've managed to fix using their tool/update process over the HID ports on the KVM yet though. I've noticed I find the agent really slow when using the HID ports on the KVM and updates do not work (actually bricked my UHK60v1 doing this and had to do the reset to fix it). Maybe those are some helpful pointers. If you have any suggestions on how to perhaps debug HID compatibility on USB keyboards I'd be happy to look into this further myself. |
|
For what it's worth I don't really care if the agent or the update process works over the HID ports. It's not a big deal to me to have to plug it in directly to a computer for that. I rarely use the agent or update the firmware. So fixing that IMHO is not in the scope of what I'm trying to get fixed here. |
|
Well if the simple key pressing works, then it's not a descriptors issue, but rather something with the hotkeys sending logic, where I cannot be of much help. |
|
Indeed, I failed to catch this detail! @kareltucek If you have time, please look into the report sending logic of #1148. |
|
@mondalaci / @breser if you think this is a report logic issue, then please elaborate on how the scancodes sent by uhk80 differ from those sent by uhk60. (Or maybe I don't understand what kvm hotkeys are? I assume they are normal key combos that the kvm intercepts and interprets as is own controls.) |
|
@kareltucek Your assumption is correct. I don't have anything else to add. |
|
@breser Have you tried increasing the Keystroke delay on the UHK? |
|
So I'm not so sure it's not a USB registration issue because from my understanding is the KVM will just pass through devices that don't register themselves properly as keyboards and just ignore the data for them. Devices it recognizes as USB HID keyboards it will listen for the events looking for the hotkeys. So if the UHK80 doesn't identify itself in a way the KVM recognizes as a keyboard then it could still work with the host while the KVM hotkeys are not registered. The KVM hotkeys are documented here (note only the KVM ones apply, the KM ones are for something different than what I have): But the general idea is that you double tap a leading key followed by some keys to issue a command. The leading keys can be Left-Control, Right-Control, Scroll Lock or Num-Lock, but Left-Control and Scroll Lock are enabled by default. For example you could double tap Left-Control and then 1 to switch to the first computer and double tap Left-Control and then 2 to switch to the second computer. Using KeyCodes on the Mac I see the following for the double tap Left-Control and then 1 with the UHK80: Modifier Change Modifier Change Modifier Change Key Down Key Up I see the same from the UHK 60, except that when it's plugged into the HID port on the KVM the Mac does not see the Key Down or Key Up modifiers for the 1 key since it appears that the KVM consumes it and doesn't pass it along. Both keyboards have the Keystroke delay set at the default of 0ms. But I've tried every 5 ms all the way up to 50ms on the UHK80 with no difference in behavior. The UHK60v1 works at 0ms or 50ms just fine (didn't bother to try everything between since it didn't seem useful given that it works at the extremes). In the Wooting thread you can see Wendel say that the keyboard needs to be HID 1.1 compliant and ask if the keyboard is using PHY or bit-banging as apparently bit-banging keyboard implementations don't work. I wonder if he doesn't mean HID 1.11 compliant since I see 1.11 is the common referenced HID specification. It's possible the Key Codes app I was using on the Mac is not low level enough to see any potential difference. I'll try to find some more time to get out a Linux machine to put behind this KVM setup and see if I can run xev on it and see if there are any differences there. I'll also try to figure out how to sniff the USB registration of both devices to look for a difference while I'm at it. Happy to investigate anything else that you can suggest. |
No need to. If I understand correctly, you are using simple key actions for both left control as well as the numbers (i.e., not secondary roles, not macros, not actions that combine modifier with a scancode). If that is the case, It might be worth to check that left control is really left control and not right. Apart from that I would rule out the high level logic. Have you checked the number of exposed interfaces? I think that gamepad should be disabled by default, but haven't checked. |
|
Correct I've been trying to use just manual key strokes to do the hotkey. I'm using a very slightly modified keymaps based on he QWERTY Mac and PC keymaps. Both of them have the LCtrl as the Modifier for the bottom left key which is labeled Ctrl. I had to add ScrLk binding back to the Mac version of the keybinding since it isn't turned on there and it has the Scancode selected as Scroll Lock. Neither key has any other secondary roles or anything else going on with it. How do I go about checking the number of exposed interfaces? I know I saw some GamePad stuff looking around the firmware but I don't see anything in the Agent about it. I do have a Key cluster module and all the navigation modes are set to Scroll, Caret or Cursor. Also worth mentioning that the KVM doesn't recognize the key strokes even when the Key Cluster is not installed on the UHK80. I didn't try the UHK60v1 with the Key Cluster. But I don't think it's really relevant, I'm not using any of the keys for this and it doesn't seem to make a difference with it on or off. |
|
Modules are not relevant. As for interfaces, I guess this should be a good starter: https://chatgpt.com/share/67bf6765-09a8-8005-8d91-3b0e66dd7678 |
|
No output from the All the TS4 stuff is the Thunderbolt 4 dock that the computer is attached to. USB-C to DP Cable is self explanatory. Razer thing is my mouse. Most of the HUBs and crap are from the Thunderbolt4 dock. Virtual HUB the hub on the KVM for the HID ports, Virtual HID is related to the KVM HID support. And the Apple stuff is just the built in busses for each USB-C port on the Mac. system_profiler command again doesn't have anything with the word keyboard in it but here's the output which is really just more detail about individual devices on the USB busses: And this is the output of Not sure that really answers your question about interfaces but it seems that there are 4 "services" according to hidutil for the UHK80. Now all those same things but with the UHK60v1 connected: UHK60v1 shows up as 1 more device and the same number of services. Note I did plug the KVM USB directly into the laptop rather than through the Thunderbolt 4 dock. That doesn't change anything with respect to the KVM hotkeys working or not, UHK80 still does not and UHK60v1 still does. |
I don't know if this is helpful at all, but I just wanted to mention the UHK80 does indeed install gamepad components in Windows. The UHK80 auto-installs an "Xbox 360 Wireless Receiver for Windows" for each half, as well as the dongle. 
I was having weird shutdown/restart hangs on Win 11 a while back, and I discovered it was caused by the UHK80's "Xbox 360 Wireless Receiver for Windows". The hang issue has since been resolved, but while troubleshooting the issue I saw this: #770 (comment) So I assumed a stray registry entry from the UHK60 was causing the "Xbox 360 Wireless Receiver for Windows" to be erroneously auto-installed with the UHK80, but it also gets installed when connecting the UHK80 for the first time on a fresh Windows install (no prior UHK60 or Xbox devices connected). |
|
Does the gamepad thing happen with USB or just wireless? Because I'm just using USB? |
The "Xbox 360 Wireless Receiver for Windows" is added when connecting either half to the PC via USB, and/or when the dongle is connected to the same PC via USB. It doesn't get installed when I connect the UHK80 to the same PC via BLE using an ASUS USB-BT500 adapter. The left half, right half, and dongle all have independent instances of the "Xbox 360 Wireless Receiver for Windows". 
|
|
Okay yeah I do see that too on Windows. I only see the right half because I don't have the left half connected via USB and am using the coiled cable between the halves. Using the USB Device Tree viewer v4.4.4 on Windows I see that the UHK80 has 7 endpoints as opposed to the 6 for the UHK60v1. I also see that the UHK60v1 is reporting it's compliant with HID version 1.10 and UHK80 is showing as HID version 1.11. I also see that when listing out the HID Descriptors for both keyboards that the UHK80 shows: While the UHK60v1 shows all the details for each descriptor. Despite he message I don't see anything in the Help that explains that message. So really not sure what the issue is. I can post the full details from the tool but I think it's basically the same for everyone so not sure if it would really be valuable. So I guess my best guesses at this point are the extra endpoint for the gamepad support is causing problems, UHK80 has some difference due to the HID version 1.10 vs 1.11 that's causing the problem, or there some sort of problem with the descriptors which also means that the USB Device Tree Viewer on windows can't even read them properly? I think my suggestion for what to try next would be to try a firmware with the gamepad disabled. Not sure how hard that is. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a UHK60v1 and a UHK80. Both of them are on the (at this time) current firmware of 12.3.3.
I also have a Level1Techs DP 1.4 KVM:
https://www.store.level1techs.com/products/p/14-kvm-switch-dual-monitor-2computer-z5erd-n6mbj
With the UHK60v1 I am able to use the hotkeys the KVM supports to switch devices.
With the UHK80 I am not.
I've seen this issue from the past:
#536
But it seems that for the people that needed just 6KRO to have it work properly with their KVM that issue has not been resolved in the current firmware. However, I do not believe my problem requires 6KRO because it's working with my UHK60v1 on the current versions.
Please note that I'm using USB with both devices and both devices are plugged into the proper HID ports on the KVM that are required for this to work.
Given some of the discussion in the older issue though, I wonder if there isn't some sort of USB ordering issue that might be relevant in this case.
If there are ideas on things to try I'm happy to give them a try.
The text was updated successfully, but these errors were encountered: