Fix OS_DETECTION_KEYBOARD_RESET

[qvr]

Description

In #24379 the OS_DETECTION_KEYBOARD_RESET logic got inadvertently changed to only reset if the keyboard ends up stuck in the INIT phase, which was apparently an issue with some KVMs, but this means that it no longer does what it originally was meant to do.

This PR leaves that functionality, but also resets the keyboard on USB device reinitilization again, as long as it had been stable for debounce duration before that. The debounce time used for reset is by default the same as for the detection, but it can be tuned with the undocumented OS_DETECTION_RESET_DEBOUNCE setting.

We set the debounce timer in the USB device change callback, because reacting to state changes in the main task loop feels racy. Actual reset still happens in os_detection_task, because some MCUs seem not to like it if they are being immediately reset on USB state change.

Fixes #24920.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• [Bug] OS_DETECTION_KEYBOARD_RESET is not executed #24920

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[bin101]

Hi sth seems to be still off.

After following this cycle:

1. Starting on macos (os is detected correctly)
2. Switching the KVM to windows (os is detected correctly)
   a. store_setups_in_eeprom()
3. Switching back to macos (os is NOT detected correctly)

My kb is in a frozen state and needs a power cycle.

The stored values print this on the console:

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: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 18, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 19, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 20, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 21, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 22, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 23, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 24, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 25, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 26, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 27, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 28, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 29, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 30, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 31, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 32, wLength: 0x202
Keebio:Iris LM-K Rev. 1:1: i: 33, wLength: 0x202
Keebio:Iris LM-K Rev. 1:1: i: 34, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 35, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 36, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 37, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 38, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 39, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 40, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 41, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 42, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 43, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 44, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 45, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 46, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 47, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 48, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 49, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 50, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 51, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 52, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 53, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 54, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 55, wLength: 0x20A

[tzarc]

All bets are off with a KVM, tbh. I wouldn’t be terribly confident that there are identical data streams from the host to kvm, and kvm to device. History has shown that the smarter the kvm, the less likely it is to work with that sort of thing.

[tzarc]

My kb is in a frozen state and needs a power cycle.

That said, this should probably be looked at. Only thought is perhaps it’s running out of eeprom and locking up.

[qvr]

My kb is in a frozen state and needs a power cycle.

Are you using this PR only, or do you have this part still commented out also?
#24920 (comment)

Just commenting out that check can easily lead to boot-loop.

[bin101]

I pulled the latest main from this mornin and replaced quantum/os_detection.c with your version.

[qvr]

I don't see how this code could end up frozen. Are you able to tell if it's in a boot loop or really frozen?

Have you changed the default debounce time? What code do you have in your process_detected_host_os_*?

[bin101]

Take a look at my userspace code

[qvr]

Take a look at my userspace code

You don't seem to have OS_DETECTION_KEYBOARD_RESET enabled at all, so this PR is not even compiled in. Possibly you are running out of eeprom as @tzarc suggested.

[bin101]

okay you're right but with the reset enabled the kb isn't showing any response at all after a KVM switch from macos to win.

with a switch from win to macos I can retrieve this output:

Keebio:Iris LM-K Rev. 1:1: i: 0, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 1, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 2, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 3, wLength: 0x04
Keebio:Iris LM-K Rev. 1:1: i: 4, wLength: 0x22
Keebio:Iris LM-K Rev. 1:1: i: 5, wLength: 0x04
Keebio:Iris LM-K Rev. 1:1: i: 6, wLength: 0x22
Keebio:Iris LM-K Rev. 1:1: i: 7, wLength: 0x04
Keebio:Iris LM-K Rev. 1:1: i: 8, wLength: 0x22
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: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 12, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 13, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 14, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 15, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 16, wLength: 0x202
Keebio:Iris LM-K Rev. 1:1: i: 17, wLength: 0x202
Keebio:Iris LM-K Rev. 1:1: i: 18, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 19, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 20, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 21, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 22, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 23, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 24, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 25, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 26, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 27, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 28, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 29, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 30, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 31, wLength: 0x20A
Keebio:Iris LM-K Rev. 1:1: i: 32, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 33, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 34, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 35, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 36, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 37, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 38, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 39, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 40, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 41, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 42, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 43, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 44, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 45, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 46, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 47, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 48, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 49, wLength: 0x103
Keebio:Iris LM-K Rev. 1:1: i: 50, wLength: 0x204
Keebio:Iris LM-K Rev. 1:1: i: 51, wLength: 0xBDA0
Keebio:Iris LM-K Rev. 1:1: i: 52, wLength: 0x101
Keebio:Iris LM-K Rev. 1:1: i: 53, wLength: 0x00
Keebio:Iris LM-K Rev. 1:1: i: 54, wLength: 0x202
Keebio:Iris LM-K Rev. 1:1: i: 55, wLength: 0xBDCD
Keebio:Iris LM-K Rev. 1:1: i: 56, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 57, wLength: 0x11
Keebio:Iris LM-K Rev. 1:1: i: 58, wLength: 0x202
Keebio:Iris LM-K Rev. 1:1: i: 59, wLength: 0xBE78
Keebio:Iris LM-K Rev. 1:1: i: 60, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 61, wLength: 0x22
Keebio:Iris LM-K Rev. 1:1: i: 62, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 63, wLength: 0x0E
Keebio:Iris LM-K Rev. 1:1: i: 64, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 65, wLength: 0x42
Keebio:Iris LM-K Rev. 1:1: i: 66, wLength: 0xFF
Keebio:Iris LM-K Rev. 1:1: i: 67, wLength: 0xFF

