[core][new feature]Pointing device modes

[Alabastard]

Okay everyone this PR is finally back again!

This update is quite significant and I have essentially redone a lot of the code changing how this feature works under the hood this will require quite a few changes to code that uses this feature.

I have put keycodes in 0.0.7 for now hopefully that is fine.

Look in the feature_pointing_device.md doc under the new section: Pointing Device Modes for how this feature works

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

[Alabastard]

is the boards that are going over the memory limit expected?
the code this adds to base without enabling anything is almost nothing...

[sigprof]

On NixOS with avr-gcc (GCC) 8.5.0 I get this on develop:

jones/v1:via        * The firmware is too large! 29126/28672 (454 bytes over)
keebio/bamfk1:via   * The firmware is too large! 28692/28672 (20 bytes over)

jones/v1:via is oversized even on master (40 bytes over); keebio/bamfk1:via on master barely fits (10 bytes free). So these boards are already broken on develop even without your changes, and are probably broken even on master with some different compiler versions.

[Alabastard]

Let me know if there is anything I can do to help the process along

[Alabastard]

Okay so a bit of a major update to how pointing mode maps are working.

Pointing mode maps now use action_exec to process key presses (basically the same code as for encoders) which enables the ability to use more than basic keycodes (such as QMK keycodes etc.). Not much changes at the keymap level other than the new POINTING_NUM_DIRECTIONS instead of hard coding 4 to avoid issues and now POINTING_MODE_MAP_COUNT is handled automatically and now only a POINTING_MODE_MAP_ENABLE = yes is needed in rules.mk).

Documentation has not been fully updated yet.

Still needs proper testing but I have been able to compile it without issue.

[Alabastard]

Okay should be cleaned up now. Sorry for anyone who picked it up while it was a bit of a mess for a bit there.
need to be better about maintaining my git exclusions and keeping my local repo up to date and based on latest develop.

[Alabastard]

Okay there was a bit more than documentation to fix up, but should be working as intended now.
POINTING_MODE_MAP_COUNT is now properly handled automatically at compile time (i.e. not intended for users to modify or define) pointing_mode_map_count(void) is meant for modifying map count if needed as a hidden feature similarly to encoders.

[Alabastard]

Argh another keyboard is going oversize again is this expected? (the code should not add much size without enabling things unless I missed something)
Also what is keeping this code from going into develop? is there anything that still needs to be addressed?

[burkfers]

I have some feedback:

First off, thank you very much, alabastard, this is great!

I tested the changes and have been running them on my productive keyboard for a combined 35 hours without trouble, though I did not try pointing mode maps yet.
It does what is advertised and does it well. Thanks to the expansive documentation, it was easy to integrate. I found no side effects that the docs didn't warn me about.

However, I found one small issue (or two tiny related ones, depending on how you look at it). The down and left directions of caret scrolling, volume, and history modes are swapped, and the order of the parameters for the relevant pointing_tap_codes are not in vimkeys order as documented.

I've submitted a PR to the source fork that hopes to address this minor issue.
Alabastard#1

[Alabastard]

First off, thank you very much, alabastard, this is great!

You are very welcome! I am just happy when someone uses my code :)

I tested the changes and have been running them on my productive keyboard for a combined 35 hours without trouble, though I did not try pointing mode maps yet. It does what is advertised and does it well. Thanks to the expansive documentation, it was easy to integrate. I found no side effects that the docs didn't warn me about.

This is great! glad it is working out there in the wild and that the docs were for the most part pretty clear/thorough!

However, I found one small issue (or two tiny related ones, depending on how you look at it). The down and left directions of caret scrolling, volume, and history modes are swapped, and the order of the parameters for the relevant pointing_tap_codes are not in vimkeys order as documented.

I've submitted a PR to the source fork that hopes to address this minor issue. Alabastard#1

Thanks for bringing this to my attention!
Also thanks for taking the effort to submit the PR!
However there is an issue with the PR you submitted in that you introduce a bug but you caught some bugs which thanks for that (I'll give more details in response to your PR).

[daskygit]

Currently there are still two requested features missing:

I'd vote for getting it merged as is, the extra features can always be sorted later and those will be a smaller (easier) pull request to review.

[Alabastard]

Okay as soon as I finish updating the docs I’ll push the refactor (as that simplifies things and makes those additional features much smaller updates) as it radically changes a few things on how to use the the modes. Sorry for all the delays and slow progress I only am getting a small amount of time per week to work on this

…

On Sun, Nov 10, 2024 at 5:00 PM Dasky ***@***.***> wrote: Currently there are still two requested features missing: I'd vote for getting it merged as is, the extra features can always be sorted later and those will be a smaller (easier) pull request to review. — Reply to this email directly, view it on GitHub <#21426 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMY4JLFEBKCXDJJE5LJ4HPDZ77XRTAVCNFSM6AAAAAAZ3GVIYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRWHE4TKOJVGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Alabastard]

Okay finally doing a full update and just running into some issues with keycodes as soon as I can set a new range I'll get this up

edit:
New range selected but I need to make some adjustments to account for the extended wheel reports (should be able to use my old code if it is handled the same way as my old implementation)

Really close here I'm hoping to get all this done over the holidays

[Alabastard]

Update:
New Code is compiling finally after a greater than expected number of changes to how the json needs to be setup and cleaning up the keycodes (currently I have added them as 0.07 let me know if I need to change that to 0.06).
Once I get it tested on a keyboard I will push the update, hopefully tomorrow.

Testing has been a lot more of a slog than I expected especially with getting the data driven config done correctly but progress is being made.

[Alabastard]

Okay running tally of everything that has been tested, fixed, and working:

• New Precision setting and Divisor code
• 4 way Maps ( allows for using QMK keycodes)
• 4 way tapping workaround function (legacy only standard keycodes allowed)
• D-PAD Mode type (Fixed!)
• Hold key modes (Working but differences to tapping mode are very subtle)
• 8 Way Maps (Working!)
• 2 Way Maps
• inverting setting per mode (part of mode type)
• allowing adjusting settings (Divisor, and type) on default modes (Drag/regular pointer)
• Finish updating Documentation with all changes (Now finally fixing up this)
  • Update 4-way mode maps documentation, divisor setting, and precision
  • Add 8-way mode map documentation
  • Update all function names to new naming scheme
  • Add section for adjusting mode types and options with examples
  • Update advanced mode type definitions to include new functions for accessing residuals etc.
  • Update any device switching code to reflect changes

[Alabastard]

Alright after a small detour to fix some bugs that went unnoticed in early testing I think the code is in the best state yet.

Should push very shortly

[Alabastard]

Will do linting once it tells me which files need formatting

Warning for anyone using the new version quite a bit has changed and I removed separate keycode tapping function as it is more limited than using the maps and creates a lot of redundant code (I could put it back if there is enough push back however).

In fact I have removed many, added several new functions, and renamed almost all functions and defines so please read the updated documentation (and let me know of any errors you find or improvements you think of)