[Bug] Mouse keys prevent keyboard from starting up when switching inputs using KVM switches

[andrebrait]

Describe the Bug

I had submitted #15939 but, after finding other users reporting issues with KVMs when enabling mouse keys, I see this is a common issue. Even though KVMs used to be a niche thing, people are using them more with WFH and all that, so maybe it's worth taking a look into why that happens.

My understanding is that QMK will present two devices (a keyboard and a mouse) connected through a hub and that is the cause of those issues.

System Information

• Keyboard: GMMK Pro, JJ50, Planck EZ
  • Revision (if applicable):
• Operating system: Windows, Linux, macOS
• AVR GCC version: various

• ARM GCC version: various

• QMK Firmware version: various

• Any keyboard related software installed?
  • AutoHotKey
  • Karabiner
  • Other:

Additional Context

I haven't been able to identify why that could be happening at all. Would appreciate input on where to look, if any bits are suspicious.

[drashna]

Does adding MOUSE_SHARED_EP = yes to your rules.mk help?

[andrebrait]

Does adding MOUSE_SHARED_EP = yes to your rules.mk help?

I didn't try that. I'll see if it helps.

Yup, necro-ing my own issue 😅

[sigprof]

MOUSE_SHARED_EP = yes is the default anyway (but some keyboards override that to no, and for some reason this includes planck/ez; strangely enough, ploopyco/ devices don't do that).

There is also KEYBOARD_SHARED_EP = yes, but in this case it's more likely to break things than to fix them; but you might still try to test the behavior with your hardware.

And KVMs can be weird — e.g., see #19472, where apparently having VIA enabled prevents KVM from passing through the data on any other HID interfaces past that, and given that the VIA interface must have index 1 due to some broken behavior in the VIA app, this effectively prevents using anything above basic 6KRO when VIA is enabled (and that KVM does not support NKRO anyway, which is apparently also very common for KVMs).