From 57e08eb8badc5db2fb44d2df684f32ea48cce411 Mon Sep 17 00:00:00 2001 From: Jack Humbert Date: Thu, 7 Jul 2016 11:33:32 -0400 Subject: updates rgblight implementation, makes non-timer stuff compatible with audio --- readme.md | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index c24d951d8d..e874812515 100644 --- a/readme.md +++ b/readme.md @@ -704,23 +704,18 @@ For this mod, you need an unused pin wiring to DI of WS2812 strip. After wiring RGBLIGHT_ENABLE = yes -Please note that the underglow is not compatible with audio output. So you cannot enable both of them at the same time. +In order to use the underglow timer functions, you need to have `#define RGBLIGHT_TIMER` in your `config.h`, and have audio disabled (`AUDIO_ENABLE = no` in your Makefile). -Please add the following options into your config.h, and set them up according your hardware configuration. These settings are for the F4 by default: - - #define ws2812_PORTREG PORTF - #define ws2812_DDRREG DDRF - #define ws2812_pin PF4 +Please add the following options into your config.h, and set them up according your hardware configuration. These settings are for the `F4` pin by default: + + #define RGB_DI_PIN F4 // The pin your RGB strip is wired to + #define RGBLIGHT_TIMER // Require for fancier stuff (not compatible with audio) #define RGBLED_NUM 14 // Number of LEDs #define RGBLIGHT_HUE_STEP 10 #define RGBLIGHT_SAT_STEP 17 #define RGBLIGHT_VAL_STEP 17 -You'll need to edit `PORTF`, `DDRF`, and `PF4` on the first three lines to the port/pin you have your LED(s) wired to, eg for B3 change things to: - - #define ws2812_PORTREG PORTB - #define ws2812_DDRREG DDRB - #define ws2812_pin PB3 +You'll need to edit `RGB_DI_PIN` to the pin you have your `DI` on your RGB strip wired to. The firmware supports 5 different light effects, and the color (hue, saturation, brightness) can be customized in most effects. To control the underglow, you need to modify your keymap file to assign those functions to some keys/key combinations. For details, please check this keymap. `keyboards/planck/keymaps/yang/keymap.c` -- cgit v1.2.1 From c444f4f702739633b11e548575cdbe8369d0a98b Mon Sep 17 00:00:00 2001 From: Erez Zukerman Date: Fri, 8 Jul 2016 21:40:57 -0400 Subject: Documents tap dance --- readme.md | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) (limited to 'readme.md') diff --git a/readme.md b/readme.md index e874812515..3657d2c15a 100644 --- a/readme.md +++ b/readme.md @@ -353,6 +353,81 @@ void matrix_scan_user(void) { As you can see, you have three function. you can use - `SEQ_ONE_KEY` for single-key sequences (Leader followed by just one key), and `SEQ_TWO_KEYS` and `SEQ_THREE_KEYS` for longer sequences. Each of these accepts one or more keycodes as arguments. This is an important point: You can use keycodes from **any layer on your keyboard**. That layer would need to be active for the leader macro to fire, obviously. +### Tap Dance: A single key can do 3, 5, or 100 different things + +Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. It's one of the nicest community-contributed features in the firmware, conceived and created by [algernon](https://github.com/algernon) in [#451](https://github.com/jackhumbert/qmk_firmware/pull/451). Here's how Algernon describes the feature: + +With this feature one can specify keys that behave differently, based on the amount of times they have been tapped, and when interrupted, they get handled before the interrupter. + +To make it clear how this is different from `ACTION_FUNCTION_TAP`, lets explore a certain setup! We want one key to send `Space` on single tap, but `Enter` on double-tap. + +With `ACTION_FUNCTION_TAP`, it is quite a rain-dance to set this up, and has the problem that when the sequence is interrupted, the interrupting key will be send first. Thus, `SPC a` will result in `a SPC` being sent, if they are typed within `TAPPING_TERM`. With the tap dance feature, that'll come out as `SPC a`, correctly. + +The implementation hooks into two parts of the system, to achieve this: into `process_record_quantum()`, and the matrix scan. We need the latter to be able to time out a tap sequence even when a key is not being pressed, so `SPC` alone will time out and register after `TAPPING_TERM` time. + +But lets start with how to use it, first! + +First, you will need `TAP_DANCE_ENABLE=yes` in your `Makefile`, because the feature is disabled by default. This adds a little less than 1k to the firmware size. Next, you will want to define some tap-dance keys, which is easiest to do with the `TD()` macro, that - similar to `F()`, takes a number, which will later be used as an index into the `tap_dance_actions` array. + +This array specifies what actions shall be taken when a tap-dance key is in action. Currently, there are two possible options: + +* `ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: Sends the `kc1` keycode when tapped once, `kc2` otherwise. +* `ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the current state of the tap-dance action. + +The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise. + +And that's the bulk of it! + +Do note, however, that this implementation does have some consequences: keys do not register until either they reach the tapping ceiling, or they time out. This means that if you hold the key, nothing happens, no repeat, no nothing. It is possible to detect held state, and register an action then too, but that's not implemented yet. Keys also unregister immediately after being registered, so you can't even hold the second tap. This is intentional, to be consistent. + +And now, on to the explanation of how it works! + +The main entry point is `process_tap_dance()`, called from `process_record_quantum()`, which is run for every keypress, and our handler gets to run early. This function checks whether the key pressed is a tap-dance key. If it is not, and a tap-dance was in action, we handle that first, and enqueue the newly pressed key. If it is a tap-dance key, then we check if it is the same as the already active one (if there's one active, that is). If it is not, we fire off the old one first, then register the new one. If it was the same, we increment the counter and the timer. + +This means that you have `TAPPING_TERM` time to tap the key again, you do not have to input all the taps within that timeframe. This allows for longer tap counts, with minimal impact on responsiveness. + +Our next stop is `matrix_scan_tap_dance()`. This handles the timeout of tap-dance keys. + +For the sake of flexibility, tap-dance actions can be either a pair of keycodes, or a user function. The latter allows one to handle higher tap counts, or do extra things, like blink the LEDs, fiddle with the backlighting, and so on. This is accomplished by using an union, and some clever macros. + +In the end, let's see a full example! + +```c +enum { + CT_SE = 0, + CT_CLN, + CT_EGG +}; + +/* Have the above three on the keymap, TD(CT_SE), etc... */ + +void dance_cln (qk_tap_dance_state_t *state) { + if (state->count == 1) { + register_code (KC_RSFT); + register_code (KC_SCLN); + unregister_code (KC_SCLN); + unregister_code (KC_RSFT); + } else { + register_code (KC_SCLN); + unregister_code (KC_SCLN); + reset_tap_dance (state); + } +} + +void dance_egg (qk_tap_dance_state_t *state) { + if (state->count >= 100) { + SEND_STRING ("Safety dance!"); + reset_tap_dance (state); + } +} + +const qk_tap_dance_action_t tap_dance_actions[] = { + [CT_SE] = ACTION_TAP_DANCE_DOUBLE (KC_SPC, KC_ENT) + ,[CT_CLN] = ACTION_TAP_DANCE_FN (dance_cln) + ,[CT_EGG] = ACTION_TAP_DANCE_FN (dance_egg) +}; +``` + ### Temporarily setting the default layer `DF(layer)` - sets default layer to *layer*. The default layer is the one at the "bottom" of the layer stack - the ultimate fallback layer. This currently does not persist over power loss. When you plug the keyboard back in, layer 0 will always be the default. It is theoretically possible to work around that, but that's not what `DF` does. -- cgit v1.2.1 From c7728780dee32d3f5e63e13ffad44600492e45d6 Mon Sep 17 00:00:00 2001 From: Fred Sundvik Date: Sun, 10 Jul 2016 20:00:04 +0300 Subject: Remove out of place documentation, caused by ChibiOS merge --- readme.md | 3 --- 1 file changed, 3 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index e874812515..f7b43d64f9 100644 --- a/readme.md +++ b/readme.md @@ -24,9 +24,6 @@ The project also includes community support for [lots of other keyboards](/keybo QMK is developed and maintained by Jack Humbert of OLKB with contributions from the community, and of course, [Hasu](https://github.com/tmk). This repo used to be a fork of [TMK](https://github.com/tmk/tmk_keyboard), and we are incredibly grateful for his founding contributions to the firmware. We've had to break the fork due to purely technical reasons - it simply became too different over time, and we've had to start refactoring some of the basic bits and pieces. We are huge fans of TMK and Hasu :) This documentation is edited and maintained by Erez Zukerman of ErgoDox EZ. If you spot any typos or inaccuracies, please [open an issue](https://github.com/jackhumbert/qmk_firmware/issues/new). -#### 2016/02/10 -core: flabbergast's Chibios protocol was merged from (@72b1668). See [tmk_core/protocol/chibios/README.md](tmk_core/protocol/chibios/README.md). Chibios protocol supports Cortex-M such as STM32 and Kinetis. - The OLKB product firmwares are maintained by [Jack Humbert](https://github.com/jackhumbert), the Ergodox EZ by [Erez Zukerman](https://github.com/ezuk), and the Clueboard by [Zach White](https://github.com/skullydazed). -- cgit v1.2.1 From b12fe6abb25db1feca6a7649097a8d1cb67a063f Mon Sep 17 00:00:00 2001 From: Smilliam Date: Sun, 10 Jul 2016 19:04:01 -0700 Subject: Made rollover behavior for space cadet optional --- readme.md | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'readme.md') diff --git a/readme.md b/readme.md index c24d951d8d..cc36a34ffa 100644 --- a/readme.md +++ b/readme.md @@ -309,6 +309,12 @@ It's defaulted to work on US keyboards, but if your layout uses different keys f #define LSPO_KEY KC_9 #define RSPC_KEY KC_0 +You can also choose between different rollover behaviors of the shift keys by defining: + + #define DISABLE_SPACE_CADET_ROLLOVER + +in your `config.h`. Disabling rollover allows you to use the opposite shift key to cancel the space cadet state in the event of an erroneous press instead of emitting a pair of parentheses when the keys are released. + The only other thing you're going to want to do is create a `Makefile` in your keymap directory and set the following: ``` -- cgit v1.2.1 From 0446263935e418537966bc64bfd1c1cdb5206583 Mon Sep 17 00:00:00 2001 From: Erik Dasque Date: Fri, 15 Jul 2016 12:55:40 -0400 Subject: Adding Docker build system & documentation --- readme.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'readme.md') diff --git a/readme.md b/readme.md index e0dcd56088..7a970eea02 100644 --- a/readme.md +++ b/readme.md @@ -75,6 +75,25 @@ Debian/Ubuntu example: sudo apt-get update sudo apt-get install gcc-avr avr-libc dfu-programmer +### Docker + +If this is a bit complex for you, Docker might be the turn-key solution you need. After installing [Docker](https://www.docker.com/products/docker), run the following commands at the root of the QMK folder: + +```bash +# You only need to run this once, it'll take a little while + +docker build -t qmk . + +# and you'll run this every time you want to build a keymap +# modify the keymap and keyboard assigment to compile what you want +# defaults are ergodox_ez/default + +docker run -e keymap=gwen -e keyboard=ergodox_ez --rm -v $('pwd'):/qmk:rw qmk + +``` + +This will compile the targetted keyboard/keymap and leave it in your QMK directory for you to flash. + ### Vagrant If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [VAGRANT_GUIDE file](VAGRANT_GUIDE.md). -- cgit v1.2.1 From aa2a79bbfa5e5134fc83daf5732ca4774edf2dc2 Mon Sep 17 00:00:00 2001 From: Erik Dasque Date: Fri, 15 Jul 2016 13:26:34 -0400 Subject: Further simplyfying the docker usage We'll be able to change the image user name if we set up the initial repo to trigger Docker images rebuilds on hub.docker.com --- readme.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index 7a970eea02..ecad173fa0 100644 --- a/readme.md +++ b/readme.md @@ -77,18 +77,14 @@ Debian/Ubuntu example: ### Docker -If this is a bit complex for you, Docker might be the turn-key solution you need. After installing [Docker](https://www.docker.com/products/docker), run the following commands at the root of the QMK folder: +If this is a bit complex for you, Docker might be the turn-key solution you need. After installing [Docker](https://www.docker.com/products/docker), run the following command at the root of the QMK folder to build a keyboard/keymap: ```bash -# You only need to run this once, it'll take a little while - -docker build -t qmk . - -# and you'll run this every time you want to build a keymap +# You'll run this every time you want to build a keymap # modify the keymap and keyboard assigment to compile what you want # defaults are ergodox_ez/default -docker run -e keymap=gwen -e keyboard=ergodox_ez --rm -v $('pwd'):/qmk:rw qmk +docker run -e keymap=gwen -e keyboard=ergodox_ez --rm -v $('pwd'):/qmk:rw edasque/qmk_firmware ``` -- cgit v1.2.1 From dddaebfa9829ef48f93f2be7119b9790271f8892 Mon Sep 17 00:00:00 2001 From: Seth Chandler Date: Sat, 16 Jul 2016 23:41:20 -0400 Subject: update readme images --- readme.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index e0dcd56088..07280c2b40 100644 --- a/readme.md +++ b/readme.md @@ -774,7 +774,7 @@ AutoHotkey inserts the Text right of `Send, ` when this combination is pressed. ## RGB Under Glow Mod -![Planck with RGB Underglow](https://raw.githubusercontent.com/yangliu/qmk_firmware/planck-rgb/keyboards/planck/keymaps/yang/planck-with-rgb-underglow.jpg) +![Planck with RGB Underglow](https://raw.githubusercontent.com/jackhumbert/qmk_firmware/master/keyboards/planck/keymaps/yang/planck-with-rgb-underglow.jpg) Here is a quick demo on Youtube (with NPKC KC60) (https://www.youtube.com/watch?v=VKrpPAHlisY). @@ -799,7 +799,7 @@ The firmware supports 5 different light effects, and the color (hue, saturation, ### WS2812 Wiring -![WS2812 Wiring](https://raw.githubusercontent.com/yangliu/qmk_firmware/planck-rgb/keyboards/planck/keymaps/yang/WS2812-wiring.jpg) +![WS2812 Wiring](https://raw.githubusercontent.com/jackhumbert/qmk_firmware/master/keyboards/planck/keymaps/yang/WS2812-wiring.jpg) Please note the USB port can only supply a limited amount of power to the keyboard (500mA by standard, however, modern computer and most usb hubs can provide 700+mA.). According to the data of NeoPixel from Adafruit, 30 WS2812 LEDs require a 5V 1A power supply, LEDs used in this mod should not more than 20. -- cgit v1.2.1 From a95ab371627073a85ae420118ac7d1d55a096583 Mon Sep 17 00:00:00 2001 From: Seth Chandler Date: Sun, 17 Jul 2016 03:24:36 -0400 Subject: update link to Vagrant docfile --- readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index 07280c2b40..a8ed51b818 100644 --- a/readme.md +++ b/readme.md @@ -76,7 +76,7 @@ Debian/Ubuntu example: sudo apt-get install gcc-avr avr-libc dfu-programmer ### Vagrant -If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [VAGRANT_GUIDE file](VAGRANT_GUIDE.md). +If you have any problems building the firmware, you can try using a tool called Vagrant. It will set up a virtual computer with a known configuration that's ready-to-go for firmware building. OLKB does NOT host the files for this virtual computer. Details on how to set up Vagrant are in the [VAGRANT_GUIDE file](doc/VAGRANT_GUIDE.md). ## Verify Your Installation 1. If you haven't already, obtain this repository ([https://github.com/jackhumbert/qmk_firmware](https://github.com/jackhumbert/qmk_firmware)). You can either download it as a zip file and extract it, or clone it using the command line tool git or the Github Desktop application. -- cgit v1.2.1 From 45414fed7b4a61453aad6bbfd1d761177c16bf65 Mon Sep 17 00:00:00 2001 From: Seth Chandler Date: Sun, 17 Jul 2016 03:28:48 -0400 Subject: update tmk link --- readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index a8ed51b818..a179d7aa21 100644 --- a/readme.md +++ b/readme.md @@ -35,7 +35,7 @@ This is not a tiny project. While this is the main readme, there are many other * The list of possible keycodes you can use in your keymap is actually spread out in a few different places: * [doc/keycode.txt](doc/keycode.txt) - an explanation of those same keycodes. * [quantum/keymap.h](quantum/keymap.h) - this is where the QMK-specific aliases are all set up. Things like the Hyper and Meh key, the Leader key, and all of the other QMK innovations. These are also explained and documented below, but `keymap.h` is where they're actually defined. -* The [TMK documentation](doc/TMK_readme.md). QMK is based on TMK, and this explains how it works internally. +* The [TMK documentation](doc/TMK_README.md). QMK is based on TMK, and this explains how it works internally. # Getting started -- cgit v1.2.1 From 68b1affbbd9be209c5b7dcbd39f222492be3314d Mon Sep 17 00:00:00 2001 From: Seth Chandler Date: Sun, 17 Jul 2016 03:32:02 -0400 Subject: update audio links --- readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index a179d7aa21..4ccf51f985 100644 --- a/readme.md +++ b/readme.md @@ -732,7 +732,7 @@ float music_scale[][2] = SONG(MUSIC_SCALE_SOUND); float goodbye[][2] = SONG(GOODBYE_SOUND); ``` -Wherein we bind predefined songs (from [audio/song_list.h](/audio/song_list.h)) into named variables. This is one optimization that helps save on memory: These songs only take up memory when you reference them in your keymap, because they're essentially all preprocessor directives. +Wherein we bind predefined songs (from [quantum/audio/song_list.h](/quantum/audio/song_list.h)) into named variables. This is one optimization that helps save on memory: These songs only take up memory when you reference them in your keymap, because they're essentially all preprocessor directives. So now you have something called `tone_plover` for example. How do you make it play the Plover tune, then? If you look further down the keymap, you'll see this: -- cgit v1.2.1 From d40d18ab1ae8a1ef9feb408e43d4b840d37998a8 Mon Sep 17 00:00:00 2001 From: Seth Chandler Date: Sun, 17 Jul 2016 10:37:45 -0400 Subject: don't believe the hex files are posted to qmk.fm --- readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index 4ccf51f985..b55659c7a7 100644 --- a/readme.md +++ b/readme.md @@ -97,7 +97,7 @@ In every keymap folder, the following files are recommended: The `make` command is how you compile the firmware into a .hex file, which can be loaded by a dfu programmer (like dfu-progammer via `make dfu`) or the [Teensy loader](https://www.pjrc.com/teensy/loader.html) (only used with Teensys). You can run `make` from the root (`/`), your keyboard folder (`/keyboards//`), or your keymap folder (`/keyboards//keymaps//`) if you have a `Makefile` there (see the example [here](/doc/keymap_makefile_example.mk)). -By default, this will generate a `_.hex` file in whichever folder you run `make` from. These files are ignored by git, so don't worry about deleting them when committing/creating pull requests. Your .hex file will also be available on qmk.fm/keyboards//keymaps//. +By default, this will generate a `_.hex` file in whichever folder you run `make` from. These files are ignored by git, so don't worry about deleting them when committing/creating pull requests. Below are some definitions that will be useful: -- cgit v1.2.1 From d8a979b6d50fb5a6735ceab02f5d93163609aa68 Mon Sep 17 00:00:00 2001 From: Pavlos Vinieratos Date: Tue, 19 Jul 2016 00:01:11 +0200 Subject: add a bit of documentation --- readme.md | 48 +++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 45 insertions(+), 3 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index e0dcd56088..b5f7f6945d 100644 --- a/readme.md +++ b/readme.md @@ -372,10 +372,11 @@ But lets start with how to use it, first! First, you will need `TAP_DANCE_ENABLE=yes` in your `Makefile`, because the feature is disabled by default. This adds a little less than 1k to the firmware size. Next, you will want to define some tap-dance keys, which is easiest to do with the `TD()` macro, that - similar to `F()`, takes a number, which will later be used as an index into the `tap_dance_actions` array. -This array specifies what actions shall be taken when a tap-dance key is in action. Currently, there are two possible options: +This array specifies what actions shall be taken when a tap-dance key is in action. Currently, there are three possible options: * `ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: Sends the `kc1` keycode when tapped once, `kc2` otherwise. -* `ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the current state of the tap-dance action. +* `ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the final tap count of the tap dance action. +* `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function on when the dance action finishes (like the previous option), and the last function when the tap dance action resets. The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise. @@ -399,7 +400,8 @@ In the end, let's see a full example! enum { CT_SE = 0, CT_CLN, - CT_EGG + CT_EGG, + CT_FLSH, }; /* Have the above three on the keymap, TD(CT_SE), etc... */ @@ -424,10 +426,50 @@ void dance_egg (qk_tap_dance_state_t *state) { } } +// on each tap, light up one led, from right to left +// on the forth tap, turn them off from right to left +void dance_flsh_each(qk_tap_dance_state_t *state) { + switch (state->count) { + case 1: + ergodox_right_led_3_on(); + break; + case 2: + ergodox_right_led_2_on(); + break; + case 3: + ergodox_right_led_1_on(); + break; + case 4: + ergodox_right_led_3_off(); + _delay_ms(50); + ergodox_right_led_2_off(); + _delay_ms(50); + ergodox_right_led_1_off(); + } +} + +// on the fourth tap, set the keyboard on flash state +void dance_flsh_finished(qk_tap_dance_state_t *state) { + if (state->count >= 4) { + reset_keyboard(); + reset_tap_dance(state); + } +} + +// if the flash state didnt happen, then turn off leds, left to right +void dance_flsh_reset(qk_tap_dance_state_t *state) { + ergodox_right_led_1_off(); + _delay_ms(50); + ergodox_right_led_2_off(); + _delay_ms(50); + ergodox_right_led_3_off(); +} + const qk_tap_dance_action_t tap_dance_actions[] = { [CT_SE] = ACTION_TAP_DANCE_DOUBLE (KC_SPC, KC_ENT) ,[CT_CLN] = ACTION_TAP_DANCE_FN (dance_cln) ,[CT_EGG] = ACTION_TAP_DANCE_FN (dance_egg) + ,[CT_FLSH] = ACTION_TAP_DANCE_FN_ADVANCED (dance_flsh_each, dance_flsh_finished, dance_flsh_reset) }; ``` -- cgit v1.2.1 From 6eb21d2680dc6f8e2cb2e2b6fabf41d82e240256 Mon Sep 17 00:00:00 2001 From: Pavlos Vinieratos Date: Tue, 19 Jul 2016 00:07:50 +0200 Subject: add some debugging doc, after i found out how to print debug messages --- readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index e0dcd56088..2374bf5541 100644 --- a/readme.md +++ b/readme.md @@ -152,7 +152,7 @@ This allows you to use the system and audio control key codes. `CONSOLE_ENABLE` -TODO +This allows you to print messages that can be read using `hid_listen`. Add this to your `Makefile`, and set it to `yes`. Then put `println`, `printf`, etc. in your keymap or anywhere in the `qmk` source. Finally, open `hid_listen` and enjoy looking at your printed messages. `COMMAND_ENABLE` -- cgit v1.2.1 From 2e815ad9a2f4e36d6c11dbe0475d1fb1e1fa9d18 Mon Sep 17 00:00:00 2001 From: Pavlos Vinieratos Date: Tue, 19 Jul 2016 17:34:23 +0200 Subject: add link to hid_listen --- readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index 2374bf5541..8e005155b9 100644 --- a/readme.md +++ b/readme.md @@ -152,7 +152,7 @@ This allows you to use the system and audio control key codes. `CONSOLE_ENABLE` -This allows you to print messages that can be read using `hid_listen`. Add this to your `Makefile`, and set it to `yes`. Then put `println`, `printf`, etc. in your keymap or anywhere in the `qmk` source. Finally, open `hid_listen` and enjoy looking at your printed messages. +This allows you to print messages that can be read using [`hid_listen`](https://www.pjrc.com/teensy/hid_listen.html). Add this to your `Makefile`, and set it to `yes`. Then put `println`, `printf`, etc. in your keymap or anywhere in the `qmk` source. Finally, open `hid_listen` and enjoy looking at your printed messages. `COMMAND_ENABLE` -- cgit v1.2.1 From fca34e2ad602b943a50c279d3b6e3a30c24dbc25 Mon Sep 17 00:00:00 2001 From: Gergely Nagy Date: Wed, 20 Jul 2016 11:54:25 +0200 Subject: readme.md: algernon is strictly lowercase Signed-off-by: Gergely Nagy --- readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index ed3da43bd0..7347412308 100644 --- a/readme.md +++ b/readme.md @@ -373,7 +373,7 @@ As you can see, you have three function. you can use - `SEQ_ONE_KEY` for single- ### Tap Dance: A single key can do 3, 5, or 100 different things -Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. It's one of the nicest community-contributed features in the firmware, conceived and created by [algernon](https://github.com/algernon) in [#451](https://github.com/jackhumbert/qmk_firmware/pull/451). Here's how Algernon describes the feature: +Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. It's one of the nicest community-contributed features in the firmware, conceived and created by [algernon](https://github.com/algernon) in [#451](https://github.com/jackhumbert/qmk_firmware/pull/451). Here's how algernon describes the feature: With this feature one can specify keys that behave differently, based on the amount of times they have been tapped, and when interrupted, they get handled before the interrupter. -- cgit v1.2.1 From 13385f5691f1a28b1349577ad58d0816f026ee05 Mon Sep 17 00:00:00 2001 From: Gergely Nagy Date: Wed, 20 Jul 2016 12:04:14 +0200 Subject: readme.md: Update the tap dance docs Signed-off-by: Gergely Nagy --- readme.md | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index 7347412308..4d6250f8ea 100644 --- a/readme.md +++ b/readme.md @@ -389,7 +389,7 @@ First, you will need `TAP_DANCE_ENABLE=yes` in your `Makefile`, because the feat This array specifies what actions shall be taken when a tap-dance key is in action. Currently, there are three possible options: -* `ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: Sends the `kc1` keycode when tapped once, `kc2` otherwise. +* `ACTION_TAP_DANCE_DOUBLE(kc1, kc2)`: Sends the `kc1` keycode when tapped once, `kc2` otherwise. When the key is held, the appropriate keycode is registered: `kc1` when pressed and held, `kc2` when tapped once, then pressed and held. * `ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the final tap count of the tap dance action. * `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function on when the dance action finishes (like the previous option), and the last function when the tap dance action resets. @@ -397,8 +397,6 @@ The first option is enough for a lot of cases, that just want dual roles. For ex And that's the bulk of it! -Do note, however, that this implementation does have some consequences: keys do not register until either they reach the tapping ceiling, or they time out. This means that if you hold the key, nothing happens, no repeat, no nothing. It is possible to detect held state, and register an action then too, but that's not implemented yet. Keys also unregister immediately after being registered, so you can't even hold the second tap. This is intentional, to be consistent. - And now, on to the explanation of how it works! The main entry point is `process_tap_dance()`, called from `process_record_quantum()`, which is run for every keypress, and our handler gets to run early. This function checks whether the key pressed is a tap-dance key. If it is not, and a tap-dance was in action, we handle that first, and enqueue the newly pressed key. If it is a tap-dance key, then we check if it is the same as the already active one (if there's one active, that is). If it is not, we fire off the old one first, then register the new one. If it was the same, we increment the counter and the timer. @@ -421,20 +419,25 @@ enum { /* Have the above three on the keymap, TD(CT_SE), etc... */ -void dance_cln (qk_tap_dance_state_t *state) { +void dance_cln_finished (qk_tap_dance_state_t *state, void *user_data) { if (state->count == 1) { register_code (KC_RSFT); register_code (KC_SCLN); - unregister_code (KC_SCLN); - unregister_code (KC_RSFT); } else { register_code (KC_SCLN); + } +} + +void dance_cln_reset (qk_tap_dance_state_t *state, void *user_data) { + if (state->count == 1) { + unregister_code (KC_RSFT); + unregister_code (KC_SCLN); + } else { unregister_code (KC_SCLN); - reset_tap_dance (state); } } -void dance_egg (qk_tap_dance_state_t *state) { +void dance_egg (qk_tap_dance_state_t *state, void *user_data) { if (state->count >= 100) { SEND_STRING ("Safety dance!"); reset_tap_dance (state); @@ -443,7 +446,7 @@ void dance_egg (qk_tap_dance_state_t *state) { // on each tap, light up one led, from right to left // on the forth tap, turn them off from right to left -void dance_flsh_each(qk_tap_dance_state_t *state) { +void dance_flsh_each(qk_tap_dance_state_t *state, void *user_data) { switch (state->count) { case 1: ergodox_right_led_3_on(); @@ -464,7 +467,7 @@ void dance_flsh_each(qk_tap_dance_state_t *state) { } // on the fourth tap, set the keyboard on flash state -void dance_flsh_finished(qk_tap_dance_state_t *state) { +void dance_flsh_finished(qk_tap_dance_state_t *state, void *user_data) { if (state->count >= 4) { reset_keyboard(); reset_tap_dance(state); @@ -472,7 +475,7 @@ void dance_flsh_finished(qk_tap_dance_state_t *state) { } // if the flash state didnt happen, then turn off leds, left to right -void dance_flsh_reset(qk_tap_dance_state_t *state) { +void dance_flsh_reset(qk_tap_dance_state_t *state, void *user_data) { ergodox_right_led_1_off(); _delay_ms(50); ergodox_right_led_2_off(); @@ -482,7 +485,7 @@ void dance_flsh_reset(qk_tap_dance_state_t *state) { const qk_tap_dance_action_t tap_dance_actions[] = { [CT_SE] = ACTION_TAP_DANCE_DOUBLE (KC_SPC, KC_ENT) - ,[CT_CLN] = ACTION_TAP_DANCE_FN (dance_cln) + ,[CT_CLN] = ACTION_TAP_DANCE_FN_ADVANCED (NULL, dance_cln_finished, dance_cln_reset) ,[CT_EGG] = ACTION_TAP_DANCE_FN (dance_egg) ,[CT_FLSH] = ACTION_TAP_DANCE_FN_ADVANCED (dance_flsh_each, dance_flsh_finished, dance_flsh_reset) }; -- cgit v1.2.1 From a4034b75c0f8ae9fd2e1001888fe07983f329597 Mon Sep 17 00:00:00 2001 From: Don Smith Date: Sun, 24 Jul 2016 19:18:22 +1200 Subject: Added LEADER_EXTERNS() call. This seems to be needed in most cases. --- readme.md | 2 ++ 1 file changed, 2 insertions(+) (limited to 'readme.md') diff --git a/readme.md b/readme.md index ed3da43bd0..1a0e256b3d 100644 --- a/readme.md +++ b/readme.md @@ -346,6 +346,8 @@ That's what `KC_LEAD` does. Here's an example: 3. Within your `matrix_scan_user` function, do something like this: ``` +LEADER_EXTERNS(); + void matrix_scan_user(void) { LEADER_DICTIONARY() { leading = false; -- cgit v1.2.1 From 812007a24168f895105330d3959909525c51636b Mon Sep 17 00:00:00 2001 From: Robert Dale Date: Sun, 24 Jul 2016 10:19:40 -0400 Subject: added music recording/playing doc --- readme.md | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'readme.md') diff --git a/readme.md b/readme.md index ed3da43bd0..9a4c314dca 100644 --- a/readme.md +++ b/readme.md @@ -801,6 +801,17 @@ This is inside one of the macros. So when that macro executes, your keyboard pla "Rest style" in the method signature above (the last parameter) specifies if there's a rest (a moment of silence) between the notes. + +## Recording And Playing back Music +* ```Music On``` - Turn music mode on. The default mapping is ```Lower+Upper+C``` +* ```LCTL``` - start a recording +* play some tones +* ```LALT``` - stop recording, stop playing +* ```LGUI``` - play recording +* ```LALT``` - stop playing +* ```Music Off``` - Turn music mode off. The default mapping is ```Lower+Upper+V``` + + ## MIDI functionalty This is still a WIP, but check out `quantum/keymap_midi.c` to see what's happening. Enable from the Makefile. -- cgit v1.2.1 From 7e69de061ae63e356b31b656f18a205199f556ed Mon Sep 17 00:00:00 2001 From: Michael Klos Date: Tue, 26 Jul 2016 18:41:35 -0400 Subject: Added Tap Dance Example Added (simple) Tap Dance example implementation steps. --- readme.md | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index affee1b62e..3854f4b8d8 100644 --- a/readme.md +++ b/readme.md @@ -409,7 +409,32 @@ Our next stop is `matrix_scan_tap_dance()`. This handles the timeout of tap-danc For the sake of flexibility, tap-dance actions can be either a pair of keycodes, or a user function. The latter allows one to handle higher tap counts, or do extra things, like blink the LEDs, fiddle with the backlighting, and so on. This is accomplished by using an union, and some clever macros. -In the end, let's see a full example! +#### Examples + +Here's a simple example for a single definition: + +1. In your `makefile`, add `TAP_DANCE_ENABLE = yes` +2. In your `config.h` (which you can copy from `qmk_firmware/keyboards/planck/config.h` to your keymap directory), add `#define TAPPING_TERM 200` +3. In your `keymap.c` file, define the variables and definitions, then add to your keymap: + +```c +//Tap Dance Declarations +enum { + TD_ESC_CAPS = 0 +}; + +//Tap Dance Definitions +const qk_tap_dance_action_t tap_dance_actions[] = { + //Tap once for Esc, twice for Caps Lock + [TD_ESC_CAPS] = ACTION_TAP_DANCE_DOUBLE(KC_ESC, KC_CAPS) +// Other declarations would go here, separated by commas, if you have them +}; + +//In Layer declaration, add tap dance item in place of a key code +TD(TD_ESC_CAPS) +``` + +Here's a more complex example involving custom actions: ```c enum { -- cgit v1.2.1 From e8f70389592421c7d7d4dbca2d5851e24a29bec9 Mon Sep 17 00:00:00 2001 From: Matthias Date: Fri, 29 Jul 2016 10:02:59 +0900 Subject: Fixed a typo Fixed a typo in line 738 'void martix_init' to 'void matrix_init' --- readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index 3854f4b8d8..f717f8e4c8 100644 --- a/readme.md +++ b/readme.md @@ -735,7 +735,7 @@ Enable the backlight from the Makefile. All of these functions are available in the `*_kb()` or `*_user()` variety. `kb` ones should only be used in the `/.c` file, and `user` ones should only be used in the `keymap.c`. The keyboard ones call the user ones - it's necessary to keep these calls to allow the keymap functions to work correctly. -## `void martix_init_*(void)` +## `void matrix_init_*(void)` This function gets called when the matrix is initiated, and can contain start-up code for your keyboard/keymap. -- cgit v1.2.1 From 7d55951050016f2cd9af80c7129bab3200abc810 Mon Sep 17 00:00:00 2001 From: Fred Sundvik Date: Fri, 29 Jul 2016 22:38:06 +0300 Subject: Fix the quick aliases documentation section Also move all keyboard customization documentation under the "Going Beyond the keycodes" heading. --- readme.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index f717f8e4c8..45af1b0c3a 100644 --- a/readme.md +++ b/readme.md @@ -229,10 +229,18 @@ For a value of `4` for this imaginary setting. So we `undef` it first, then `def You can then override any settings, rather than having to copy and paste the whole thing. -## Going beyond the keycodes +# Going beyond the keycodes Aside from the [basic keycodes](doc/keycode.txt), your keymap can include shortcuts to common operations. +## Quick aliases to common actions + +Your keymap can include shortcuts to common operations (called "function actions" in tmk). + +These functions work the same way that their `ACTION_*` functions do - they're just quick aliases. To dig into all of the tmk `ACTION_*` functions, please see the [TMK documentation](https://github.com/jackhumbert/qmk_firmware/blob/master/doc/keymap.md#2-action). + +Instead of using `FNx` when defining `ACTION_*` functions, you can use `F(x)` - the benefit here is being able to use more than 32 function actions (up to 4096), if you happen to need them. + ### Switching and toggling layers `MO(layer)` - momentary switch to *layer*. As soon as you let go of the key, the layer is deactivated and you pop back out to the previous layer. When you apply this to a key, that same key must be set as `KC_TRNS` on the destination layer. Otherwise, you won't make it back to the original layer when you release the key (and you'll get a keycode sent). You can only switch to layers *above* your current layer. If you're on layer 0 and you use `MO(1)`, that will switch to layer 1 just fine. But if you include `MO(3)` on layer 5, that won't do anything for you -- because layer 3 is lower than layer 5 on the stack. @@ -310,7 +318,7 @@ We've added shortcuts to make common modifier/tap (mod-tap) mappings more compac * `LCAG_T(kc)` - is CtrlAltGui when held and *kc* when tapped * `MEH_T(kc)` - is like Hyper, but not as cool -- does not include the Cmd/Win key, so just sends Alt+Ctrl+Shift. -### Space Cadet Shift: The future, built in +## Space Cadet Shift: The future, built in Steve Losh [described](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/) the Space Cadet Shift quite well. Essentially, you hit the left Shift on its own, and you get an opening parenthesis; hit the right Shift on its own, and you get the closing one. When hit with other keys, the Shift key keeps working as it always does. Yes, it's as cool as it sounds. @@ -335,7 +343,7 @@ COMMAND_ENABLE = no # Commands for debug and configuration This is just to keep the keyboard from going into command mode when you hold both Shift keys at the same time. -### The Leader key: A new kind of modifier +## The Leader key: A new kind of modifier If you've ever used Vim, you know what a Leader key is. If not, you're about to discover a wonderful concept. :) Instead of hitting Alt+Shift+W for example (holding down three keys at the same time), what if you could hit a _sequence_ of keys instead? So you'd hit our special modifier (the Leader key), followed by W and then C (just a rapid succession of keys), and something would happen. @@ -373,7 +381,7 @@ void matrix_scan_user(void) { As you can see, you have three function. you can use - `SEQ_ONE_KEY` for single-key sequences (Leader followed by just one key), and `SEQ_TWO_KEYS` and `SEQ_THREE_KEYS` for longer sequences. Each of these accepts one or more keycodes as arguments. This is an important point: You can use keycodes from **any layer on your keyboard**. That layer would need to be active for the leader macro to fire, obviously. -### Tap Dance: A single key can do 3, 5, or 100 different things +## Tap Dance: A single key can do 3, 5, or 100 different things Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a colon. Hit it three times, and your keyboard's LEDs do a wild dance. That's just one example of what Tap Dance can do. It's one of the nicest community-contributed features in the firmware, conceived and created by [algernon](https://github.com/algernon) in [#451](https://github.com/jackhumbert/qmk_firmware/pull/451). Here's how algernon describes the feature: @@ -409,7 +417,7 @@ Our next stop is `matrix_scan_tap_dance()`. This handles the timeout of tap-danc For the sake of flexibility, tap-dance actions can be either a pair of keycodes, or a user function. The latter allows one to handle higher tap counts, or do extra things, like blink the LEDs, fiddle with the backlighting, and so on. This is accomplished by using an union, and some clever macros. -#### Examples +### Examples Here's a simple example for a single definition: @@ -518,11 +526,11 @@ const qk_tap_dance_action_t tap_dance_actions[] = { }; ``` -### Temporarily setting the default layer +## Temporarily setting the default layer `DF(layer)` - sets default layer to *layer*. The default layer is the one at the "bottom" of the layer stack - the ultimate fallback layer. This currently does not persist over power loss. When you plug the keyboard back in, layer 0 will always be the default. It is theoretically possible to work around that, but that's not what `DF` does. -### Prevent stuck modifiers +## Prevent stuck modifiers Consider the following scenario: @@ -543,12 +551,6 @@ This option uses 5 bytes of memory per every 8 keys on the keyboard rounded up (5 bits per key). For example on Planck (48 keys) it uses (48/8)\*5 = 30 bytes. -### Remember: These are just aliases - -These functions work the same way that their `ACTION_*` functions do - they're just quick aliases. To dig into all of the tmk ACTION_* functions, please see the [TMK documentation](https://github.com/jackhumbert/qmk_firmware/blob/master/doc/keymap.md#2-action). - -Instead of using `FNx` when defining `ACTION_*` functions, you can use `F(x)` - the benefit here is being able to use more than 32 function actions (up to 4096), if you happen to need them. - ## Macro shortcuts: Send a whole string when pressing just one key Instead of using the `ACTION_MACRO` function, you can simply use `M(n)` to access macro *n* - *n* will get passed into the `action_get_macro` as the `id`, and you can use a switch statement to trigger it. This gets called on the keydown and keyup, so you'll need to use an if statement testing `record->event.pressed` (see keymap_default.c). -- cgit v1.2.1 From 8a9bf1f1653a5029ffd8f1e1171cd0b16bc2bc71 Mon Sep 17 00:00:00 2001 From: Gergely Nagy Date: Sat, 30 Jul 2016 08:37:30 +0200 Subject: Update some obsolete references Some links were still pointing to `/keyboards/ergodox_ez`, while the directory is `/keyboards/erdogox` now. Not all references have been updated, and some of the text here and there may need updating to mention the ErgoDox Infinity too, but that's out of the scope for this quick fix. Signed-off-by: Gergely Nagy --- readme.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index 45af1b0c3a..c3d866f36b 100644 --- a/readme.md +++ b/readme.md @@ -82,9 +82,9 @@ If this is a bit complex for you, Docker might be the turn-key solution you need ```bash # You'll run this every time you want to build a keymap # modify the keymap and keyboard assigment to compile what you want -# defaults are ergodox_ez/default +# defaults are ergodox/default -docker run -e keymap=gwen -e keyboard=ergodox_ez --rm -v $('pwd'):/qmk:rw edasque/qmk_firmware +docker run -e keymap=gwen -e keyboard=ergodox --rm -v $('pwd'):/qmk:rw edasque/qmk_firmware ``` -- cgit v1.2.1 From 87a1a095d0b46cb39d3ac627d94650b4e52da19b Mon Sep 17 00:00:00 2001 From: Fred Sundvik Date: Sun, 31 Jul 2016 14:18:00 +0300 Subject: Fix the readme for the removed quick target --- readme.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index c3d866f36b..57629f8be2 100644 --- a/readme.md +++ b/readme.md @@ -122,17 +122,16 @@ Below are some definitions that will be useful: Below is a list of the useful `make` commands in QMK: -* `make` - cleans automatically and builds your keyboard and keymap depending on which folder you're in. This defaults to the "default" layout (unless in a keymap folder), and Planck keyboard in the root folder +* `make` - builds your keyboard and keymap depending on which folder you're in. This defaults to the "default" layout (unless in a keymap folder), and Planck keyboard in the root folder * `make keyboard=` - specifies the keyboard (only to be used in root) * `make keymap=` - specifies the keymap (only to be used in root and keyboard folder - not needed when in keymap folder) -* `make quick` - skips the clean step (cannot be used immediately after modifying config.h or Makefiles) +* `make clean` - cleans the `.build` folder, ensuring that everything is re-built * `make dfu` - (requires dfu-programmer) builds and flashes the keymap to your keyboard once placed in reset/dfu mode (button or press `KC_RESET`). This does not work for Teensy-based keyboards like the ErgoDox EZ. * `keyboard=` and `keymap=` are compatible with this * `make all-keyboards` - builds all keymaps for all keyboards and outputs status of each (use in root) * `make all-keyboards-default` - builds all default keymaps for all keyboards and outputs status of each (use in root) * `make all-keymaps [keyboard=]` - builds all of the keymaps for whatever keyboard folder you're in, or specified by `` -* `make all-keyboards-quick`, `make all-keyboards-default-quick` and `make all-keymaps-quick [keyboard=]` - like the normal "make-all-*" commands, but they skip the clean steps - +* `make all-keyboards-*`, `make all-keyboards-default-*` and `make all-keymaps-* [keyboard=]` - like the normal "make-all-*" commands, but the last string aftter the `-` (for example clean) is passed to the keyboard make command. Other, less useful functionality: * `make COLOR=false` - turns off color output -- cgit v1.2.1 From 477f1ad0c8e360880d2b2db9abe4b000940a56bf Mon Sep 17 00:00:00 2001 From: Aaron Patterson Date: Fri, 12 Aug 2016 19:07:44 -0700 Subject: fix link to ErgoDox EZ This just fixes the readme link to the ErgoDox EZ directory --- readme.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index 57629f8be2..e2221e7496 100644 --- a/readme.md +++ b/readme.md @@ -13,7 +13,7 @@ For an easy-to-read version of this document and the repository, check out [http * [Planck](/keyboards/planck/) * [Preonic](/keyboards/preonic/) * [Atomic](/keyboards/atomic/) -* [ErgoDox EZ](/keyboards/ergodox_ez/) +* [ErgoDox EZ](/keyboards/ergodox/ez/) * [Clueboard](/keyboards/clueboard/) * [Cluepad](/keyboards/cluepad/) @@ -31,7 +31,7 @@ The OLKB product firmwares are maintained by [Jack Humbert](https://github.com/j This is not a tiny project. While this is the main readme, there are many other files you might want to consult. Here are some points of interest: -* The readme for your own keyboard: This is found under `keyboards//`. So for the ErgoDox EZ, it's [here](keyboards/ergodox_ez/); for the Planck, it's [here](keyboards/planck/) and so on. +* The readme for your own keyboard: This is found under `keyboards//`. So for the ErgoDox EZ, it's [here](keyboards/ergodox/ez/); for the Planck, it's [here](keyboards/planck/) and so on. * The list of possible keycodes you can use in your keymap is actually spread out in a few different places: * [doc/keycode.txt](doc/keycode.txt) - an explanation of those same keycodes. * [quantum/keymap.h](quantum/keymap.h) - this is where the QMK-specific aliases are all set up. Things like the Hyper and Meh key, the Leader key, and all of the other QMK innovations. These are also explained and documented below, but `keymap.h` is where they're actually defined. -- cgit v1.2.1 From 29f64d7a93d941167c6c6e95f893ab84586b2205 Mon Sep 17 00:00:00 2001 From: Gergely Nagy Date: Wed, 17 Aug 2016 13:04:50 +0200 Subject: tap-dance: Major rework, to make it more reliable This reworks how the tap-dance feature works: instead of one global state, we have a state for each tap-dance key, so we can cancel them when another tap-dance key is in flight. This fixes #527. Since we have a state for each key, we can avoid situation where a keyup would mess with our global state. This fixes #563. And while here, we also make sure to fire events only once, and this fixes #574. There is one breaking change, though: tap-dance debugging support was removed, because dumping the whole state would increase the firmware size too much. Any keymap that made use of this, will have to be updated (but there's no such keymap in the repo). Also, there's a nice trick used in this rework: we need to iterate through tap_dance_actions in a few places, to check for timeouts, and so on. For this, we'd need to know the size of the array. We can't discover that at compile-time, because tap-dance gets compiled separately. We'd like to avoid having to terminate the list with a sentinel value, because that would require updates to all keymaps that use the feature. So, we keep track of the highest tap-dance code seen so far, and iterate until that index. Signed-off-by: Gergely Nagy --- readme.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index e2221e7496..8c07a5d1fa 100644 --- a/readme.md +++ b/readme.md @@ -431,7 +431,7 @@ enum { }; //Tap Dance Definitions -const qk_tap_dance_action_t tap_dance_actions[] = { +qk_tap_dance_action_t tap_dance_actions[] = { //Tap once for Esc, twice for Caps Lock [TD_ESC_CAPS] = ACTION_TAP_DANCE_DOUBLE(KC_ESC, KC_CAPS) // Other declarations would go here, separated by commas, if you have them @@ -517,7 +517,7 @@ void dance_flsh_reset(qk_tap_dance_state_t *state, void *user_data) { ergodox_right_led_3_off(); } -const qk_tap_dance_action_t tap_dance_actions[] = { +qk_tap_dance_action_t tap_dance_actions[] = { [CT_SE] = ACTION_TAP_DANCE_DOUBLE (KC_SPC, KC_ENT) ,[CT_CLN] = ACTION_TAP_DANCE_FN_ADVANCED (NULL, dance_cln_finished, dance_cln_reset) ,[CT_EGG] = ACTION_TAP_DANCE_FN (dance_egg) -- cgit v1.2.1 From 950755edaf766a420376f8d11ac47ab087e7fa99 Mon Sep 17 00:00:00 2001 From: Wojciech Siewierski Date: Thu, 18 Aug 2016 01:40:54 +0200 Subject: Add the dynamic macros documentation to the readme --- readme.md | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) (limited to 'readme.md') diff --git a/readme.md b/readme.md index e2221e7496..5252de5dff 100644 --- a/readme.md +++ b/readme.md @@ -695,6 +695,49 @@ const macro_t *action_get_macro(keyrecord_t *record, uint8_t id, uint8_t opt) And then, to assign this macro to a key on your keyboard layout, you just use `M(0)` on the key you want to press for copy/paste. +## Dynamic macros: record and replay macros in runtime + +In addition to the static macros described above, you may enable the dynamic macros which you may record while writing. They are forgotten as soon as the keyboard is unplugged. Only two such macros may be stored at the same time, with the total length of 128 keypresses. + +To enable them, first add a new element to the `planck_keycodes` enum -- `DYNAMIC_MACRO_RANGE`: + + enum planck_keycodes { + QWERTY = SAFE_RANGE, + COLEMAK, + DVORAK, + PLOVER, + LOWER, + RAISE, + BACKLIT, + EXT_PLV, + DYNAMIC_MACRO_RANGE, + }; + +Afterwards create a new layer called `_DYN`: + + #define _DYN 6 /* almost any other free number should be ok */ + +Below these two modifications include the `dynamic_macro.h` header: + + #include "dynamic_macro.h"` + +Then define the `_DYN` layer with the following keys: `DYN_REC_START1`, `DYN_REC_PLAY1`,`DYN_REC_START2` and `DYN_REC_PLAY2`. It may also contain other keys, it doesn't matter apart from the fact that you won't be able to record these keys in the dynamic macros. + + [_DYN]= { + {_______, DYN_REC_START1, DYN_MACRO_PLAY1, _______, _______, _______, _______, _______, _______, _______, _______, _______}, + {_______, DYN_REC_START2, DYN_MACRO_PLAY2, _______, _______, _______, _______, _______, _______, _______, _______, _______}, + {_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______}, + {_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______} + }, + +Add the following code to the very beginning of your `process_record_user()` function: + + if (!process_record_dynamic_macro(keycode, record)) { + return false; + } + +The usage should be pretty self-explanatory. For the details, please read the comments in the `dynamic_macro.h` header. + ## Additional keycode aliases for software-implemented layouts (Colemak, Dvorak, etc) Everything is assuming you're in Qwerty (in software) by default, but there is built-in support for using a Colemak or Dvorak layout by including this at the top of your keymap: -- cgit v1.2.1 From ea7115534afb23571f11af38c19b4835e1699c7e Mon Sep 17 00:00:00 2001 From: Wojciech Siewierski Date: Fri, 19 Aug 2016 00:17:57 +0200 Subject: Improve the dynamic macro documentation --- readme.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'readme.md') diff --git a/readme.md b/readme.md index 119995a5cb..37f140839d 100644 --- a/readme.md +++ b/readme.md @@ -721,7 +721,7 @@ Below these two modifications include the `dynamic_macro.h` header: #include "dynamic_macro.h"` -Then define the `_DYN` layer with the following keys: `DYN_REC_START1`, `DYN_REC_PLAY1`,`DYN_REC_START2` and `DYN_REC_PLAY2`. It may also contain other keys, it doesn't matter apart from the fact that you won't be able to record these keys in the dynamic macros. +Then define the `_DYN` layer with the following keys: `DYN_REC_START1`, `DYN_MACRO_PLAY1`,`DYN_REC_START2` and `DYN_MACRO_PLAY2`. It may also contain other keys, it doesn't matter apart from the fact that you won't be able to record these keys in the dynamic macros. [_DYN]= { {_______, DYN_REC_START1, DYN_MACRO_PLAY1, _______, _______, _______, _______, _______, _______, _______, _______, _______}, @@ -736,7 +736,11 @@ Add the following code to the very beginning of your `process_record_user()` fun return false; } -The usage should be pretty self-explanatory. For the details, please read the comments in the `dynamic_macro.h` header. +To start recording the macro, press either `DYN_REC_START1` or `DYN_REC_START2`. To finish the recording, press the `_DYN` layer button. The handler awaits specifically for the `MO(_DYN)` keycode as the "stop signal" so please don't use any fancy ways to access this layer, use the regular `MO()` modifier. To replay the macro, press either `DYN_MACRO_PLAY1` or `DYN_MACRO_PLAY2`. + +If the LED-s start blinking during the recording with each keypress, it means there is no more space for the macro in the macro buffer. To fit the macro in, either make the other macro shorter (they share the same buffer) or increase the buffer size by setting the `DYNAMIC_MACRO_SIZE` preprocessor macro (default value: 256; please read the comments for it in the header). + +For the details about the internals of the dynamic macros, please read the comments in the `dynamic_macro.h` header. ## Additional keycode aliases for software-implemented layouts (Colemak, Dvorak, etc) -- cgit v1.2.1