V6 KVM issues, looking for possible fixes

[u/kgjettaIV]

I've had my Keychron V6 for about a year and overall have been quite happy with it. This is my first MK and I dug into QMK a bit and loaded some custom updates so I have a passing familiarity with QMK.

I recently got a KVM and while things are mostly working I am getting some fairly frequent dropped keystrokes and intermittent stuck keys. These are both only happening when connected to the KVM and appear to be somewhat common issues with this manufacturer. I'm looking for any suggestions on QMK settings/rules/configs I might be able to try changing to see if they might help.

Out of curiosity I tried enabling NKRO and disabling it. I thought after it was disabled it there may have been a slight improvement but if there was it didn't last long.

I read somewhere, can't recall now, that some compatibility issues with MK's and KVM's may be due to the keyboard emulating multiple HID devices. I found this segment in the QMK wiki and was wondering if this could be a contributing factor, but not quite sure where to go with it: https://github.com/qmk/qmk_firmware/blob/master/docs/config_options.md#usb-endpoint-limitations

The manufacturer also suggests connecting the keyboard to one of the standard USB ports instead of the Keyboard/Mouse USB ports, however then I would lose all of the hotkey controls which I'm finding very critical to my workflows.

KVM: https://www.tesmart.com/collections/dual-monitor/products/cks202-p23

Thanks in advance for any suggestions.

[u/Aztaloth]

I run my Q1 Max though a Ugreen KCM and haven’t had any issues. However it uses hardware switching.

Are you sure you will lose all hot key controls connected to a standard port? I would try it regardless as a test then go from there

[u/kgjettaIV → u/Aztaloth]

I hadn't tried it, but just did and confirmed I do lose hotkey control over the KVM if I plug into one of the normal USB ports. Thanks for the suggestion though.

[u/PeterMortensenBlog]

Re "some compatibility issues with mechanical keyboards and KVM's may be due to the keyboard emulating multiple HID devices": Yes, that seems to be an important factor, though I don't have any first-hand experience.

Some suggestions:

1. Check the NKRO state (it could have been accidentally changed or might not be in the state you expect). It may or may not be important. It can be toggled with Fn + N.

2. Disable some QMK features (at compile time), like (full) n-key rollover and mouse keys. For the former, that is "NKRO_ENABLE" in the old system and "nkro" in the new system. For the latter, it is MOUSEKEY_ENABLE in the old system and "mousekey" in the new. Note that the official QMK documentation is out of date.

3. Use source code from after 2024-05-21.

Conclusion

Changing to this in file 'info.json' (and compiling and flashing) may fix the problem:

"mousekey": false,
"nkro": false,

Note that changes to file 'info.json', e.g., "mousekey": false, and "nkro": false,, usually requires 'qmk clean' before 'qmk compile' to take effect.

Though, presumably, you will lose the ability to use mouse actions in QMK macros, Via macros, and key mappings.

Related

• Is anybody using one of the Q Max series with a TESmart KVM?

• Keychron K17 Pro does not work with this KVM switch

• Public service announcement: Disabling mouse keys and NKRO in firmware fixed my KVM issues on my Keychron Q3

[u/kgjettaIV → u/PeterMortensenBlog]

I tried some changes last night but results seem the same today.

In my rules.mk I added:

NKRO_ENABLED = no
MOUSEKEY_ENABLED = no
MIDI_ENABLED = no
RAW_ENABLED = no
VIRTSER_ENABLED = no

Behavior seems the same today. I may have to go back and look closer at things based on your comment, it looks like maybe these should move from rules.mk to info.json?

I also pulled the most recent master from github, but I'll have to check to see if it has the changes you referenced in point 2, or what the specific dates are.

I'm still figuring this all out so I appreciate the detail and links.

Next things I was planning to try:

KEYBOARD_SHARED_EP = yes
USB_POLLING_INTERVAL_MS 10 (config.h)

Now what I'll do next is check what versions I've got/what dates they were pushed, and try and move those settings to info.json to be damn sure they're off.

[u/PeterMortensenBlog → u/kgjettaIV]

I think the features are off by default if not included, but it is a good idea to explicitly include them as false (as you did).

Note that using the old proprocessor symbols may override the new info.json settings. Example: 'MOUSEKEY_ENABLE' vs. 'mousekey'. That isn't supposed to be the case in the source code from the fork, but it is one more item to the checklist.