index 60 to 67 is the fingerprint I get from macos, so no reset executed? Will try the single report.

Edit: Activating single report also didn't help

[qvr]

okay you're right but with the reset enabled the kb isn't showing any response at all after a KVM switch from macos to win.

with a switch from win to macos I can retrieve this output:
index 60 to 67 is the fingerprint I get from macos, so no reset executed? Will try the single report.

Edit: Activating single report also didn't help

What response do you expect that you do not see? I'm not sure you can say based on the debug output that the reset did not happen.

Your process_detected_host_os_user will default to _MAC layout if the detection ends up unsure after the switch.

This PR will reset the keyboard if the USB state goes to INIT after it had already been CONFIGURED for debounce time. If your KVM does not change the USB state, or the OS can't be correctly fingerprinted via your KVM even after the reset, that would be beyond the scope of this PR.

[bin101]

Ah okay I thought the kb does a full "reboot" and I would see only the output from one os and then the detection by fingerprint grabs.

[bin101]

Sorry my C and hardware programming knowledge got a little bit rusty.
I tried to log the usb state changes with this quick 'n dirty change, so I can print the usb state changes to console:

diff --git a/quantum/os_detection.c b/quantum/os_detection.c
index df12297c14..5b9c9fa38a 100644
--- a/quantum/os_detection.c
+++ b/quantum/os_detection.c
@@ -29,10 +29,12 @@
 
  #    define STORED_USB_SETUPS 50
  #    define EEPROM_USER_OFFSET (uint8_t*)EECONFIG_SIZE
 
  static uint16_t usb_setups[STORED_USB_SETUPS];
+ static uint16_t usb_states[STORED_USB_SETUPS];
+ static uint8_t usb_states_index = 0;
  #endif
 
  #ifndef OS_DETECTION_DEBOUNCE
  #    define OS_DETECTION_DEBOUNCE 250
  #endif
@@ -190,10 +192,16 @@
      }
      current_usb_device_state = usb_device_state;
      last_time                = timer_read_fast();
      debouncing               = true;
 
