Keyboards do not work in HID port

[MR-Assister]

Describe the bug
When using KVMs from Level1techs (https://www.store.level1techs.com/products/p/4-port-km-switch-with-usb-32-gen-1-mouse-roaming-function) with HID ports for hotkey control of the KVM, the Wooting One and Wooting 60HE do not work in the HID port and only work in usb3.0 ports.

To Reproduce
Steps to reproduce the behavior:

1. Plug in Keyboard to HID port. No lights appear.

• OS: Windows 11

Wootility and Firmware version
2.7.2
2.8.1
2.9.1-beta.0

Keyboard Type
Wooting one or 60HE + English

Things already tested.

1. Disabled NKRO
2. Multiple firmware versions
3. Different USB cables.
4. Swapping between analog and digital mode on the Wooting One.
5. Multiple other keyboards work fine, This appears to be an issue with the Wooting firmware.

[jckail]

any fixes or resolutions here?

i'd be happy to help if pointed in the right direction.

I'm suspecting its a power delivery issue in that the wooting needs more juice than the KVM can provide.

[MR-Assister]

any fixes or resolutions here?

i'd be happy to help if pointed in the right direction.

I'm suspecting its a power delivery issue in that the wooting needs more juice than the KVM can provide.

I highly doubt it is a power issue since the KM is powered and I've tested a handful of mechanical, backlit keyboards, from other brands and no other keyboard has this problem.

If there is anything else you can think for me to test, let me know and I'll give it a try.

[BigBrainAFK]

We have found some KVMs that dont like something in our firmware. As far as I am aware we are working on a fix but I would expect this to drop with firmware at or after the 80HE release.

[jckail]

Here to help however I can, I am relatively tech savy.
I would LOVE to be able to pickup an 80HE but can't because of my KM.

This is my KM from level 1 techs

I have the gen2 60HE that doesn't work at all with the HID ports (but works with USB3) then I have a keychron q1 he that works fine with the KM via HID Ports (except the software can't sync over HID)

[jckail]

If it helps here is a thread on level1 techs:

https://forum.level1techs.com/t/wooting-60he-and-hid-ports/210911

[MR-Assister]

If it helps here is a thread on level1 techs:

https://forum.level1techs.com/t/wooting-60he-and-hid-ports/210911

I've already posted on that thread. I would also purchase an 80he if we could get this issue resolved. But there may only be 3 of us with the same configuration.

I don't know enough about keyboard firmware to troubleshoot any further on my own and was hoping the wooting staff could give us something to test.

[Rocky04]

• The Wootings aren't QMK compatible.
• Previously the Wootings used two separated keyboard interfaces. When NKRO was enabled the boot keyboard interface was crippled, that maybe causes issues for some devices who parse the HID report descriptor.
• On the most recent firmware (on Wootility V5) both keyboard interfaces got merged. This implementation should be 100% HID compliant. If the host changes the protocol mode to boot (default is report structure) the Wootings should use that well defined structure and otherwise they will use the structure defined in the HID report, as specified by USB IF.
• To my knowledge Wooting tried to trade products but didn't got a reply yet. So possible that Wooting currently don't have a Level1Tech product in order to troubleshoot and vice versa.

[jckail]

Thanks for the follow up @Rocky04 & @MR-Assister!

Previously the Wootings used two separated keyboard interfaces. When NKRO was enabled the boot keyboard interface was crippled, that maybe causes issues for some devices who parse the HID report descriptor.

-- This makes sense and maybe explains why it works w/ USB3 and not HID?

On the most recent firmware (on Wootility V5) both keyboard interfaces got merged. This implementation should be 100% HID compliant. If the host changes the protocol mode to boot (default is report structure) the Wootings should use that well defined structure and otherwise they will use the structure defined in the HID report, as specified by USB IF.

-- Is there a way to get access to an early release candidate of V5? Can't find any docs or request forms. I'm on v4.7.2-beta now w/ firmware v2.9.1 on my 60HE.

[Rocky04]

@jckail Wootility V5 got public a few days ago.

Edit:
I assume the Level1Tech products ignore additional keyboard interfaces. That they only look out for a boot keyboard compatible interface and expect that the structure there is always constant and matches the boot report. But this is not the case. Only when the host sets the protocol mode to boot via a special request you can expect the well defined structure, otherwise the HID report structure must be parsed.

[jckail]

Damn you're too fast i just found it after a few more google searches.!

Thanks for the help, flashing that update from v5 now and giving it a test run!

[jckail]

