-
-
Notifications
You must be signed in to change notification settings - Fork 39.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Core] Add OS detection callbacks #21777
Conversation
Ah, it's missing one change I made yesterday. Gonna update it, but the general picture is unchanged. |
1d1a24a
to
9e96586
Compare
9986dc5
to
aacc264
Compare
b9a0a71
to
2372428
Compare
@sigprof ping |
Thank you for your contribution! |
Thank you for your contribution! |
@drashna any chance you can help this PR leave limbo? 😜 |
Or is it expected to be stale until the breaking change merges start? |
@pfn got it. The weirdest part is that nothing should have changed there. All I did was making Could you undo that, recompile and try again? |
I'll give it a try tomorrow or Friday |
That screenshot on Windows is the negotiation dump from OS detection debugging after switching to mac saving the packet, switching back to Windows and dumping. Resetting the keyboard while on mac produces the same packet. I didn't print out the contents of Windows negotiation in the screenshot. Yes, all dumps are with code from current PR.
I haven't tried this yet, will try again tomorrow. |
Never mind. It's an actual bug. Got it. Could you please replace line 133 from if (guessed != OS_UNSURE) detected_os = guessed; and then try it? I think current EDIT: yeah, you actually said yourself that it detected That likely caused it to revert back to For backwards compatibility sake, I'll revert this behavior and I'll add your packets to the unit testing suit so we do not regress this way again. Do you have an actual iOS device to test as well? I'd need to check if it's safe to change the condition for |
Yes! This change has my keyboard detecting my Mac is OS_IOS again now after switching. Makes sense why this happens.
Same behavior on master, detecting as OS_IOS (just mentioning).
I do not have an iOS device to test. |
@pfn thanks for testing it, providing debug data (extremely valuable!) and confirming the fix. It's really appreciated. I'll push it alongside with a test case later today or tomorrow. |
9a3b87f
to
7418712
Compare
Thanks, works great with everything up-to-date. Re the description:
Is it worth updating the PR description with regards to KVM switching? It works for my cheap USB switcher. |
@pfn yeah, done it. I also removed the part where I said tests were pending, since the PR has contained tests for a while now. It seems fixing the issue you had also fixed the weird instability I very rarely found under macOS. |
* Debounce OS detection (defaults to 100ms) * OS callbacks happen on to the main loop
7418712
to
3033206
Compare
This reverts commit 0cc6bb2.
Amazing feature, thanks! A simple way to set the behaviour of CTRL and GUI across OSs. #ifdef OS_DETECTION_ENABLE
bool process_detected_host_os_kb(os_variant_t detected_os) {
if (!process_detected_host_os_user(detected_os)) {
return false;
}
switch (detected_os) {
case OS_MACOS:
keymap_config.swap_lctl_lgui = keymap_config.swap_rctl_rgui = true;
break;
case OS_IOS:
keymap_config.swap_lctl_lgui = keymap_config.swap_rctl_rgui = true;
break;
case OS_WINDOWS:
keymap_config.swap_lctl_lgui = keymap_config.swap_rctl_rgui = false;
break;
case OS_LINUX:
keymap_config.swap_lctl_lgui = keymap_config.swap_rctl_rgui = false;
break;
case OS_UNSURE:
keymap_config.swap_lctl_lgui = keymap_config.swap_rctl_rgui = false;
break;
}
return true;
}
#endif |
@aadcg I didn't even know this exists. Gonna check it out later. |
(cherry picked from commit 80f3da3)
Description
This adds callbacks for OS detection, similar to other mechanisms we already have to allow the KB/user to run custom code on an event.
The main use is withholding taking action until the OS detection has run, so the user does not have to craft some sort of periodic checks for the current OS, etc. As an example (and my usage), to set the current default layer depending on whether the detected OS is Windows, macOS, etc.
This also eliminates any questions on whether OS_UNSURE means the detection ran and it resulted in that, or if it just happened to be the default value.
Since the detection runs when the USB device descriptor is being assembled, I added the option to also automatically reboot the keyboard when the USB link goes back to a non-configured state, due to e.g. KVM switching when the KVM does not cut power to the USB devices. This will trigger the initialization again and thus allows the detection to run again for the new host device. This is disabled by default and can be enabled by defining
OS_DETECTION_KEYBOARD_RESET
.Types of Changes
Issues Fixed or Closed by This PR
Checklist