Tweak OS detect, add OS_DETECTION_SINGLE_REPORT #24379
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andrebrait
force-pushed
the
os_detection_improvements
branch
from
4b11976 to
8698ced
Compare
* Default OS_DETECTION_DEBOUNCE bumped from 200ms to 250ms * Add OS_DETECTION_SINGLE_REPORT to prevent undesired multiple reports * Prevents random stability issues on ARM MacBooks after switching via KVM * Works for every device I could test, including ARM MacBooks * Disabled by default to keep current behavior * Add Troubleshooting section on documentation * Tweak reset logic to prevent a freeze with some KVMs The USB stack on ARM MacBooks is more similar to that of iOS and, for some reason, it seems to like sending packets that influence the OS detection and results in a second OS_MACOS report being sent at a random period of time after plugging the keyboard back. This does not always happen and the consequences of this vary based on what the user is doing in the callback, but since this is not obvious and it's hard to debug, I've decided to add a flag for those affected by such issue. The stability issue I had in mine was a combination of factors and I found the actual cause being my own bad math when changing the default layer, but this change alone is also confirmed to fix it. Lastly, soem KVMs seem to leave the USB controlled in a suspended state when cold-booting Windows, meaning the keyboard would hang and the reset logic would not work. This tunes it so that it can get out of such state. Also retested for compatibility with my old KVM to ensure the logic works for both.
andrebrait
force-pushed
the
os_detection_improvements
branch
from
8698ced to
1c03187
Compare
drashna
approved these changes
Sep 10, 2024
tzarc
approved these changes
Oct 6, 2024
ilham-agustiawan
pushed a commit
to ilham-agustiawan/qmk_firmware
that referenced
this pull request
Nov 30, 2024
* Default OS_DETECTION_DEBOUNCE bumped from 200ms to 250ms * Add OS_DETECTION_SINGLE_REPORT to prevent undesired multiple reports * Prevents random stability issues on ARM MacBooks after switching via KVM * Works for every device I could test, including ARM MacBooks * Disabled by default to keep current behavior * Add Troubleshooting section on documentation * Tweak reset logic to prevent a freeze with some KVMs The USB stack on ARM MacBooks is more similar to that of iOS and, for some reason, it seems to like sending packets that influence the OS detection and results in a second OS_MACOS report being sent at a random period of time after plugging the keyboard back. This does not always happen and the consequences of this vary based on what the user is doing in the callback, but since this is not obvious and it's hard to debug, I've decided to add a flag for those affected by such issue. The stability issue I had in mine was a combination of factors and I found the actual cause being my own bad math when changing the default layer, but this change alone is also confirmed to fix it. Lastly, soem KVMs seem to leave the USB controlled in a suspended state when cold-booting Windows, meaning the keyboard would hang and the reset logic would not work. This tunes it so that it can get out of such state. Also retested for compatibility with my old KVM to ensure the logic works for both.
smallketchup82
pushed a commit
to smallketchup82/qmk_firmware
that referenced
this pull request
Dec 1, 2024
* Default OS_DETECTION_DEBOUNCE bumped from 200ms to 250ms * Add OS_DETECTION_SINGLE_REPORT to prevent undesired multiple reports * Prevents random stability issues on ARM MacBooks after switching via KVM * Works for every device I could test, including ARM MacBooks * Disabled by default to keep current behavior * Add Troubleshooting section on documentation * Tweak reset logic to prevent a freeze with some KVMs The USB stack on ARM MacBooks is more similar to that of iOS and, for some reason, it seems to like sending packets that influence the OS detection and results in a second OS_MACOS report being sent at a random period of time after plugging the keyboard back. This does not always happen and the consequences of this vary based on what the user is doing in the callback, but since this is not obvious and it's hard to debug, I've decided to add a flag for those affected by such issue. The stability issue I had in mine was a combination of factors and I found the actual cause being my own bad math when changing the default layer, but this change alone is also confirmed to fix it. Lastly, soem KVMs seem to leave the USB controlled in a suspended state when cold-booting Windows, meaning the keyboard would hang and the reset logic would not work. This tunes it so that it can get out of such state. Also retested for compatibility with my old KVM to ensure the logic works for both.
jlaptavi
pushed a commit
to jlaptavi/qmk_firmware
that referenced
this pull request
Dec 3, 2024
* Default OS_DETECTION_DEBOUNCE bumped from 200ms to 250ms * Add OS_DETECTION_SINGLE_REPORT to prevent undesired multiple reports * Prevents random stability issues on ARM MacBooks after switching via KVM * Works for every device I could test, including ARM MacBooks * Disabled by default to keep current behavior * Add Troubleshooting section on documentation * Tweak reset logic to prevent a freeze with some KVMs The USB stack on ARM MacBooks is more similar to that of iOS and, for some reason, it seems to like sending packets that influence the OS detection and results in a second OS_MACOS report being sent at a random period of time after plugging the keyboard back. This does not always happen and the consequences of this vary based on what the user is doing in the callback, but since this is not obvious and it's hard to debug, I've decided to add a flag for those affected by such issue. The stability issue I had in mine was a combination of factors and I found the actual cause being my own bad math when changing the default layer, but this change alone is also confirmed to fix it. Lastly, soem KVMs seem to leave the USB controlled in a suspended state when cold-booting Windows, meaning the keyboard would hang and the reset logic would not work. This tunes it so that it can get out of such state. Also retested for compatibility with my old KVM to ensure the logic works for both.
DmNosachev
pushed a commit
to DmNosachev/qmk_firmware
that referenced
this pull request
Dec 7, 2024
* Default OS_DETECTION_DEBOUNCE bumped from 200ms to 250ms * Add OS_DETECTION_SINGLE_REPORT to prevent undesired multiple reports * Prevents random stability issues on ARM MacBooks after switching via KVM * Works for every device I could test, including ARM MacBooks * Disabled by default to keep current behavior * Add Troubleshooting section on documentation * Tweak reset logic to prevent a freeze with some KVMs The USB stack on ARM MacBooks is more similar to that of iOS and, for some reason, it seems to like sending packets that influence the OS detection and results in a second OS_MACOS report being sent at a random period of time after plugging the keyboard back. This does not always happen and the consequences of this vary based on what the user is doing in the callback, but since this is not obvious and it's hard to debug, I've decided to add a flag for those affected by such issue. The stability issue I had in mine was a combination of factors and I found the actual cause being my own bad math when changing the default layer, but this change alone is also confirmed to fix it. Lastly, soem KVMs seem to leave the USB controlled in a suspended state when cold-booting Windows, meaning the keyboard would hang and the reset logic would not work. This tunes it so that it can get out of such state. Also retested for compatibility with my old KVM to ensure the logic works for both.
SyrupSplashin
pushed a commit
to SyrupSplashin/qmk_firmware
that referenced
this pull request
Dec 10, 2024
* Default OS_DETECTION_DEBOUNCE bumped from 200ms to 250ms * Add OS_DETECTION_SINGLE_REPORT to prevent undesired multiple reports * Prevents random stability issues on ARM MacBooks after switching via KVM * Works for every device I could test, including ARM MacBooks * Disabled by default to keep current behavior * Add Troubleshooting section on documentation * Tweak reset logic to prevent a freeze with some KVMs The USB stack on ARM MacBooks is more similar to that of iOS and, for some reason, it seems to like sending packets that influence the OS detection and results in a second OS_MACOS report being sent at a random period of time after plugging the keyboard back. This does not always happen and the consequences of this vary based on what the user is doing in the callback, but since this is not obvious and it's hard to debug, I've decided to add a flag for those affected by such issue. The stability issue I had in mine was a combination of factors and I found the actual cause being my own bad math when changing the default layer, but this change alone is also confirmed to fix it. Lastly, soem KVMs seem to leave the USB controlled in a suspended state when cold-booting Windows, meaning the keyboard would hang and the reset logic would not work. This tunes it so that it can get out of such state. Also retested for compatibility with my old KVM to ensure the logic works for both.
LeonMusCoden
pushed a commit
to LeonMusCoden/qmk_firmware
that referenced
this pull request
Jan 5, 2025
* Default OS_DETECTION_DEBOUNCE bumped from 200ms to 250ms * Add OS_DETECTION_SINGLE_REPORT to prevent undesired multiple reports * Prevents random stability issues on ARM MacBooks after switching via KVM * Works for every device I could test, including ARM MacBooks * Disabled by default to keep current behavior * Add Troubleshooting section on documentation * Tweak reset logic to prevent a freeze with some KVMs The USB stack on ARM MacBooks is more similar to that of iOS and, for some reason, it seems to like sending packets that influence the OS detection and results in a second OS_MACOS report being sent at a random period of time after plugging the keyboard back. This does not always happen and the consequences of this vary based on what the user is doing in the callback, but since this is not obvious and it's hard to debug, I've decided to add a flag for those affected by such issue. The stability issue I had in mine was a combination of factors and I found the actual cause being my own bad math when changing the default layer, but this change alone is also confirmed to fix it. Lastly, soem KVMs seem to leave the USB controlled in a suspended state when cold-booting Windows, meaning the keyboard would hang and the reset logic would not work. This tunes it so that it can get out of such state. Also retested for compatibility with my old KVM to ensure the logic works for both.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The USB stack on ARM MacBooks is more similar to that of iOS and,
for some reason, it seems to like sending packets that influence
the OS detection and results in a second OS_MACOS report being sent
at a random period of time after plugging the keyboard back. This
does not always happen and the consequences of this vary based on
what the user is doing in the callback, but since this is not
obvious and it's hard to debug, I've decided to add a flag for
those affected by such issue. The stability issue I had in mine was
a combination of factors and I found the actual cause being my own
bad math when changing the default layer, but this change alone is
also confirmed to fix it. Lastly, soem KVMs seem to leave the USB
controlled in a suspended state when cold-booting Windows, meaning
the keyboard would hang and the reset logic would not work. This
tunes it so that it can get out of such state. Also retested for
compatibility with my old KVM to ensure the logic works for both.
Types of Changes
Issues Fixed or Closed by This PR
Checklist