Mousekeys inertia zero friction improvements

[chaorace]

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

• [x] Core
• [x] Bugfix
• [x] New feature
• [x] Enhancement/optimization
• [ ] Keyboard (addition or update)
• [ ] Keymap/layout/userspace (addition or update)
• [x] 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

• [x] My code follows the code style of this project: C, Python
• [x] I have read the PR Checklist document and have made the appropriate changes.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[chaorace]

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]

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]

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]

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

[github-actions[bot]]

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 bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[chaorace]

Status Update: I am still waiting for a qmk collaborator to review the PR. Due to changes on the develop branch, there is now a trivial merge conflict which is strictly limited to the modified markdown file.

I'm not going to bother fixing the conflict until I know someone is ready to pay attention to this PR. No point in my doing that if it'll just accumulate new conflicts as time continues to go on, yeah?

[drashna]

There are some merge conflicts here now, due to updating the document code.

[chaorace]

Yes, and I'll repeat what I said earlier: I'm not going to bother fixing the conflict until I know someone is ready to pay attention to this PR. No point in my doing that if it'll just accumulate new conflicts as time continues to go on, yeah?

It's not fair to ask me to fix conflicts indefinitely. I'll put the work in to fix conflicts once and only once I know that my effort is not going to be wasted. I appreciate the consideration and will continue to patiently wait.

[drashna]

Then, most likely, it's not gonna get reviewed or merged.

Most of us won't review if there are conflicts, especially if you're actively refusing to fix those conflicts, because it shows an unwillingness to do the bare minimum to maintain the PR.

Unfortunately, merge conflicts do happen. In this case, the reason it has happened is that we've changed the entire document backend to something that should be much better (actual working and usable search, indexable by search engines, etc).

I've also dismissed my review until the merge conflict has been resolved, for above stated reasons.