An issue while remapping the keyboard can bring it to a bricked state, as described in the issue #58. It looks like the issue may be related to the architecture of the host machine (arm64 apple silicon), and it is not discarded something else like encoding/locale.
Potential Solutions
Before remapping the keyboard, the solution could generate the byte array for the default config and match it with an expected output (logic similar to a test run, but it would be executed at runtime). This step could be removed in the future, when the confidence on the solution increases. An extended version could also assert some conditions for custom remaps (as you cannot compare them to an expected output because they will vary based on the key maps), e.g. is there an expected number of bytes to be written, is it fixed or could we assert for a range?
Similar to the solution above, it would be great to have a unit test on this, or a command to check whether the platform is generating the expected output (in case you don't have the unit test framework setup and don't want to waste time setting it up);
Add a dry-run option to the commands that would output the bytes instead of writing them to the usb;
Notes
I'm not an experienced C/C++ developer but I can try to help. I'm considering to port the logic to Go (language I'm more familiar with) as it has less architecture dependencies and would be easier to build/distribute.
Description
Problem
An issue while remapping the keyboard can bring it to a bricked state, as described in the issue #58. It looks like the issue may be related to the architecture of the host machine (arm64 apple silicon), and it is not discarded something else like encoding/locale.
Potential Solutions
dry-runoption to the commands that would output the bytes instead of writing them to the usb;Notes
I'm not an experienced C/C++ developer but I can try to help. I'm considering to port the logic to Go (language I'm more familiar with) as it has less architecture dependencies and would be easier to build/distribute.