search

WootingKb / wootility-issues

A place to report issues with the Wootility and help with feedback on existing issues
25 stars 3 forks source link

Keyboards do not work in HID port #293

Open MR-Assister opened 3 months ago

MR-Assister commented 3 months ago

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.

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

If it helps here is a thread on level1 techs:

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

MR-Assister commented 2 months ago

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 commented 2 months ago
jckail commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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:

Power Consumption:

Interface Complexity:

Endpoint Configuration:

Device Classes and Protocols:

MR-Assister commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

Level1Techs KVM Expectations

Why Other Keyboards Work

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 commented 1 month ago

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 wendell@level1techs.com? 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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

jckail commented 3 weeks ago

Curious if anyone has found anything out in the last month. I tried again with the lastest Wootility v5
and firmware v2.10.0-alpha.12

still no luck

Rocky04 commented 3 weeks ago

Nothing new about that yet...

There is dev firmware which reordered the keyboard interface and may can help. You can try it out via this link: https://v5.wootility.io/?test-builds=true, the name is v2.10.0-test.itf.restructure.

johnd31415 commented 2 weeks ago

Not exactly related, but I was having similar issues with a TESmart KVM and the test firmware from the forum thread linked above (v2.10.0-test.kvm) solved it for me

Rocky04 commented 2 weeks ago

@johnd31415 Only when the gamepad feature is disabled or does it also work when the Xbox or classic controller is used?

jckail commented 1 week ago

I'll give it a shot!

jckail commented 1 week ago

This worked for me! Steps to reproduce: https://v5.wootility.io/?test_builds=true Ensured NKRO & gamepad were disabled. move from HID interface to USB interface, run update to "kvm build" ... update firmware ... move back to HID Then it worked!!!! Tested with ctrl + ctrl 1,2,3 etc...

I know this is preRelease but thank you everyone who did this!

Screenshot 2024-11-10 at 3 10 47 PM

LETS GO!!!!

jckail commented 1 week ago

Let me know if I can test any other builds out to get this shipped!

Rocky04 commented 1 week ago

The NKRO state should not matter, only the gamepad need to be disabled. Sadly the Wootility don't work reliably.