+     usb_states[usb_states_index] = (uint16_t)usb_device_state.configure_state;
+     usb_states_index++;
+     if (usb_states_index >= STORED_USB_SETUPS) {
+         usb_states_index = 0;
+     }
+
  #ifdef OS_DETECTION_KEYBOARD_RESET
      if (current_usb_device_state.configure_state == USB_DEVICE_STATE_CONFIGURED) {
          configured_since = timer_read_fast();
      } else if (current_usb_device_state.configure_state == USB_DEVICE_STATE_INIT) {
          // reset the keyboard only if it's been stable for at least debounce duration, to avoid issues with some KVMs
@@ -223,13 +231,13 @@
      }
  #    endif
  }
 
  void store_setups_in_eeprom(void) {
-     eeprom_update_byte(EEPROM_USER_OFFSET, setups_data.count);
-     for (uint16_t i = 0; i < setups_data.count; ++i) {
+     eeprom_update_byte(EEPROM_USER_OFFSET, usb_states_index);
+     for (uint16_t i = 0; i < usb_states_index; ++i) {
          uint16_t* addr = (uint16_t*)EEPROM_USER_OFFSET + i * sizeof(uint16_t) + sizeof(uint8_t);
-         eeprom_update_word(addr, usb_setups[i]);
+         eeprom_update_word(addr, usb_states[i]);
      }
  }
 
  #endif // OS_DETECTION_DEBUG_ENABLE

Plain mac:

Keebio:Iris LM-K Rev. 1:1: i: 0, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 1, wLength: 0x03
Keebio:Iris LM-K Rev. 1:1: i: 2, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 3, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 4, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 5, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 6, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 7, wLength: 0x02

Plain win:

Keebio:Iris LM-K Rev. 1:1: i: 0, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 1, wLength: 0x03
Keebio:Iris LM-K Rev. 1:1: i: 2, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 3, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 4, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 5, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 6, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 7, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 8, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 9, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 10, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 11, wLength: 0x02

win -> mac:

Keebio:Iris LM-K Rev. 1:1: i: 0, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 1, wLength: 0x03
Keebio:Iris LM-K Rev. 1:1: i: 2, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 3, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 4, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 5, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 6, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 7, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 8, wLength: 0x03
Keebio:Iris LM-K Rev. 1:1: i: 9, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 10, wLength: 0x03
Keebio:Iris LM-K Rev. 1:1: i: 11, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 12, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 13, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 14, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 15, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 16, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 17, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 18, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 19, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 20, wLength: 0x02

mac -> win:

Keebio:Iris LM-K Rev. 1:1: i: 0, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 1, wLength: 0x03
Keebio:Iris LM-K Rev. 1:1: i: 2, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 3, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 4, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 5, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 6, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 7, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 8, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 9, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 10, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 11, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 12, wLength: 0x03
Keebio:Iris LM-K Rev. 1:1: i: 13, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 14, wLength: 0x03
Keebio:Iris LM-K Rev. 1:1: i: 15, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 16, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 17, wLength: 0x01
Keebio:Iris LM-K Rev. 1:1: i: 18, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 19, wLength: 0x02
Keebio:Iris LM-K Rev. 1:1: i: 20, wLength: 0x02

When i read this correctly the KVM is triggering the state change just fine. So my only guess is that setups_data is not reset on USB reINITs? Is this still not scope of my reported issue/this PR?

[qvr]

The one issue I can see is that your USB state is moving from configured to suspend and back twice, before moving to init state. The debounce timer for "last configured" state is reset during this, and then if the init happens during debounce window, no reset will happen.

I pushed a new commit that only sets the last configured timer once, and it is only reset in INIT state. Can you try this out if your keyboard is now reset correctly?

[bin101]

Unfortunately, this didn't solve the problem. Now I get a freeze every time I press the KVM switch.

[qvr]

Can you disable the debugging, and your other changes, and make sure you have the reset feature enabled?

[bin101]

Still no change

[bin101]

Found a working solution for me:

#ifdef OS_DETECTION_KEYBOARD_RESET
 static volatile bool was_configured_before = false;
 static volatile bool init_state_passed = false;
 #endif

 void os_detection_notify_usb_device_state_change(struct usb_device_state usb_device_state) {
     // treat this like any other source of instability
     if (maxprev_usb_device_state.configure_state < current_usb_device_state.configure_state) {
         maxprev_usb_device_state.configure_state = current_usb_device_state.configure_state;
     }
     current_usb_device_state = usb_device_state;
     last_time                = timer_read_fast();
     debouncing               = true;

 #ifdef OS_DETECTION_KEYBOARD_RESET
     if (init_state_passed && current_usb_device_state.configure_state == USB_DEVICE_STATE_CONFIGURED) {
        init_state_passed = false;

        if(was_configured_before) {
            soft_reset_keyboard();
        }
        was_configured_before = true;

     } else if (!init_state_passed && current_usb_device_state.configure_state == USB_DEVICE_STATE_INIT) {
         init_state_passed = true;
     }
 #endif
 }

The problem is the debounce check after usb state changes. os_detection_notify_usb_device_state_change with USB_DEVICE_STATE_INIT can easily skip over the if clause with the soft reset invoke if the time has not been progressed enough and then the usb state is already USB_DEVICE_STATE_CONFIGURED and we do not reset at all.

Only problem left: The kb will reset multiple times after pressing the KVM switch until the state is stabilized.

Green index keys = macos
Blue index keys = win

playback.1.mp4

[qvr]

and then the usb state is already USB_DEVICE_STATE_CONFIGURED and we do not reset at all.

So just to clarify, when you said that the keyboard was frozen, it was in fact not frozen and did just not simply reset and just stayed in previous mode? Or what did you mean by freeze? If the code did nothing, what was freezing? I'm really confused here.

Only problem left: The kb will reset multiple times after pressing the KVM switch until the state is stabilized.

I wonder if your issue would be solved with a smaller (customizable, separate from the detection) debounce time.

[bin101]

By freeze I meant that I got no reaction by keypresses, LEDs were all off or stayed in one previous configuration.

A separate smaller debounce time or no one at all (this is actually my solution?) is really maybe the answer.

@sigprof also mentioned this in #24920

[bin101]

This solution also works for me and is more complain with your approach:

#ifdef OS_DETECTION_KEYBOARD_RESET
    if (configured_since == 0 && current_usb_device_state.configure_state == USB_DEVICE_STATE_CONFIGURED) {
        configured_since = timer_read_fast();
    } else if (current_usb_device_state.configure_state == USB_DEVICE_STATE_INIT) {
        configured_since = 0;
    }

    // reset the keyboard only if it's been stable for at least debounce duration, to avoid issues with some KVMs
    if (configured_since > 0 && timer_elapsed_fast(configured_since) >= OS_DETECTION_DEBOUNCE) {
        soft_reset_keyboard();
    }
#endif

This also avoids multiple resets in my case.

[qvr]

Aha, so it sounds like your keyboard gets locked up if it is being reset immediately when it goes to INIT state? So the debounce timer is probably not your issue, and the original comment about resets there causing instabilities might be true after all.

I think the reset needs to be moved back to os_detection_task, and only leave the debounce timer (re-)setting in os_detection_notify_usb_device_state_change.

I pushed couple of new commits, can you test this now (on an otherwise clean git tree)? There's also the option of setting different debounce time for the reset, but try it with the default first.

[bin101]

Success 👍 Could even keep the reset debounce at 250ms. So the problem was indeed that the reset happened during INIT.

[qvr]

Great stuff! This was "fun" to debug. 👍

So note to maintainers, this is again ready for review, and now works for at least 2 people!

I can squash the commits if needed, or you can squash when merging, let me know.

[qvr]

Squashed and rebased onto develop.