Rebound v4 - New shield support

[PippinW]

Adds support for a new unibody shield: Rebound 4-3. Default keymap includes 1u thumb clusters on the left "half" and 2u thumb key on the right "half" to provide examples of each layout option.

Testing has been undertaken over USB and BLE using my own rebound 4-3 with n!n and encoder. No issues with build or in use.

[PippinW]

Sorry about the additional changes, which I should have done in draft.
This PR is now in final form and ready for review.

[Nicell]

I have a couple small comments. Then if you could add this shield to docs/docs/hardware.md, docs/static/setup.ps1, and docs/static/setup.sh, that'd be great.

Thanks for working on this!

[PippinW]

@Nicell

Thanks for taking a look at this!

I have committed your suggested revisions and made the additional changes to hardware.md, setup.ps1, and setup.sh.

I noticed at line 94 of setup.sh, it has "Pick an keyboard" rather than "Pick a keyboard". Let me know if you want me to fix the typo and I can include it in this PR.

[Nicell]

@PippinW Thanks for getting these updates in quick. It seems the formatting of setup.ps1 has been inadvertently updated. Could you take a look at that?

As for the typo, could you make a separate PR so it's simpler to track and get in?

[Nicell]

@PippinW looks like you're running into a failed prettier check. Could you run the prettier formatter on the docs folder and push the changes?

[PippinW]

@Nicell My bad!
Upon realising that I needed to install prettier, I wasn't able to get to this/hardware.md until this evening.
All sorted now. Thanks for pointing me in the right direction.

Noted on the separate PR for the typo - (I have also spotted that the recently added shield, BFO-9000 is numbered incorrectly on setup.sh. It is currently No.17 rather than No.20).

[Nicell]

@PippinW The mis-numbered item was fixed in the last shield that got merged I believe. I think setup.ps1 still is being reformatted for some reason. Could you address that and the merge conflicts with a rebase? This PR should be up next to be merged!

[PippinW]

@Nicell Thanks again - I think this is all sorted now!
(And noted on the numbering issue.)

[Nicell]

Looks good! Thanks.

[innovaker]

Thanks for contribution @PippinW.

I'm not familiar with this keyboard so forgive my ignorance. The shield id is given as rebound4, but I'm also seeing references to "Rebound", "Rebound v4", and "Rebound v4-3" across the files. It comes across as inconsistent to a naïve observer. Could there potentially be other versions of this shield such as "Rebound v5" or "Rebound v4-4"? Please help me to understand the bigger picture.

Otherwise, I only spotted very minor formatting tweaks.

[PippinW]

@innovaker - thanks for checking this over.

This Rebound shield PR is for v4.x (v4.0 and onwards uses a different matrix to previous iterations - it is currently at v4.9 and I have been informed that there are no plans for a v5.0 at present).
The reference to "v4-3" is because v4-3's schematics are the most recent version that is publicly available on the Rebound github repo. It is titled "rebound_4-3", but I think this reference is redundant for ZMK purposes.

I had intended to keep consistency by using rebound4 "where it mattered" (i.e. in the /app files), but I take your point and agree that standardised terminology across the PR is less likely to cause confusion to users.

Next steps:
I will retain the use of "rebound4" and amend all other references to bring them in line with this. I will also add a note in the README to explain in more detail which versions are, and are not supported.
Let me know if you think otherwise!

Thanks

[PippinW]

@innovaker All sorted and rebased! - Thanks!

[innovaker]

Thanks @PippinW!

You'll need to rebase again because a fix was committed recently that conflicts.

Thanks for explaining the versioning situation. I can see from a cursory look of the maker's website that there's not much information provided about what differentiates the versions:
https://store.montsinger.net/products/rebound

And it's only advertised as "Rebound" style 4.9.x.

Because of this, it might actually be worth calling the shield directory "rebound" but the files inside "rebound4". @Nicell, want do you think? I don't think we've hit versioned shields yet so this is new ground.

Otherwise, please note that you've used:

• Rebound 4.x in the hardware.md
• Rebound4 in setup.sh's options and shield_title
• Rebound4 in setup.ps1's $options

I don't know if you intended to have those matching.

[innovaker]

