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

fix unreliable multimedia keys on Planck rev 6.1/Proton-C #13959

Closed
wants to merge 1 commit into from

Conversation

aumuell
Copy link

@aumuell aumuell commented Aug 10, 2021

Description

Rotary encoders mapped to volume control would work very unreliably both on a Planck rev 6.1 and a Sofle V2 with Proton-Cs: only every 100th or so step would trigger a volume change, both on Linux and macOS. After copying these few lines from the send_mouse function in the same file, the encoders worked reliably. I don't know why that helped.

Types of Changes

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

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

without this change that was copied from send_mouse, only every 100th
or so step on my volume encoder would trigger a volume change both on
Linux and macOS
@zvecr zvecr added the core label Aug 10, 2021
@drashna drashna requested a review from a team August 11, 2021 01:53
@stale
Copy link

stale bot commented Sep 26, 2021

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

@fauxpark
Copy link
Member

Why not just use tap_code_delay()? That usually fixes this issue.

@stale
Copy link

stale bot commented Oct 30, 2021

Thank you for your contribution!
This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready.

@stale stale bot closed this Oct 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants