added timber wolf keyboard

[Croktopus]

added firmware for timber wolf. some elements such as via keymaps and info.json arent confirmed to be working, but I think they should be good and don't know how to test without merging into QMK proper.

Description

added timber wolf keyboard, with subdirectories for the 3 versions (they differ physically in layout but share a pcb).

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

• none

Checklist

• My code follows the code style of this project.
• 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).

[zvecr]

they differ physically in layout but share a pcb

If this is the case, the a, b, prime board revisions dont add a ton of value. To confirm, its exactly the same PCB between those 3 examples above?

[Croktopus]

they differ physically in layout but share a pcb

If this is the case, the a, b, prime board revisions dont add a ton of value. To confirm, its exactly the same PCB between those 3 examples above?

it is exactly the same pcb, but the layout files for a TBR-Prime will not work for a TBR-A or a TBR-B, etc. which kills the idea of a default layout

[zvecr]

If its one PCB, then it should be a single keyboard with no revisions and then LAYOUT macros for the available options. This means ditching the a,b,prime subfolders.

[Croktopus]

but it's a really weird pcb. https://geekhack.org/index.php?action=dlattach;topic=102520.0;attach=226645;image you see how things like the arrows are in a different place from one another and stuff?

If you let me do this I'll promise to make no rev2 pcbs, but the alternative isnt combining them and doing stuff in the layout files to fix it (because that simply won't work), it's splitting it into 3 keyboards entirely. which i can do.

[zvecr]

the alternative isnt combining them and doing stuff in the layout files to fix it (because that simply won't work)

Layout macros is exactly the way to manage this, and is working perfectly in many other use cases within the repo. We dont use board revisions to do different bottom rows on a 60% keyboard. We have stuff like keebio/quefrency with its snap off sections, boardwalk with its ortho and non ortho layouts. All this is done with layout macros.

[Croktopus]

but if I'm then relying on layout macros, the default keymap & layout become useless. which seems pretty non-ideal from a user perspective. the reason i set it up as multiple boards in the first place is because in the original PR i was told i need to add a default keymap so this was my way to do that in a sensible way.

this is not just a difference in bottom rows - for example, the switch pins for right control on Prime are the same as the switch pins for left arrow on A, and they are physically separated as you can see in that image. its a similar story for the other arrows, nav cluster area, etc. its more like there are multiple physical keyboards crammed onto a single pcb.

can you explain to me why we cant do this as multiple folders? i understand that the intent was to support multiple revisions of a pcb, but it seems like it still makes sense to use that feature for this application.

[zvecr]

As this is one pcb with multiple layouts available, it should not use board revisions to separate case compatibility and should rely on layout macros to do so. Apart from providing a default keymap, any other layout macros can be represented with something like default_prime.

[Croktopus]

im working on merging the boards into a single directory. plan to commit those changes tonight.

[Erovia]

Incompatible versions should be handled as revisions.
Common code should be at the keyboards/metamechs/timberwolf/ level, version-specific code below that in appropriately named directories.

[drashna]

Could the docs changes listed above be applied?

[Croktopus]

I've updated the readme to reflect the changes to the file structure.

[zvecr]

As a note, C6 should be able to do HARDWARE_PWM using timers rather than the super crude task emulation.

I wont mark it as a blocking requirement, more a "you should try it and see if its better" kinda thing

[Croktopus]

thanks for pointing this out - that was a holdover from the last revision that used c7 or something instead

[zvecr]

Thanks!

Also as a little bit too late note, info.json looks to be spitting out some errors but we can easily patch that up.

[Croktopus]

looks like the errors are only occurring on layout_all right? that's strange - when i preview the info.json using ctrl+shift+i it works fine.

edit: oh wait the keycodes arent showing up either....

since it looks like there will be more changes to this, should i delete branch and start a new one or continue making changes in this branch?