Because of this, it might actually be worth calling the shield directory "rebound" but the files inside "rebound4". @Nicell, want do you think? I don't think we've hit versioned shields yet so this is new ground.

Following a lengthy discussion about this, @PippinW please adopt this convention:

• app/boards/shields/rebound/rebound_v4.conf
• app/boards/shields/rebound/rebound_v4.dtsi
• app/boards/shields/rebound/rebound_v4.keymap
• app/boards/shields/rebound/rebound_v4.overlay

which also means its ids in the setup scripts would be rebound_v4 instead of rebound4.

I'm sorry for the trouble. This is the first shield we've encountered whose "variant" is simply a version instead of being clearly named or stated by the maker (e.g. the Rebound 4 or Rebound v4 or Rebound rev4 or Rebound MK IV), so this PR is effectively setting a new naming convention/precedent for similar boards/shields to follow. Thank you for your patience 👍

[PippinW]

@innovaker No problem at all, and thanks for clarifying the naming convention.
I have rebased, replaced all references with Rebound_v4, and changed the shield's directory to rebound.
This should now be ready!

[innovaker]

Thanks @PippinW!

Somehow you've now got 92 changed files in this PR. Do you need someone to help you sort this out?

[PippinW]

@innovaker Sorry about the mess. I have now cleaned up shop (and unintentionally closed the PR by a force-push).

[Nicell]

Thinking for the user facing strings we should have a space rather than an underscore. Also a small BFO change needs to be reverted in setup.sh.

[PippinW]

@Nicell - Thanks for the input and spotting that BFO problem. I have resolved as per your suggestions, rebased and squashed.

[PippinW]

@innovaker @Nicell, just a friendly nudge on this PR! - does it need any more work before merging?

[Nicell]

@PippinW Sorry about the huge delay here, for some reason our update message didn't get put on this PR, here's a copy of it:

Thank you, contributor, for your patience with how long review and merge of boards/shields has taken!

There are three recent refactors/changes to boards and shields that require some attention, and then we can finally get this PR merged!

1. Hardware Metadata
2. Pro Micro shield DT naming changes
3. Split changes for BLE advertising

Hardware Metadata

The Problem

When first developing the process around contributing new shields/boards to ZMK, we failed to recognize that several key files (setup scripts, documentation page of supported hardware, and GH Action build.yml file) required changes, often in the same spot, for every PR. This resulted in immediate merge conflicts for every other PR after one was merged, which is a headache for contributors.

The Fix

By adding discrete metadata files that are located with the boards/shields in question, and using that metadata to generate setup scripts, website hardware list, etc., users can contributing new hardware descriptions without the need to change the same files that other contributors are changing.

Next Steps

First, refer to https://zmk.dev/docs/development/hardware-metadata-files to familiarize yourself with the new metadata file format.

Next, you have two options for fixing up your PR:

1. If comfortable with git rebase, perform an interactive rebase and revert any changes to build.yml, hardware.md, or the setup scripts setup.sh/setup.ps1, and then add the new metadata YAML file. Then force push your branch. Or,
2. Create a new branch from an up-to-date main, copy in the files for your new hardware, add the metadata file, then commit and push the new branch. Then, edit your open PR to point to your new branch.

Pro Micro shield DT naming changes

In #876, we have simplified the DT naming for the "nexus node" we expose for pro-micro compatible boards, deprecating the use of pro_micro_a, and renaming pro_micro_d node to simply pro_micro. For pro-micro boards and shields, you'll need to adjust your DT to use the proper names.

Please see https://zmk.dev/docs/development/new-shield#shield-overlays for the updated docs on this.

Split Shield Advertising Changes

In addition, if this is a split PR, please see #658 where we have changed our conventions to remove the the name from the right sides, to prevent users attempting to pair with them and causing split sync issues. This also includes removing the " Left" suffix from the naming on the left side. See the changes in that PR for examples of what to change with your split shield.

Getting Help

If you have any questions about any of these changes, please comment here and tag @zmkfirmware/boards-shields or ask in the #boards-shields Discord channel.

[Nicell]

@PippinW I'll be closing this PR as we haven't heard anything in 6 months. Please feel free to reopen this if you ever come back to it.