Skip to content
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

Allow a larger int for the idle timeout for urbanvanilla keymap #19738

Merged
merged 1 commit into from
Apr 3, 2023

Conversation

tels7ar
Copy link
Contributor

@tels7ar tels7ar commented Feb 2, 2023

Existing code used a uint32_t for the idle timer, but the comparisons were done with timer_read and timer_elapsed so actual comparison was on uint16_t. This meant the idle timer could not be more than 65535 milliseconds, or just over 1 minute.

Switched the comparisons to timer_read32 and timer_elapsed32 so that the largest possible timeout is 4,294,967,295ms, or 136 years. While that would be pretty ridiculous, at least this way more reasonable longer timeouts like 15 minutes or an hour will work.

Description

Types of Changes

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

Issues Fixed or Closed by This PR

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).

@github-actions github-actions bot added the keymap label Feb 2, 2023
Existing code used a uint32_t for the idle timer, but the comparisons
were done with timer_read and timer_elapsed so actual comparison was
on uint16_t.  This meant the idle timer could not be more than 65535
milliseconds, or just over 1 minute.

Switched the comparisons to timer_read32 and timer_elapsed32 so that
the largest possible timeout is 4,294,967,295ms, or 136 years.  While
that would be pretty ridiculous, at least this way more reasonable
longer timeouts like 15 minutes or an hour will work.
@drashna drashna requested a review from a team February 2, 2023 21:39
@zvecr zvecr changed the base branch from master to develop February 2, 2023 22:20
Copy link
Member

@zvecr zvecr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@urbanvanilla will have to sign off on the changes, otherwise the change has to go via develop (which i've updated the target to reflect this).

@tzarc
Copy link
Member

tzarc commented Apr 3, 2023

Clearing backlog, merging to develop, will filter through to master in coming months.

@tzarc tzarc merged commit 162d615 into qmk:develop Apr 3, 2023
coquizen pushed a commit to coquizen/qmk_firmware that referenced this pull request Jun 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants