diff --git a/.vscode/settings.json b/.vscode/settings.json index afe8341d0e2..ba5b56aa402 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -11,6 +11,7 @@ "*.h": "c", "*.c": "c", "*.cpp": "cpp", - "*.hpp": "cpp" + "*.hpp": "cpp", + "xstddef": "c" } -} \ No newline at end of file +} diff --git a/bootloader.mk b/bootloader.mk index 55352f3d426..4bcf183fb77 100644 --- a/bootloader.mk +++ b/bootloader.mk @@ -32,21 +32,41 @@ ifeq ($(strip $(BOOTLOADER)), atmel-dfu) OPT_DEFS += -DBOOTLOADER_ATMEL_DFU OPT_DEFS += -DBOOTLOADER_DFU - BOOTLOADER_SIZE = 4096 + ifeq ($(strip $(MCU)), atmega32u4) + BOOTLOADER_SIZE = 4096 + endif + ifeq ($(strip $(MCU)), at90usb1286) + BOOTLOADER_SIZE = 8192 + endif endif ifeq ($(strip $(BOOTLOADER)), lufa-dfu) OPT_DEFS += -DBOOTLOADER_LUFA_DFU OPT_DEFS += -DBOOTLOADER_DFU - BOOTLOADER_SIZE = 4096 + ifeq ($(strip $(MCU)), atmega32u4) + BOOTLOADER_SIZE = 4096 + endif + ifeq ($(strip $(MCU)), at90usb1286) + BOOTLOADER_SIZE = 8192 + endif endif ifeq ($(strip $(BOOTLOADER)), qmk-dfu) OPT_DEFS += -DBOOTLOADER_QMK_DFU OPT_DEFS += -DBOOTLOADER_DFU - BOOTLOADER_SIZE = 4096 + ifeq ($(strip $(MCU)), atmega32u4) + BOOTLOADER_SIZE = 4096 + endif + ifeq ($(strip $(MCU)), at90usb1286) + BOOTLOADER_SIZE = 8192 + endif endif ifeq ($(strip $(BOOTLOADER)), halfkay) OPT_DEFS += -DBOOTLOADER_HALFKAY - BOOTLOADER_SIZE = 512 + ifeq ($(strip $(MCU)), atmega32u4) + BOOTLOADER_SIZE = 512 + endif + ifeq ($(strip $(MCU)), at90usb1286) + BOOTLOADER_SIZE = 1024 + endif endif ifeq ($(strip $(BOOTLOADER)), caterina) OPT_DEFS += -DBOOTLOADER_CATERINA @@ -59,4 +79,4 @@ endif ifdef BOOTLOADER_SIZE OPT_DEFS += -DBOOTLOADER_SIZE=$(strip $(BOOTLOADER_SIZE)) -endif \ No newline at end of file +endif diff --git a/build_keyboard.mk b/build_keyboard.mk index 4781f4a5d19..b25712385c6 100644 --- a/build_keyboard.mk +++ b/build_keyboard.mk @@ -210,8 +210,8 @@ endif USER_PATH := users/$(USER_NAME) -include $(USER_PATH)/rules.mk -ifneq ("$(wildcard users/$(KEYMAP)/config.h)","") - CONFIG_H += users/$(KEYMAP)/config.h +ifneq ("$(wildcard $(USER_PATH)/config.h)","") + CONFIG_H += $(USER_PATH)/config.h endif diff --git a/common_features.mk b/common_features.mk index 7bd43afdbaf..0778f8e0f51 100644 --- a/common_features.mk +++ b/common_features.mk @@ -114,6 +114,15 @@ ifeq ($(strip $(RGBLIGHT_ENABLE)), yes) endif endif +ifeq ($(strip $(RGB_MATRIX_ENABLE)), yes) + OPT_DEFS += -DRGB_MATRIX_ENABLE + SRC += is31fl3731.c + SRC += i2c_master.c + SRC += $(QUANTUM_DIR)/color.c + SRC += $(QUANTUM_DIR)/rgb_matrix.c + CIE1931_CURVE = yes +endif + ifeq ($(strip $(TAP_DANCE_ENABLE)), yes) OPT_DEFS += -DTAP_DANCE_ENABLE SRC += $(QUANTUM_DIR)/process_keycode/process_tap_dance.c diff --git a/docs/CNAME b/docs/CNAME new file mode 100644 index 00000000000..e089843e0bc --- /dev/null +++ b/docs/CNAME @@ -0,0 +1 @@ +docs.qmk.fm \ No newline at end of file diff --git a/docs/README.md b/docs/README.md index d4587d2dfd1..22ab243cd25 100644 --- a/docs/README.md +++ b/docs/README.md @@ -9,7 +9,7 @@ ## What is QMK Firmware? -QMK (*Quantum Mechanical Keyboard*) is an open source community that maintains QMK Firmware, QMK Flasher, qmk.fm, and these docs. QMK Firmware is a keyboard firmware based on the [tmk\_keyboard](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB. +QMK (*Quantum Mechanical Keyboard*) is an open source community that maintains QMK Firmware, QMK Toolbox, qmk.fm, and these docs. QMK Firmware is a keyboard firmware based on the [tmk\_keyboard](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.com), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB. ## How to Get It @@ -19,7 +19,7 @@ Otherwise, you can either download it directly ([zip](https://github.com/qmk/qmk ## How to Compile -Before you are able to compile, you'll need to [install an environment](01_Getting_Started/01_Install_Build_Tools.md) for AVR or/and ARM development. Once that is complete, you'll use the `make` command to build a keyboard and keymap with the following notation: +Before you are able to compile, you'll need to [install an environment](getting_started_build_tools.md) for AVR or/and ARM development. Once that is complete, you'll use the `make` command to build a keyboard and keymap with the following notation: make planck/rev4:default @@ -29,4 +29,4 @@ This would build the `rev4` revision of the `planck` with the `default` keymap. ## How to Customize -QMK has lots of [features](05_Features/index.md) to explore, and a good deal of [reference documentation](http://docs.qmk.fm) to dig through. Most features are taken advantage of by modifying your [keymap](07_Reference/Keymap_Overview.md), and changing the [keycodes](06_Keycodes/index.md). +QMK has lots of [features](features.md) to explore, and a good deal of [reference documentation](http://docs.qmk.fm) to dig through. Most features are taken advantage of by modifying your [keymap](keymap.md), and changing the [keycodes](keycodes.md). diff --git a/docs/_sidebar.md b/docs/_sidebar.md index 00aeb805777..31a22315dd2 100644 --- a/docs/_sidebar.md +++ b/docs/_sidebar.md @@ -43,6 +43,7 @@ * [Pointing Device](feature_pointing_device.md) * [PS/2 Mouse](feature_ps2_mouse.md) * [RGB Lighting](feature_rgblight.md) + * [RGB Matrix](feature_rgb_matrix.md) * [Space Cadet Shift](feature_space_cadet.md) * [Space Cadet Shift Enter](feature_space_shift_cadet.md) * [Stenography](feature_stenography.md) diff --git a/docs/contributing.md b/docs/contributing.md index 0e8066f0053..17a9aa98591 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -101,7 +101,7 @@ You'll find all our documentation in the `qmk_firmware/docs` directory, or if yo Most first-time QMK contributors start with their personal keymaps. We try to keep keymap standards pretty casual (keymaps, after all, reflect the personality of their creators) but we do ask that you follow these guidelines to make it easier for others to discover and learn from your keymap. -* Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#). +* Write a `readme.md` using [the template](documentation_templates.md). * All Keymap PR's are squashed, so if you care about how your commits are squashed you should do it yourself * Do not lump features in with keymap PR's. Submit the feature first and then a second PR for the keymap. * Do not include `Makefile`s in your keymap folder (they're no longer used) @@ -113,7 +113,7 @@ Keyboards are the raison d'être for QMK. Some keyboards are community maintaine We also ask that you follow these guidelines: -* Write a `readme.md` using [the template](https://docs.qmk.fm/documentation_templates.html#). +* Write a `readme.md` using [the template](documentation_templates.md). * Keep the number of commits reasonable or we will squash your PR * Do not lump core features in with new keyboards. Submit the feature first and then submit a separate PR for the keyboard. * Name `.c`/`.h` file after the immediate parent folder, eg `/keyboards///.[ch]` @@ -140,7 +140,7 @@ We also ask that you follow these guidelines: * Keep the number of commits reasonable or we will squash your PR * Do not lump keyboards or keymaps in with core changes. Submit your core changes first. -* Write [Unit Tests](http://docs.qmk.fm/unit_testing.html) for your feature +* Write [Unit Tests](unit_testing.md) for your feature * Follow the style of the file you are editing. If the style is unclear or there are mixed styles you should conform to the [coding conventions](#coding-conventions) above. ## Refactoring diff --git a/docs/feature_audio.md b/docs/feature_audio.md index 1b8ca86f498..50e389605c1 100644 --- a/docs/feature_audio.md +++ b/docs/feature_audio.md @@ -89,6 +89,20 @@ By default, `MUSIC_MASK` is set to `keycode < 0xFF` which means keycodes less th Which will capture all keycodes - be careful, this will get you stuck in music mode until you restart your keyboard! +For a more advanced way to control which keycodes should still be processed, you can use `music_mask_kb(keycode)` in `.c` and `music_mask_user(keycode)` in your `keymap.c`: + + bool music_mask_user(uint16_t keycode) { + switch (keycode) { + case RAISE: + case LOWER: + return false; + default: + return true; + } + } + +Things that return false are not part of the mask, and are always processed. + The pitch standard (`PITCH_STANDARD_A`) is 440.0f by default - to change this, add something like this to your `config.h`: #define PITCH_STANDARD_A 432.0f diff --git a/docs/feature_leader_key.md b/docs/feature_leader_key.md index fb74bf7c8b0..46633b28703 100644 --- a/docs/feature_leader_key.md +++ b/docs/feature_leader_key.md @@ -17,14 +17,16 @@ void matrix_scan_user(void) { leader_end(); SEQ_ONE_KEY(KC_F) { - register_code(KC_S); - unregister_code(KC_S); + // Anything you can do in a macro. + SEND_STRING("QMK is awesome."); + } + SEQ_TWO_KEYS(KC_D, KC_D) { + SEND_STRING(SS_LCTRL("a")SS_LCTRL("c")); + } + SEQ_THREE_KEYS(KC_D, KC_D, KC_S) { + SEND_STRING("https://start.duckduckgo.com"SS_TAP(X_ENTER)); } SEQ_TWO_KEYS(KC_A, KC_S) { - register_code(KC_H); - unregister_code(KC_H); - } - SEQ_THREE_KEYS(KC_A, KC_S, KC_D) { register_code(KC_LGUI); register_code(KC_S); unregister_code(KC_S); @@ -34,4 +36,6 @@ 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. +As you can see, you have a few function. You can use `SEQ_ONE_KEY` for single-key sequences (Leader followed by just one key), and `SEQ_TWO_KEYS`, `SEQ_THREE_KEYS` up to `SEQ_FIVE_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. diff --git a/docs/feature_rgb_matrix.md b/docs/feature_rgb_matrix.md new file mode 100644 index 00000000000..5d2db3b9709 --- /dev/null +++ b/docs/feature_rgb_matrix.md @@ -0,0 +1,143 @@ +# RGB Matrix Lighting + +There is basic support for addressable RGB matrix lighting with the I2C IS31FL3731 RGB controller. To enable it, add this to your `rules.mk`: + + RGB_MATRIX_ENABLE = yes + +Configure the hardware via your `config.h`: + + // This is a 7-bit address, that gets left-shifted and bit 0 + // set to 0 for write, 1 for read (as per I2C protocol) + // The address will vary depending on your wiring: + // 0b1110100 AD <-> GND + // 0b1110111 AD <-> VCC + // 0b1110101 AD <-> SCL + // 0b1110110 AD <-> SDA + #define DRIVER_ADDR_1 0b1110100 + #define DRIVER_ADDR_2 0b1110110 + + #define DRIVER_COUNT 2 + #define DRIVER_1_LED_TOTAL 25 + #define DRIVER_2_LED_TOTAL 24 + #define DRIVER_LED_TOTAL DRIVER_1_LED_TOTAL + DRIVER_2_LED_TOTAL + +Currently only 2 drivers are supported, but it would be trivial to support all 4 combinations. + +Define these arrays listing all the LEDs in your `.c`: + + const is31_led g_is31_leds[DRIVER_LED_TOTAL] = { + /* Refer to IS31 manual for these locations + * driver + * | R location + * | | G location + * | | | B location + * | | | | */ + {0, C1_3, C2_3, C3_3}, + .... + } + +Where `Cx_y` is the location of the LED in the matrix defined by [the datasheet](http://www.issi.com/WW/pdf/31FL3731.pdf). The `driver` is the index of the driver you defined in your `config.h` (`0` or `1` right now). + + const rgb_led g_rgb_leds[DRIVER_LED_TOTAL] = { + /* {row | col << 4} + * | {x=0..224, y=0..64} + * | | modifier + * | | | */ + {{0|(0<<4)}, {20.36*0, 21.33*0}, 1}, + {{0|(1<<4)}, {20.36*1, 21.33*0}, 1}, + .... + } + +The format for the matrix position used in this array is `{row | (col << 4)}`. The `x` is between (inclusive) 0-224, and `y` is between (inclusive) 0-64. The easiest way to calculate these positions is: + + x = 224 / ( NUMBER_OF_ROWS - 1 ) * ROW_POSITION + y = 64 / (NUMBER_OF_COLS - 1 ) * COL_POSITION + +Where all variables are decimels/floats. + +`modifier` is a boolean, whether or not a certain key is considered a modifier (used in some effects). + +## Keycodes + +All RGB keycodes are currently shared with the RGBLIGHT system: + + * `RGB_TOG` - toggle + * `RGB_MOD` - cycle through modes + * `RGB_HUI` - increase hue + * `RGB_HUD` - decrease hue + * `RGB_SAI` - increase saturation + * `RGB_SAD` - decrease saturation + * `RGB_VAI` - increase value + * `RGB_VAD` - decrease value + * `RGB_SPI` - increase speed effect (no EEPROM support) + * `RGB_SPD` - decrease speed effect (no EEPROM support) + + + * `RGB_MODE_*` keycodes will generally work, but are not currently mapped to the correct effects for the RGB Matrix system + +## RGB Matrix Effects + +These are the effects that are currently available: + + enum rgb_matrix_effects { + RGB_MATRIX_SOLID_COLOR = 1, + RGB_MATRIX_ALPHAS_MODS, + RGB_MATRIX_DUAL_BEACON, + RGB_MATRIX_GRADIENT_UP_DOWN, + RGB_MATRIX_RAINDROPS, + RGB_MATRIX_CYCLE_ALL, + RGB_MATRIX_CYCLE_LEFT_RIGHT, + RGB_MATRIX_CYCLE_UP_DOWN, + RGB_MATRIX_RAINBOW_BEACON, + RGB_MATRIX_RAINBOW_PINWHEELS, + RGB_MATRIX_RAINBOW_MOVING_CHEVRON, + RGB_MATRIX_JELLYBEAN_RAINDROPS, + #ifdef RGB_MATRIX_KEYPRESSES + RGB_MATRIX_SOLID_REACTIVE, + RGB_MATRIX_SPLASH, + RGB_MATRIX_MULTISPLASH, + RGB_MATRIX_SOLID_SPLASH, + RGB_MATRIX_SOLID_MULTISPLASH, + #endif + RGB_MATRIX_EFFECT_MAX + }; + +## Custom layer effects + +Custom layer effects can be done by defining this in your `.c`: + + void rgb_matrix_indicators_kb(void) { + // rgb_matrix_set_color(index, red, green, blue); + } + +A similar function works in the keymap as `rgb_matrix_indicators_user`. + +## Additional `config.h` Options + + #define RGB_MATRIX_KEYPRESSES // reacts to keypresses (will slow down matrix scan by a lot) + #define RGB_MATRIX_KEYRELEASES // reacts to keyreleases (not recommened) + #define RGB_DISABLE_AFTER_TIMEOUT 0 // number of ticks to wait until disabling effects + #define RGB_DISABLE_WHEN_USB_SUSPENDED false // turn off effects when suspended + #define RGB_MATRIX_SKIP_FRAMES 1 // number of frames to skip when displaying animations (0 is full effect) if not defined defaults to 1 + +## EEPROM storage + +The EEPROM for it is currently shared with the RGBLIGHT system (it's generally assumed only one RGB would be used at a time), but could be configured to use its own 32bit address with: + + #define EECONFIG_RGB_MATRIX (uint32_t *)16 + +Where `16` is an unused index from `eeconfig.h`. + +## Suspended state + +To use the suspend feature, add this to your `.c`: + + void suspend_power_down_kb(void) + { + rgb_matrix_set_suspend_state(true); + } + + void suspend_wakeup_init_kb(void) + { + rgb_matrix_set_suspend_state(false); + } diff --git a/docs/feature_rgblight.md b/docs/feature_rgblight.md index 0f1e649ef85..5369d2fb768 100644 --- a/docs/feature_rgblight.md +++ b/docs/feature_rgblight.md @@ -88,11 +88,36 @@ const uint16_t RGBLED_GRADIENT_RANGES[] PROGMEM = {360, 240, 180, 120, 90}; Look in `rgblights.h` for all available functions, but if you want to control all or some LEDs your goto functions are: ```c -rgblight_disable(); // turn all lights off -rgblight_enable(); // turn lights on, based on their previous state (stored in EEPROM) +// turn all lights off (stored in EEPROM) +rgblight_disable(); +// turn lights on, based on their previous state (stored in EEPROM) +rgblight_enable(); + +// turn all lights off (not stored in EEPROM) +rgblight_disable_noeeprom(); +// turn lights on, based on their previous state (not stored in EEPROM) +rgblight_enable_noeeprom(); + +// where r/g/b is a number from 0..255. Turns all the LEDs to this color (ignores mode, not stored in EEPROM). +rgblight_setrgb(r, g, b); +// HSV color control - h is a value from 0..360 and s/v is a value from 0..255 (stored in EEPROM) +rgblight_sethsv(h, s, v); +// HSV color control - h is a value from 0..360 and s/v is a value from 0..255 (not stored in EEPROM) +rgblight_sethsv_noeeprom(h, s, v); + +// Sets the mode, if rgb animations are enabled (stored in eeprom) +rgblight_mode(x); +// Sets the mode, if rgb animations are enabled (not stored in eeprom) +rgblight_mode_noeeprom(x); +// MODE 1, solid color +// MODE 2-5, breathing +// MODE 6-8, rainbow mood +// MODE 9-14, rainbow swirl +// MODE 15-20, snake +// MODE 21-23, knight +// MODE 24, xmas +// MODE 25-34, static rainbow -rgblight_setrgb(r, g, b); // where r/g/b is a number from 0..255. Turns all the LEDs to this color -rgblight_sethsv(h, s, v); // HSV color control - h is a value from 0..360 and s/v is a value from 0..255 rgblight_setrgb_at(r,g,b, LED); // control a single LED. 0 <= LED < RGBLED_NUM rgblight_sethsv_at(h,s,v, LED); // control a single LED. 0 <= LED < RGBLED_NUM ``` @@ -126,7 +151,7 @@ note: for backwards compatibility, `RGB_SMOD` is an alias for `RGB_MOD`. ## Hardware Modification -![Planck with RGB Underglow](https://raw.githubusercontent.com/qmk/qmk_firmware/master/keyboards/planck/keymaps/yang/planck-with-rgb-underglow.jpg) +![Planck with RGB Underglow](https://raw.githubusercontent.com/qmk/qmk_firmware/3774a7fcdab5544fc787f4c200be05fcd417e31f/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). diff --git a/docs/feature_tap_dance.md b/docs/feature_tap_dance.md index 141c3108d06..99298fbda83 100644 --- a/docs/feature_tap_dance.md +++ b/docs/feature_tap_dance.md @@ -6,9 +6,9 @@ Hit the semicolon key once, send a semicolon. Hit it twice, rapidly -- send a co 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. +To make it clear how this is different from `ACTION_FUNCTION_TAP`, let's 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. +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 sent 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. @@ -16,11 +16,13 @@ But lets start with how to use it, first! First, you will need `TAP_DANCE_ENABLE=yes` in your `rules.mk`, 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 three possible options: +This array specifies what actions shall be taken when a tap-dance key is in action. Currently, there are five possible options: * `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_DUAL_ROLE(kc, layer)`: Sends the `kc` keycode when tapped once, or moves to `layer`. (this functions like the `TO` layer keycode). * `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_dance_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. +* `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function when the dance action finishes (like the previous option), and the last function when the tap dance action resets. +* `ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`. The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise. diff --git a/docs/features.md b/docs/features.md index 5abede2c253..4dee486ef17 100644 --- a/docs/features.md +++ b/docs/features.md @@ -17,8 +17,10 @@ QMK has a staggering number of features for building your keyboard. It can take * [Pointing Device](feature_pointing_device.md) - Framework for connecting your custom pointing device to your keyboard. * [PS2 Mouse](feature_ps2_mouse.md) - Driver for connecting a PS/2 mouse directly to your keyboard. * [RGB Light](feature_rgblight.md) - RGB lighting for your keyboard. +* [RGB Matrix](feature_rgb_matrix.md) - RGB Matrix lights for per key lighting. * [Space Cadet](feature_space_cadet.md) - Use your left/right shift keys to type parenthesis and brackets. * [Stenography](feature_stenography.md) - Put your keyboard into Plover mode for stenography use. +* [Swap Hands](feature_swap_hands.md) - Mirror your keyboard for one handed usage. * [Tap Dance](feature_tap_dance.md) - Make a single key do as many things as you want. * [Terminal](feature_terminal.md) - CLI interface to the internals of your keyboard. * [Thermal Printer](feature_thermal_printer.md) - Connect a thermal printer to your keyboard to be able to toggle on a printed log of everything you type. diff --git a/docs/getting_started_build_tools.md b/docs/getting_started_build_tools.md index 636b54672f8..45b51b2ccbf 100644 --- a/docs/getting_started_build_tools.md +++ b/docs/getting_started_build_tools.md @@ -4,6 +4,8 @@ This page describes setting up the build environment for QMK. These instructions +Note: If it is your first time here, Check out the "Complete Newbs guide" instead + ## Linux To ensure you are always up to date, you can just run `sudo util/install_dependencies.sh`. That should always install all the dependencies needed. **This will run `apt-get upgrade`.** diff --git a/docs/getting_started_make_guide.md b/docs/getting_started_make_guide.md index 39ea34a60f6..a57edcb9846 100644 --- a/docs/getting_started_make_guide.md +++ b/docs/getting_started_make_guide.md @@ -14,7 +14,7 @@ The full syntax of the `make` command is `::`, The `` means the following * If no target is given, then it's the same as `all` below * `all` compiles as many keyboard/revision/keymap combinations as specified. For example, `make planck/rev4:default` will generate a single .hex, while `make planck/rev4:all` will generate a hex for every keymap available to the planck. -* `dfu`, `teensy` or `dfu-util`, compile and upload the firmware to the keyboard. If the compilation fails, then nothing will be uploaded. The programmer to use depends on the keyboard. For most keyboards it's `dfu`, but for ChibiOS keyboards you should use `dfu-util`, and `teensy` for standard Teensys. To find out which command you should use for your keyboard, check the keyboard specific readme. +* `dfu`, `teensy`, `avrdude` or `dfu-util`, compile and upload the firmware to the keyboard. If the compilation fails, then nothing will be uploaded. The programmer to use depends on the keyboard. For most keyboards it's `dfu`, but for ChibiOS keyboards you should use `dfu-util`, and `teensy` for standard Teensys. To find out which command you should use for your keyboard, check the keyboard specific readme. * **Note**: some operating systems need root access for these commands to work, so in that case you need to run for example `sudo make planck/rev4:default:dfu`. * `clean`, cleans the build output folders to make sure that everything is built from scratch. Run this before normal compilation if you have some unexplainable problems. diff --git a/docs/hardware_keyboard_guidelines.md b/docs/hardware_keyboard_guidelines.md index 27d29f5c72d..67af78838a1 100644 --- a/docs/hardware_keyboard_guidelines.md +++ b/docs/hardware_keyboard_guidelines.md @@ -47,16 +47,6 @@ The `info.json` file is a JSON formatted dictionary with the following keys avai * Example: `Clueboard 66%` * `url` * A URL to the keyboard's product page, [QMK.fm/keyboards](https://qmk.fm/keyboards) page, or other page describing information about the keyboard. -* `bootloader` - * What bootloader this keyboard uses. Available options: - * `atmel-dfu` - * `kiibohd-dfu-util` - * `lufa-dfu` - * `qmk-dfu` - * `stm32-dfu-util` - * `caterina` - * `halfkay` - * `bootloadHID` * `maintainer` * GitHub username of the maintainer, or `qmk` for community maintained boards * `width` diff --git a/docs/index.html b/docs/index.html index 9fddda840d7..f0b1fae07e7 100644 --- a/docs/index.html +++ b/docs/index.html @@ -2,11 +2,13 @@ - Document + QMK Firmware - + + +
@@ -18,9 +20,16 @@ loadSidebar: true, auto2top: true, formatUpdated: '{YYYY}/{MM}/{DD} {HH}:{mm}', + search: { + paths: 'auto', + placeholder: 'Search Documentation...', + noData: 'We could not find any documents matching your search.', + depth: 6 + } } + @@ -28,6 +37,7 @@