Edit: I assume the Level1Tech products ignore additional keyboard interfaces. That they only look out for a boot keyboard interface and expect that the structure there is always constant. But this is not the case, only when the host sets the protocol to boot you can expect the well defined structure, otherwise the HID report structure must be parsed.

I share your assumption, would also explain why QMK works well when wooting and other "proprietary" software like logitech etc doesn't. I know NKRO's config impacts how its registered with the upstream host(s).

Fingers crossed the lights at least turn on with the latest update :)

[MR-Assister]

Damn you're too fast i just found it after a few more google searches.!

Thanks for the help, flashing that update from v5 now and giving it a test run!

I tried v5 on my keyboard and still no lights or anything.
I did notice that if I disconnect all other keyboards from the kvm and remove power from the kvm, then connect the wooting keyboard to hid, when I connect my other keyboards to hid they do not work until I disconnect everything again. So it seems like the wooting is at least taking over some control of the hid link.

[Rocky04]

KVMs are typically not smart enough to parse a HID report descriptor. So for the Wootings a KVM should change the protocol mode to boot so it can easily read the data in a well optimized way. But then there is likely the problem how to pass through the keyboard to the host. This likely causes issues because the host is not aware that the KVM has changed the mode. Meaning the KVM should act as a man in the middle and not allow to transparently pass the device to the host. At least for the keyboard interface to no break anything else. So it would be very complex...

I guess for a KVM it would be better to have two keyboard interface where the first is the boot interface and where the report matches the boot structure. Then to send any additional keys which can't fit in the first other the second.

[jckail]

Yup @MR-Assister can confirm, I tried everything (also using the including Wooting USB cable) got the same result.

I wonder if there is a way to "spoof" the boot report being set to the KVM when ever the wooting is plugged in OR the KVM boots.

[jckail]

Python Script to Compare Keyboards

