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

Mousekeys inertia zero friction improvements #23677

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

chaorace
Copy link

@chaorace chaorace commented May 7, 2024

I like using Mousekeys in inertia mode with the friction turned off. It's a great way to get analog-like movements when piloted well, though there are some tweaks which I had to make in order to get things to properly behave when MOUSEKEY_FRICTION is set to zero.

These changes do very slightly impact the current behavior of the inertia mode, but only imperceptibly so.

Description

There are two changes included in this PR:

  1. A fix for a preexisting bug which caused different directions to decelerate differently. The fix is necessary for zero-friction to work correctly, because all directions must decelerate in exactly the same way (i.e.: not at all)
  2. A new option called MOUSE_STOP_SPEED which allows configuring a threshold below which velocity will snap to zero (if currently decelerating). A value of 0 is identical to the current behavior, though I've chosen a default of 1 instead because it makes stopping through reverse acceleration substantially easier regardless of the friction setting.

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

  • Fixes inconsistent deceleration behavior for mousekeys in inertia mode (per above). Not presently tracked on the issue tracker.

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

Velocity multiplication works the same regardless of sign.
Removing this unnecessary +1 makes it so that left/up & right/down
decelerate consistently with each other.
This new option controls the threshold at which velocity snaps to 0
whilst decelerating. Only applicable to the inertia mode
Comment on lines 299 to 300
else if (velocity <= MOUSEKEY_STOP_SPEED && velocity >= -MOUSEKEY_STOP_SPEED)
velocity = 0;
Copy link
Author

Choose a reason for hiding this comment

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

I wasn't quite sure what to do here regarding the styleguide. The guide is unambiguous in saying that braces must always be used... but since I am extending an existing unbraced if/else chain it felt wrong to differently format only my lines in the function.

I suppose I could have reformatted the entire function, but I worried that doing so would be considered out-of-scope for the purposes of this PR.

@@ -191,6 +191,7 @@ Recommended settings in your keymap’s `config.h` file:
|`MOUSEKEY_MAX_SPEED` |32 |Maximum cursor speed at which acceleration stops |
|`MOUSEKEY_TIME_TO_MAX` |32 |Number of frames until maximum cursor speed is reached |
|`MOUSEKEY_FRICTION` |24 |How quickly the cursor stops after releasing a key |
|`MOUSEKEY_STOP_SPEED` |1 |Lowest possible decelerating velocity before it snaps to 0 |
Copy link
Author

Choose a reason for hiding this comment

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

My Japanese isn't particularly good. Is it alright that I only updated the English documentation?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, that's fine.

@chaorace
Copy link
Author

chaorace commented May 7, 2024

Regarding tests: I couldn't seem to find any existing tests for mousekeys... so my takeaway was that this area of the code isn't considered critical enough to require tests.

If I'm wrong about that, I can give writing some tests a shot... but I'll need someone to point me towards a test file which would be workable as a template for mouse stuff.

@chaorace
Copy link
Author

chaorace commented May 7, 2024

Well... I suppose that I should have anticipated I'd get dinged by the linter regardless of existing code.

I've revised the surrounding calc_inertia function so that it's up to spec with the styleguide. If I wasn't supposed to do that, then please by all means feel free to drop f3d9898. Thanks

@drashna
Copy link
Member

drashna commented May 18, 2024

Regarding tests: I couldn't seem to find any existing tests for mousekeys... so my takeaway was that this area of the code isn't considered critical enough to require tests.

The reason for a lack of tests, is because the framework isn't written for them. Currently, the test framework only supports HID keyboard reporting, it doesn't support HID mouse reporting. It's something that does need to be built out, but nobody has stepped up to do it, yet.

Ideally, it is something that needs to be done and there should be tests for it.

@chaorace
Copy link
Author

Ah, lucky me that I get to skip eating my vegetables today!

@drashna drashna requested a review from a team May 19, 2024 04:39
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.

None yet

2 participants