Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed Iris default build/Updated Dev Guide #187

Merged
merged 9 commits into from
Sep 20, 2020
Prev Previous commit
Next Next commit
Revert "Merge pull request #1 from zmkfirmware/main"
This reverts commit 36da21b, reversing
changes made to 719db13.
  • Loading branch information
kurtis-lew committed Sep 15, 2020
commit 5383bdd4dfc85b7782c489341eff96d0abf7dc72
Binary file not shown.
2 changes: 1 addition & 1 deletion docs/docs/behavior/hold-tap.md
Original file line number Diff line number Diff line change
Expand Up @@ -59,4 +59,4 @@ If this config does not work for you, try the flavor "tap-preferred" and a short
If you want to use a tap-hold with a keycode from a different code page, you have to define another behavior with another "bindings" parameter.For example, if you want to use SHIFT and volume up, define the bindings like `bindings = <&kp>, <&cp>;`. Only single-argument behaviors are supported at the moment.

#### Note
Astute readers may notice similarities between the possible behaviors in ZMK and other firmware, such as QMK. The hold-preferred flavor works similar to the `HOLD_ON_OTHER_KEY_PRESS` setting. The 'balanced' flavor is similar to the `PERMISSIVE_HOLD` setting, and the `tap-preferred` flavor is similar to `IGNORE_MOD_TAP_INTERRUPT`.
Astute readers may notice similarities between the possible behaviors in ZMK and other firmware, such as QMK. The hold-preferred flavor works similar to the `HOLD_ON_OTHER_KEY_PRESS` setting. The 'balanced' flavor is similar to the `PERMISSIVE_HOLD` setting, and the `tap-preferred` flavor is similar to `IGNORE_MOD_TAP_INTERRUPT`.
2 changes: 0 additions & 2 deletions docs/docs/dev-boards-shields-keymaps.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,8 +35,6 @@ in the `app/boards/${arch}/${board_name}` directory, e.g. `app/boards/arm/planck

## Pro Micro Compatible Keyboard

![Labelled Pro Micro pins](assets/pro-micro/pro-micro-pins-labelled.jpg)

For keyboards that require a (usually Pro Micro compatible) add-on board to operate, the ZMK integration pieces are places
in the _shield_ definition for that keyboard, allowing users to
swap in different Pro Micro compatible boards (e.g. Proton-C, or nice!nano) and build a firmware the matches their actual
Expand Down
4 changes: 0 additions & 4 deletions docs/docs/dev-guide-new-shield.md
Original file line number Diff line number Diff line change
Expand Up @@ -67,10 +67,6 @@ endif

## Shield Overlay

![Labelled Pro Micro pins](assets/pro-micro/pro-micro-pins-labelled.jpg)

ZMK uses the green color coded pin names to generate devicetree node references. For example, to refer to the node `D0` in the devicetree files, use `&pro_micro_d 0` or to refer to `A1`, use `&pro_micro_a 1`.

The `<shield_name>.overlay` is the devicetree description of the keyboard shield that is merged with the primary board devicetree description before the build. For ZMK, this file at a minimum should include the [chosen]() node named `zmk,kscan` that references a KSCAN driver instance. For a simple 3x3 macropad matrix,
this might look something like:

Expand Down