With a little help from ChatGPT, I quickly turned around a Python script to compare two keyboards:
(Note: You'll need to brew install lsusb)

Script:

usbsniffer python script

Results:

results

ChatGPT's Interpretation of the Results:

Functionality:

• Wooting 60HE (ARM): Appears to be a more feature-rich keyboard with multiple interfaces and endpoints, possibly supporting analog input, advanced lighting effects, and other proprietary features.
• Keychron Q1 HE: Focuses on providing standard keyboard functionality with some customization, indicated by the large HID descriptor on Interface 0.

Power Consumption:

• Wooting 60HE (ARM): Consumes more power (400 mA vs. 100 mA), likely due to additional features like per-key RGB lighting and analog key switches.

Interface Complexity:

• Wooting 60HE (ARM): Has a more complex interface structure with five interfaces.
• Keychron Q1 HE: Has two interfaces.

Endpoint Configuration:

• Wooting 60HE (ARM): Uses various endpoints with different packet sizes and intervals, indicating diverse data transmission needs.
• Keychron Q1 HE: Uses fewer endpoints with consistent configurations.

Device Classes and Protocols:

• Both devices implement the standard HID class for keyboards but differ in how they structure additional functionalities.
  """

[MR-Assister]

I really think the best way to get this resolved is to get wooting's USB firmware guy in touch with Wendell from lvl1techs.

[Rocky04]

If the KVM is expecting the well defined boot structure it should change the protocol mode to boot. At least it needs to check the current protocol mode. If the protocol mode is not boot it must parse the HID report descriptor to know the HID report structure.

A system (like a legacy BIOS or UEFI BIOS) which doesn't support to parse a HID report either directly sets the protocol mode to boot or it checks the current mode and changes it to boot in the case it's set to the report protocol mode (which is the default). Just assuming that a HID interface which is specified with the boot interface sub class sends data in the boot structure is not correct and so not HID compliant.

See "F.5 Keyboard: Using the Keyboard Boot Protocol" in "Device Class Definition for Human Interface Devices (HID)" version 1.11

[Rocky04]

I really think the best way to get this resolved is to get wooting's USB firmware guy in touch with Wendell from lvl1techs.

As mentioned I'm aware that Wooting tried to contact Wendell without success. So I know this would be very appreciated.

[jckail]

I really think the best way to get this resolved is to get wooting's USB firmware guy in touch with Wendell from lvl1techs.

Completely agree. Hopefully we can get them flagged down.

See "F.5 Keyboard: Using the Keyboard Boot Protocol" in "Device Class Definition for Human Interface Devices (HID)" version 1.11

Thanks for this I read a bit of it then it clicked:

Wooting Keyboard's HID Descriptor

• bInterfaceSubClass: 0 (No Subclass)
• bInterfaceProtocol: 0 (No Protocol)
• Implication: Does not declare itself as a boot device, requiring the host to parse its HID Report descriptor.

Level1Techs KVM Expectations

• Assumes Boot Protocol Support: Expects connected keyboards to declare the Boot Interface Subclass and Keyboard protocol.
• Limited Parsing Capability: Likely does not parse HID Report descriptors due to complexity and hardware limitations.
• Result: Cannot recognize or communicate with keyboards that do not support the boot protocol.

Why Other Keyboards Work

• Keychron and Ducky One:
• bInterfaceSubClass: 1 (Boot Interface Subclass)
• bInterfaceProtocol: 1 (Keyboard)
• Compatibility: These keyboards are recognized by the KVM because they support the boot protocol.

I'll try to flag down Wooting Support and L1Techs. I think both companies really care about their products and making sure they are the best and most compatible.

[MR-Assister]

I really think the best way to get this resolved is to get wooting's USB firmware guy in touch with Wendell from lvl1techs.

As mentioned I'm aware that Wooting tried to contact Wendell without success. So I know this would be very appreciated.

Have they tried [email protected]? He's a busy guy so it might take a few days but I know he really cares about his products and has a deep understanding of how this kvm works.

[Rocky04]

I know they have this e-mail but I don't know if they used the form or this e-mail to try to get in touch with him.

@jckail
I don't like AI generated stuff because it often isn't 100% correct. So no, the first keyboard interface always had and still has the boot interface sub class while the interface protocol is specified as keyboard. So this interface can be easily found without the need to parse the HID report. Before Wooting used a second keyboard interface without the boot interface sub class for their gaming keyboard interface while the first was but was crippled down in the HID report structure in a way that the OS don't use it. This wasn't fully HID compliant and Linux even showed a warning about that in the kernel log. On the most recent firmware (alpha 8 on Wootility v5) the two keyboard interfaces are merged. Meaning the report looks like the previous gaming interface and the interface itself is specified as a boot interface. So normally the keyboard will send the report structure of the gaming interface over the endpoint but if the host changes the protocol mode to boot the keyboard will instead use the boot structure. This should be HID compliant, at least how I understood the specification.

Edit:
The problem is that not a lot are aware of the protocol mode. So far I only saw one keyboard which was doing it in a similar way as Wooting does it in the new firmware.

[jckail]

I don't like AI generated stuff because it often isn't 100% correct.

Story of my life haha, I'm way out of my area of expertise WRT hardware specs and protocols so i'm crutching on it :) appreciate your help and patience helping with all this. I am learning a lot of fun stuff today.

Meaning the report looks like the previous gaming interface and the interface itself is specified as a boot interface.

Interesting! Makes sense too, my friends have reported that sometimes on their windows machine it will think its a game pad.

Would it be possible to send a signal from the upstream host to the KVM to override and/or reboot with a working signal?

Side note: I know it was mentioned earlier but I would also love to fully understand or debunk my thoughts around the keyboard not getting enough power. The 4x requirement of the wooting over the keychron seems significant. I needed a reason for a new USB meter anyways so i'll test out how much juice the KVM is outputting from the USB HID port.

[Rocky04]

A host expect that the HID interface is in the report mode because that should be the default. A host would not expect that a device in-between, like a KVM, would change that. I don't know how the Level1Tech KVMs work and can only assume. I would need one and some time to tinker around with that.

Of-topic...
The Wooting can emulate a Xbox 360 controller (XInput on Win) or a classic controller (DInput on Win). So yes, if either one of these two modes is used the Wooting would appear as a gamepad controller on the system in addition. On default that features is disabled because a lot users had issues because the Wooting typically got the first Xbox slot resulting that other Xbox controller didn't work in game because games often assign the controller slot to the player slot. Meaning games often only accept the input of the controller which in the slot 1. Some games automatically activate split screen and a second player if a controller in slot 2 is detected.

[jckail]

I don't know how the Level1Tech KVMs work and can only assume. I would need one and some time to tinker around with that.

I couldn't recommend them more whole heartedly. I've tried quite a few others and they all had noticeable latency or just have inconsistent functionality. Wendell has a few different videos on them not to mention L1T isn't a giant mega corp so its nice supporting folks who care enough to solve problems. --- All being said thats apart from the issue with the wooting KBs 😄

Meaning games often only accept the input of the controller which in the slot 1.

Steam has spoiled me with how well it manages this over windows these days. Wish there was a "steam input" for keyboards like a wootility haha.

[jckail]

Wooting and Wendell look to be in touch over on the L1T Forums