[Bug] OS_DETECTION_KEYBOARD_RESET is not executed

[bin101]

Describe the Bug

My Setup:

• M2 Macbook Air
• Windows PC
• KVM Switch in the middle

Keyboard Used

keebio/iris_lm/k1

Link to product page (if applicable)

https://keeb.io/products/iris-lm-keyboard

Operating System

macOS 15.3.1 and Windows 11

qmk doctor Output

❯ qmk doctor 
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.6
Ψ QMK home: /Users/bin101/Repos/qmk_firmware
Ψ Detected macOS 15.3.1 (Apple Silicon).
Ψ Testing userspace candidate: /Users/bin101/Repos/qmk_userspace -- Valid `qmk.json`
Ψ QMK userspace: /Users/bin101/Repos/qmk_userspace
Ψ Userspace enabled: True
Ψ Git branch: master
Ψ Repo version: 0.27.13
Ψ - Latest master: 2025-02-15 05:56:00 +0100 (5e88647879) -- Fix installation of clang in gentoo install script (#24917)
Ψ - Latest upstream/master: 2025-02-15 05:56:00 +0100 (5e88647879) -- Fix installation of clang in gentoo install script (#24917)
Ψ - Latest upstream/develop: None
Ψ - Common ancestor with upstream/master: 2025-02-15 05:56:00 +0100 (5e88647879) -- Fix installation of clang in gentoo install script (#24917)
Ψ - Common ancestor with upstream/develop: None
Ψ CLI installed in virtualenv.
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 8.5.0
Ψ Successfully compiled using arm-none-eabi-gcc
Ψ Successfully tested arm-none-eabi-binutils using arm-none-eabi-size
Ψ Found avr-gcc version 8.5.0
Ψ Successfully compiled using avr-gcc
Ψ Successfully tested avr-binutils using avr-size
Ψ Found avrdude version 8.0
Ψ Found dfu-programmer version 1.1.0
Ψ Found dfu-util version 0.11
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2024-02-17 19:20:06 +0000 --  (be44b3305f)
Ψ - lib/chibios-contrib: 2024-04-03 20:39:24 +0800 --  (77cb0a4f)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

My current firmware code:
https://github.com/bin101/qmk_userspace

Starting on MacOS I get this console output:

Ψ Console Connected: Keebio Iris LM-K Rev. 1 (CB10:1756:1)
Keebio:Iris LM-K Rev. 1:1: i: 0, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 1, wLength: 0x22
Keebio:Iris LM-K Rev. 1:1: i: 2, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 3, wLength: 0x0E
Keebio:Iris LM-K Rev. 1:1: i: 4, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 5, wLength: 0x42
Keebio:Iris LM-K Rev. 1:1: i: 6, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 7, wLength: 0xFF

After switching to my Windows machine and back to the Mac I get this output:

Ψ Console Connected: Keebio Iris LM-K Rev. 1 (CB10:1756:1)
Keebio:Iris LM-K Rev. 1:1: i: 0, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 1, wLength: 0x22
Keebio:Iris LM-K Rev. 1:1: i: 2, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 3, wLength: 0x0E
Keebio:Iris LM-K Rev. 1:1: i: 4, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 5, wLength: 0x42
Keebio:Iris LM-K Rev. 1:1: i: 6, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 7, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 8, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 9, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 10, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 11, wLength: 0x04
Keebio:Iris LM-K Rev. 1:1: i: 12, wLength: 0x22
Keebio:Iris LM-K Rev. 1:1: i: 13, wLength: 0x04
Keebio:Iris LM-K Rev. 1:1: i: 14, wLength: 0x22
Keebio:Iris LM-K Rev. 1:1: i: 15, wLength: 0x04
Keebio:Iris LM-K Rev. 1:1: i: 16, wLength: 0x22
Keebio:Iris LM-K Rev. 1:1: i: 17, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 18, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 19, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 20, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 21, wLength: 0x22
Keebio:Iris LM-K Rev. 1:1: i: 22, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 23, wLength: 0x0E
Keebio:Iris LM-K Rev. 1:1: i: 24, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 25, wLength: 0x42
Keebio:Iris LM-K Rev. 1:1: i: 26, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 27, wLength: 0xFF

[tzarc]

Some “smart” KVMs are known to cause problems with “smarter” USB devices — in effect acting as their own OS. Unless it’s a true USB passthrough you may not be receiving what your host OS is sending due to the KVM interception. Not sure there is a lot that can be done.

[bin101]

one addition:

A direct connection to my mac had the same sequence, so at least that changed with my current macOS version

[bin101]

The debounce check seems to be interfering in my case. Commented the logic and now the switch back and forth is working

[sigprof]

The sequences here seem to roughly match the expected sequences from macOS and Windows (except the macOS sequence for some reason has 3 packets with length 0x02 instead of 2, so it won't match the sequence which is expected by the current version of the OS detection code — maybe this was caused by some macOS updates since that time). So the real problem here is how to detect the fact that USB had been switched to a different host — the OS_DETECTION_KEYBOARD_RESET feature was intended to address this, but apparently does not.

Looks like the initial implementation of OS_DETECTION_KEYBOARD_RESET in #21777 was performing the reset immediately after moving from USB_DEVICE_STATE_CONFIGURED to USB_DEVICE_STATE_INIT. However, in #24379 that code was changed to also have the if (debouncing && timer_elapsed_fast(last_time) >= OS_DETECTION_DEBOUNCE) check around it, so it expects that the KVM switch keeps the keyboard in the USB reset state for some time longer than OS_DETECTION_DEBOUNCE — and that is the same timeout that is used for the actual debouncing of the OS detection result, so it can't be decreased arbitrarily to match the reset time without also breaking the OS detection. Maybe those two debounce times should be decoupled, so that a shorter debounce time (or even 0) could be specified for the keyboard reset. Another option is to use a completely different debouncing mechanism for the keyboard reset — instead of waiting for the USB_DEVICE_STATE_INIT state with the specified duration, perform the reset immediately on switching to USB_DEVICE_STATE_INIT, but only after some specified time had been spent in the USB_DEVICE_STATE_CONFIGURED state; this should still avoid quick reset loops, but would work even if the KVM switch does not keep the keyboard in the USB reset or suspend state for a significant time before switching the port to another host.