feat(boards): Generic 40%, 50%, 60%, 65%, 75% and tkl physical layouts

[ReFil]

This PR adds physical layout definitions for all the common physical layouts for 40% ortho through tkl unibody keyboards as well as implementing them on the relevant boards.

All boards have been confirmed to build, but I don't have many of these boards to test on personally. I can test on all the boards I do have access to

[lesshonor]

If you have strong sentiments about the naming of the matrix-transform attributes, I think it would be a good idea to add docs with naming guidelines.

[ReFil]

the use of &kscan0 has been ended up being a de facto standard across a lot of boards. standardising on the matrix transform naming scheme as matrix_transform_<size>_<quirks/specifics> in documentation is a good idea, I'll add that

[lesshonor]

the use of &kscan0 has been ended up being a de facto standard across a lot of boards. standardising on the matrix transform naming scheme as matrix_transform_<size>_<quirks/specifics> in documentation is a good idea, I'll add that

I think it's a great idea to establish naming guidelines. My main concern is that board/shield creators will see the layouts here (with predefined &kscans and &matrix-transforms), say "That isn't close enough to what I need", and roll their own...which kind of defeats the purpose.

Manipulating the devicetree via labels/phandles/etc is an obscure tactic this side of Zephyr; even before app/dts/layouts/foostan/corne.dtsi was merged, parts of it were being extracted "because I wasn't going to need the 5 column transform". (if you're reading this: no shade intended.)

I'm sure "I didn't need X/Y doesn't match my build so I just cut-pasted Z in" will be a constant refrain regardless of what approach is taken here. (Especially if the first ZMK Studio video tutorial does so.) My five cents is just a wager that if the common layouts are defined loosely enough, it will happen less often.

[ReFil]

Unless I'm mistaken the kscan and matrix transform can be overridden in downstream boards by calling the layout node and overriding it, that was the impression under which I did this, if that's not the case then I agree it should be dropped from the layout and configured on a per board basis upstream. Perhaps this is also something that can be addressed through documentation. I'll do some testing quickly and get back on this point

[ReFil]

Just given this a big shake up, removing transform names from the layouts, moving each layout to it's own file so no need for /delete-node/ schenanigans and going back to chosen kscan nodes

[petejohanson]

Just given this a big shake up, removing transform names from the layouts, moving each layout to it's own file so no need for /delete-node/ schenanigans and going back to chosen kscan nodes

Given the fix merged in #2490 is in, I think we should be moving to:

• Have split files like you have here.
• Also offer a "one stop shop" .dtsi that pulls in the unique files, and adds a position map. I'm on the fence on the status we should set here, but I suspect we should disable them all, and allow importers to enable just the layouts they use. That will allow us to add more variants to the aggregate .dtsi later and not break things.

Thoughts?

[ReFil]

I was thinking about the position map earlier. I'm not sure if it should be done in a generic basis because the layouts each board supports are going to be different, and if a layout is omitted but the position map is tried to be used the build will fail

[petejohanson]

I was thinking about the position map earlier. I'm not sure if it should be done in a generic basis because the layouts each board supports are going to be different, and if a layout is omitted but the position map is tried to be used the build will fail

Can you describe a bit more the build failure you're talking about?

[ReFil]

Would the build not fail if the position map references a disabled or absent layout? It's on my list to add position mapping to the ckp and 40&50% boards anyway so I'll be able to do testing but my understanding of device tree was that it would fail in processing that

[petejohanson]

Would the build not fail if the position map references a disabled or absent layout? It's on my list to add position mapping to the ckp and 40&50% boards anyway so I'll be able to do testing but my understanding of device tree was that it would fail in processing that

The code is set up so the position map can reference a disabled layout, and that layout will be skipped. It should compile and work fine. I've tested with posix minivan setup recently.

[ReFil]

Ah ok awesome, I'll get to work on adding that later then

[ReFil]

Physical layout maps for 40 through 75% have been added, and all multi layout boards now incorporate the physical layout map. I've tested 60, 65 and 75 and checked that 40 and 50 compile but haven't got a suitable board for testing to hand

[petejohanson]

A few thoughts on the implementation. I think we are very close here though.

Thanks for working on this!

[petejohanson]

A few more items. Thanks again!

[petejohanson]

Ditto on naming.

[petejohanson]

Just one question, otherwise LGTM.