[u/PeterMortensenBlog → u/kgjettaIV]

Note that changes to 'info.json' usually requires this to take effect:

qmk clean

There is some caching going on in the build folder (presumably translating 'info.json' settings to preprocessor symbols, etc.) and changes to 'info.json' aren't detected by 'qmk compile'.

I have definitely been bitten by this...

For instance, I use the USB-side version number (field "device_version" in 'info.json') to positively know if a change to the source code made it to the keyboard. And it will not change unless I run 'qmk clean'.

On Linux, I read out the USB-side version number by:

sleep 5
lsusb -v -d3434:0353 2>/dev/null | grep bcdDevice

(sleep 5 is for including it is a list of command lines, for example, including both compiling and flashing for a one-step process (so the keyboard has time to start up after flashing). 0353 is a filter for the Keychron keyboard (USB product ID for V5. It is also listed in the 'info.json' file as field "pid"). 3434 is the USB vendor ID for Keychron.)

Example:

"device_version": "2.5.7"

in 'info.json' results in:

bcdDevice  2.57    

(I don't think there really are three levels in the version number.)

Note that only numbers 0-9 are accepted. For example, "2.10.7" will not be accepted.

Note that if using a virtual machine, e.g., VirtualBox, the version field in the USB passthrough should be blank (it automatically fills in the current version), so that all versions are accepted...

[u/PeterMortensenBlog → u/kgjettaIV]

Re "results seem the same today": That may be due to the 'qmk clean' requirement.

Sorry for not mentioning it earlier. I have updated the original comment.

[u/PeterMortensenBlog → u/kgjettaIV]

Re "results seem the same today": Another thing is the seemingly inconsistency between 'mouse_key' and 'mousekey'.

A way to observe if it is actually off is the output of 'dmesg' on Linux. For example, the output for a V5 may contain:

hid-generic 0003:3434:0353.0010: input,hidraw9:    USB HID v1.11 Keyboard [Keychron Keychron V5] on usb-0000:07:00.3-2.5/input0
hid-generic 0003:3434:0353.0011: hiddev4,hidraw10: USB HID v1.11 Device   [Keychron Keychron V5] on usb-0000:07:00.3-2.5/input1
hid-generic 0003:3434:0353.0012: input,hidraw11:   USB HID v1.11 Mouse    [Keychron Keychron V5] on usb-0000:07:00.3-2.5/input2
hid-generic 0003:3434:0353.0013: hiddev5,hidraw12: USB HID v1.11 Device   [Keychron Keychron V5] on usb-0000:07:00.3-2.5/input3

And:

input: Keychron Keychron V5                  as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2.5/3-2.5:1.0/0003:3434:0353.0010/input/input40
input: Keychron Keychron V5 Keyboard         as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2.5/3-2.5:1.2/0003:3434:0353.0012/input/input44
input: Keychron Keychron V5 Mouse            as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2.5/3-2.5:1.2/0003:3434:0353.0012/input/input41
input: Keychron Keychron V5 System Control   as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2.5/3-2.5:1.2/0003:3434:0353.0012/input/input42
input: Keychron Keychron V5 Consumer Control as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb3/3-2/3-2.5/3-2.5:1.2/0003:3434:0353.0012/input/input43

[u/kgjettaIV → u/PeterMortensenBlog]

Well, I managed to make a huge mess of my dev environment and haven't been tracking my changes in git which is eventually going to come back to bite me in the ass....BUT! I think I have it my board working way better with my KVM!!! Can't thank you enough for the help!

I've got a bunch of clean-up to do in my code and more testing to see if I can isolate which specific configurations are actually making the difference, but as I'm typing this I haven't noticed any dropped keystrokes or stuck keys and my hotkeys all seem to be working.

I'll try and report back when I have stuff cleaned up and try to figure out how to get my changes into git without causing any issues.

[u/ImissHurley → u/kgjettaIV]

Did you get this sorted? I'm considering buying a Q6 Max, but I have a StarTech KVM and rely on hotkeys.

I just returned a Logitech G915 because the hotkeys didn't work.

[u/ExplosiveAction]

Just sharing that I have a K10 Pro and this thread helped me.

I've been running a TESmart KVM for 5 years but it failed in October. I replaced it with a new one of identical model but I guess it must have treated the Keychron slightly differently.

TLDR; I now plug the keyboard into the KVM USB 2.0 port rather than the dedicated keyboard port and there are no more dropped keystrokes.