iCE40/nextpnr - clone of git://git.panaceas.org/iCE40/nextpnr

diff options

Diffstat (limited to '3rdparty')

0 files changed, 0 insertions, 0 deletions

# Quantum Mechanical Keyboard Firmware This is a keyboard firmware based on the [tmk_keyboard firmware](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.co), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/). QMK is developed and maintained by Jack Humbert of OLKB with contributions from the community, and of course, TMK. 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). The OLKB product firmwares are maintained by Jack, the Ergodox EZ by Erez, and the Clueboard by [Zach White](https://github.com/skullydazed). ## Important background info: TMK documentation The documentation below explains QMK customizations and elaborates on some of the more useful features of TMK. To understand the base firmware, and especially what *layers* are and how they work, please see [TMK_README.md](/TMK_README.md). ## Getting started * [BUILD_GUIDE.md](BUILD_GUIDE.md) contains instructions to set up a build environment, build the firmware, and deploy it to a keyboard. Once your build environment has been set up, all `make` commands to actually build the firmware must be run from a folder in `keyboard/`. * If you're looking to customize a keyboard that currently runs QMK or TMK, find your keyboard's directory under `keyboard/` and run the make commands from there. * If you're looking to apply this firmware to an entirely new hardware project (a new kind of keyboard), you can create your own Quantum-based project by using `./new_project.sh <project_name>`, which will create `/keyboard/<project_name>` with all the necessary components for a Quantum project. ### Makefile Options You have access to a bunch of goodies! Check out the Makefile to enable/disable some of the features. Uncomment the `#` to enable them. Setting them to `no` does nothing and will only confuse future you. BACKLIGHT_ENABLE = yes # Enable keyboard backlight functionality MIDI_ENABLE = yes # MIDI controls UNICODE_ENABLE = no # <-- This is how you disable an option, just set it to "no" BLUETOOTH_ENABLE = yes # Enable Bluetooth with the Adafruit EZ-Key HID ### Customizing Makefile options on a per-keymap basis If your keymap directory has a file called `makefile.mk` (note the lowercase filename, and the `.mk` extension), any Makefile options you set in that file will take precedence over other Makefile options (those set for Quantum as a whole or for your particular keyboard). So let's say your keyboard's makefile has `CONSOLE_ENABLE = yes` (or maybe doesn't even list the `CONSOLE_ENABLE` option, which would cause it to revert to the global Quantum default). You want your particular keymap to not have the debug console, so you make a file called `makefile.mk` and specify `CONSOLE_ENABLE = no`. ### Customizing config.h on a per-keymap basis If you use the ErgoDox EZ, you can make a `config_user.h` file in your keymap directory and use it to override any `config.h` settings you don't like. Anything you set there will take precedence over the global `config.h` for the ErgoDox EZ. To see an example of this, check out `keymaps/erez_experimental`. ## Quick aliases to common actions Your keymap can include shortcuts to common operations (called "function actions" in tmk). ### 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. `OSL(layer)` - momentary switch to *layer*, as a one-shot operation. So if you have a key that's defined as `OSL(1)`, and you tap that key, then only the very next keystroke would come from layer 1. You would drop back to layer zero immediately after that one keystroke. That's handy if you have a layer full of custom shortcuts -- for example, a dedicated key for closing a window. So you tap your one-shot layer mod, then tap that magic 'close window' key, and keep typing like a boss. Layer 1 would remain active as long as you hold that key down, too (so you can use it like a momentary toggle-layer key with extra powers). `LT(layer, kc)` - momentary switch to *layer* when held, and *kc* when tapped. Like `MO()`, this only works upwards in the layer stack (`layer` must be higher than the current layer). `TG(layer)` - toggles a layer on or off. As with `MO()`, you should set this key as `KC_TRNS` in the destination layer so that tapping it again actually toggles back to the original layer. Only works upwards in the layer stack. ### Fun with modifier keys * `LSFT(kc)` - applies left Shift to *kc* (keycode) - `S(kc)` is an alias * `RSFT(kc)` - applies right Shift to *kc* * `LCTL(kc)` - applies left Control to *kc* * `RCTL(kc)` - applies right Control to *kc* * `LALT(kc)` - applies left Alt to *kc* * `RALT(kc)` - applies right Alt to *kc* * `LGUI(kc)` - applies left GUI (command/win) to *kc* * `RGUI(kc)` - applies right GUI (command/win) to *kc* * `HYPR(kc)` - applies Hyper (all modifiers) to *kc* * `MEH(kc)` - applies Meh (all modifiers except Win/Cmd) to *kc* * `LCAG(kc)` - applies CtrlAltGui to *kc* You can also chain these, like this: LALT(LCTL(KC_DEL)) -- this makes a key that sends Alt, Control, and Delete in a single keypress. The following shortcuts automatically add `LSFT()` to keycodes to get commonly used symbols. Their long names are also available and documented in `/quantum/keymap_common.h`. KC_TILD ~ KC_EXLM ! KC_AT @ KC_HASH # KC_DLR $ KC_PERC % KC_CIRC ^ KC_AMPR & KC_ASTR * KC_LPRN ( KC_RPRN ) KC_UNDS _ KC_PLUS + KC_LCBR { KC_RCBR } KC_LABK < KC_RABK > KC_PIPE | KC_COLN : `OSM(mod)` - this is a "one shot" modifier. So let's say you have your left Shift key defined as `OSM(MOD_LSFT)`. Tap it, let go, and Shift is "on" -- but only for the next character you'll type. So to write "The", you don't need to hold down Shift -- you tap it, tap t, and move on with life. And if you hold down the left Shift key, it just works as a left Shift key, as you would expect (so you could type THE). There's also a magical, secret way to "lock" a modifier by tapping it multiple times. If you want to learn more about that, open an issue. :) `MT(mod, kc)` - is *mod* (modifier key - MOD_LCTL, MOD_LSFT) when held, and *kc* when tapped. In other words, you can have a key that sends Esc (or the letter O or whatever) when you tap it, but works as a Control key or a Shift key when you hold it down. These are the values you can use for the `mod` in `MT()` and `OSM()` (right-hand modifiers are not available for `MT()`): * MOD_LCTL * MOD_LSFT * MOD_LALT * MOD_LGUI * MOD_HYPR * MOD_MEH These can also be combined like `MOD_LCTL | MOD_LSFT` e.g. `MT(MOD_LCTL | MOD_LSFT, KC_ESC)` which would activate Control and Shift when held, and send Escape when tapped. We've added shortcuts to make common modifier/tap (mod-tap) mappings more compact: * `CTL_T(kc)` - is LCTL when held and *kc* when tapped * `SFT_T(kc)` - is LSFT when held and *kc* when tapped * `ALT_T(kc)` - is LALT when held and *kc* when tapped


context:
space:
mode: