Generate a hacky layout by parsing <keyboard>.dtsi

[nickcoutsos]

Using the devicetree parser and treating the default_transform.map node as row-based grid we can put together a rough ortholinear layout.

1. Each line in the map is a new row.
2. Find the column start/end location of each RC(...) instance
3. Compare each column's approximate position to the columns in the previous row
4. Cells with the greatest amount of text overlap are considered to be the same column

The result is a simple layout of 1u keys that means the end user doesn't need to have created an info.json file to get started. This process could spit one out, however, and give the user an opportunity to tweak it as required.

This will likely look like shit for row-staggered keyboards but I don't care.

[nickcoutsos]

I've got a preliminary implementation just testing against various map = < ... > strings, but going forward it should be noted that the location of the mapping isn't totally straightforward

• Split keyboards have <keyboard>.dtsi
• Unibody keyboards have <keyboard>.overlay
• Some repositories may be set up to build against keyboards defined in the main repo (or, technically, any other specified repo) and not have an easily accessible mapping at all
• Some keyboards do not define a keymap transform in which case the layout is effectively an ortholinear keyboard with size <rows>*<cols> as defined in the kscan node.

Probably not going to try too hard for some of these.

[nickcoutsos]

A basic implementation is in place for testing now.

If the server reports that the repo/branch doesn't have a config/info.json file it will prompt the user to try enabling the experimental auto layout functionality.

The settings dialog presents the option and describes its use and limitations.

With the experimental option enabled the backend will parse config/boards/shields/<keyboard>.dtsi, get the appropriate matrix transform's map, and create a layout to approximate the textual layout.

I haven some unit tests to see how it handles a small selection of layouts (including row staggered) and it's going better than I'd thought. I still need to add some error handling and a little more planning around where to actually find the matrix transform per the last comment.

[nickcoutsos]

Another note: if we're going as far as looking in boards/(shields|arm)/<keyboard>/ to find to find the matrix transform then we can also look out for a default <keyboard>.keymap there in case one doesn't exist under config/.

[nickcoutsos]

Finished this a little while ago. For the moment it expects to find the necessary files in the local repository or in the ZMK core repo. I may eventually add support for discovering and searching alternate remotes defined in west.yml.