[keyboard] bastardkb: restructure folder hierarchy

[0xcharly]

Upstream changes to Bastard Keyboard boards.

This PR:

• Restructure folder hierarchy ahead of supporting other adapters/mcus
• Add support for 2 new keyboards:
  • Charybdis Mini (aka. Cmini, aka. Charybdis 3x6)
  • Dilemma
• Add support for adapter v2
• Add support for RP2040-based Splinky MCU

This PR is on behalf of @bstiq.

Description

Bastard Keyboards support for the following (adapter, mcu) pairs:

• v2/elitec
• v2/stemcell
• v2/splinky
• blackpill

This PR contains the following changes:

• Move previous implementation to a sub v1/elitec folder
• Add support for adapter v2
• Add support for Charybdis 3x6 format
• Add support for Dilemma
• Add support for RP2040-based MCU across all Bastard Keyboards
• Move keyboard USB IDs and strings to data driven
• Update headers to keep maintainers list up to date
• Run qmk format-c
• Minor no-op cleanups

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

[0xcharly]

A couple updates:

• Split the PR into 2 commits to make it easier to review: moved the changes from qmk format-c into a separate commit
• Rebased onto latest qmk:master

[drashna]

Also, rgb matrix modes removed, without being re-added elsewhere?

[0xcharly]

Also, rgb matrix modes removed, without being re-added elsewhere?

Correct, they were added back in a follow-up planned PR. Fixed and added back in this one.

(apologies for the delayed answer.)

[drashna]

bump?

[drashna]

@0xcharly, some concerns here:

Ideally, we don't want a bunch of specific boards listed. Converters should handle that, eventually. I'd argue v1_elite_c v2_elite_c and blackpill would be better names for the revisions here.

A revision for each carrier board or wiring harness rather than the controller used. Part of this is because we do have a specific direction we want to head with the converter stuff. Eg, CONVERT_TO, and PIN_COMPATIBLE, rather than twenty "CONVERT_TO_CONTROLLER_NAME" type settings.

[0xcharly]

A few notes that summaries the various conversations I had with @drashna, @filterpaper, and @KarlK90.

Stability

At this stage, those firmwares are rather well tested and considered stable. They are used daily by multiple members of our community, and are shipped with @bstiq's prebuilds (bastardkb.com).

They have been available through the github.com/bastardkb/bastardkb-qmk fork for close to a year, and have evolved to adopt the latest and greatest from QMK.

Freshness

To avoid the firmwares becoming stale, our fork is constantly updated against the latest changes that are upstreamed on qmk:master and qmk:develop, and against the latest designs and improvements that @drashna and @KarlK90 always kindly notifies us of.

We have been amongst the first few to add support for the STeMCell, and more recently the RP2040. We have integrated the recent improvements to the pointing device driver, and the latest feature for the Circque trackpad.

Converters

We've had several discussions with @drashna and @filterpaper w.r.t folder structure and use of converters instead of maintaining several sub folders for each boards.

• While the converters route seems promising, it does not seem to be fully adequate yet for BastardKB boards: we support multiple boards (pro micro, blackpill, elite-c, Splinky, STeMCell) for each keyboards, and while some of these share the same physical footprint (Elite-c/Splinky/STeMCell), these boards do not share the same feature set (mostly because we have to cut down a lot of features on AVR), nor do they always share the same configuration (eg. WS2812 driver configuration for the STeMCell). Using a multi folder structure simplifies the maintenance, and the build documentation
• Current converters seem to target the pro micro footprint, which does not include the bottom 5 pins that are available on boards that share the elite-c footprint, which the Bastard Keyboard line use, so converters as they stand today would only partially factorize the configuration, while still requiring per-board setup
• While the current structure and configurations are now well tested and I have a high level of confidence that they work as expected, I would not be able to say the same if we were to make changes now to these keyboard configurations (there are 26 different configurations, and multiple keymaps that would need retesting after such changes)

That being said, I am looking forward to the progress the core team is making with converters, and to being able to take advantage of them for the Bastard Keyboard firmwares. However, I believe this will be best addressed in future PR, to avoid further delaying the upstream of the Bastard Keyboard firmware implementations.

[0xcharly]

Thanks for the review @drashna, let me cleanup the Vial-related stuff.

[keyboard-magpie]

Very impressive work overall, edit: everything is in place already I requested!

[bstiq]

Excellent work @0xcharly , thanks !
Looks good to me.