# How keys are registered, and interpreted by computers
In this file, you can will learn the concepts of how keyboards work over USB,
and you'll be able to better understand what you can expect from changing your
firmware directly.
## Schematic view
Whenever you type on 1 particular key, here is the chain of actions taking
place:
``` text
+------+ +-----+ +----------+ +----------+ +----+
| User |-------->| Key |------>| Firmware |----->| USB wire |---->| OS |
+------+ +-----+ +----------+ +----------+ |----+
```
This scheme is a very simple view of what's going on, and more details follow
in the next sections.
## 1. You Press a Key
Whenever you press a key, the firmware of your keyboard can register this event.
It can register when the key is pressed, held and released.
This usually happens with a [periodic scan of key presses with a frequency around 100 hz](https://github.com/benblazak/ergodox-firmware/blob/master/references.md#typical-keyboard-information).
This speed often is limited by the mechanical key response time, the protocol
to transfer those key presses (here USB HID), and by the software it is used in.
## 2. What the Firmware Sends
The [HID specification](http://www.usb.org/developers/hidpage/Hut1_12v2.pdf)
tells what a keyboard can actually send through USB to have a chance to be
properly recognised. This includes a pre-defined list of keycodes which are
simple numbers from `0x00` to `0xE7`. The firmware assigns a keycode to each
key of the keyboard.
The firmware does not send actually letters or characters, but only keycodes.
Thus, by modifying the firmware, you only can modify what keycode is sent over
USB for a given key.
## 3. What the Operating System Does
Once the keycode reaches the operating system, a piece of software has to have
it match an actual character thanks to a keyboard layout. For example, if your
layout is set to QWERTY, a sample of the matching table is as follow:
``` text
| keycode | character |
|---------+-----------|
| 0x04 | a/A |
| 0x05 | b/B |
| 0x06 | c/C |
| ... | ... |
| 0x1C | y/Y |
| 0x1D | z/Z |
| ... | ... |
|---------+-----------|
```
## Back to the firmware
As the layout is generally fixed (unless you create your own), the firmware can
actually call a keycode by its layout name directly to ease things for you.
This is exactly what is done here with `KC_A` actually representing `0x04` in
QWERTY. The full list can be found in `keycode.txt`.
## List of Characters You Can Send
Putting aside shortcuts, having a limited set of keycodes mapped to a limited
layout means that **the list of characters you can assign to a given key only
is the ones present in the layout**.
For example, this means that if you have a QWERTY US layout, and you want to
assign 1 key to produce `€` (euro currency symbol), you are unable to do so,
because the QWERTY US layout does not have such mapping. You could fix that by
using a QWERTY UK layout, or a QWERTY US International.
You may wonder why a keyboard layout containing all of Unicode is not devised
then? The limited number of keycode available through USB simply disallow such
a thing.
## How to (Maybe) Enter Unicode Characters
You can have the firmware send *sequences of keys* to use the [software Unicode
Input
Method](https://en.wikipedia.org/wiki/Unicode_input#Hexadecimal_code_input) of
the target operating system, thus effectively entering characters independently
of the layout defined in the OS.
Yet, it does come with multiple disadvantages:
- Tied to a specific OS a a time (need recompilation when changing OS);
- Within a given OS, does not work in all software;
@ -14,6 +14,7 @@ This layout more closely resembles that of the Mac keyboard, and has some other
- **The key to the right of "0" is Backspace instead of "-"** (misleadingly labeled "delete" on the Mac's keyboard). There was no room to fit in "-" and "=" between "0" and Backspace, unfortunately.
- **The key to the left of "Q" is Tab instead of Delete.**
- **The rightmost big key on the left thumb is CMD (LGui) instead of Backspace.**
- **The key to the left of Alt-Shift is an Alt key**. This is close to it's position on the Mac keyboard, though slightly further left.
### Other changes
@ -23,7 +24,9 @@ This layout more closely resembles that of the Mac keyboard, and has some other
- **The Toggle L1 keys have been replaced by the otherwise displaced "-" and "=".** They are laid out, left-to-right, in the same order as on the Mac keyboard. Honestly, they are not terribly conveniently placed, and their placement might change in a later version. I found that I did not toggle L1 frequently at all, and found using the momentary keys to access L1 to fit my workflow better.
- **The "~"/L1 key in the bottom-left is now just momentary L1.** The "~" key was moved to the top-left as mentioned before, and I like to keep my multi-use keys to a minimum due to the latency for them to switch from "press" to "hold."
- **The Home and End buttons have been shifted up on the left thumb, and Shift inserted below them.** This makes doing Shift-5 and other such combinations less painful.
- **The Page Up and Page Down buttons have been shifted up on the right thumb, and Alt was moved from above them to below them.** I use Alt more than Page Up or Page Down (mostly in terminal applications), and thought that it deserved a more accessible location.
- **The Page Up and Page Down buttons have been shifted up on the right thumb.** I don't use either of these keys often, and wanted to free up some real estate.
- **The bottommost-inner keys on the left and right thumb are momentary L2 and momentary L1, respectively**. I have found that both modes are useful, and this seemed like a reasonably accessible place to put these.
- **Traditional numpad layout.** The base of most numpads is a double-wide "0" key to the left of a "." key. This is reflected in my layout by having two "0" keys to the left of a "." key.
- **The function keys (F1-F12) have been moved to L2.** They were in the way in L1.
**I'm always open to feedback and/or suggestions!**
@ -42,4 +42,4 @@ I press C-a, C-e, and C-k all the time. It’s difficult to press these key comb
## use spreadsheets
All the common spreadsheet operations (+-*/=) are now on the right side of the symbol layer.
All the common spreadsheet operations (+-*/=) are now on the right side of the symbol layer. There’s also a colon there for entering times and maybe IPv6 addresses. Not that I expect people to type IPv6 addresses into a spreadsheet, but, y’know.
There are two main ways you could customize the ErgoDox (EZ and Infinity)
## The Easy Way: Use an existing firmware file and just flash it
This does not work for Infinity ErgoDox yet, you need to compile the firmware according to the instructions below
## The Easy Way: Use an existing firmware file and just flash it (ErgoDox EZ only)
1. Download and install the [Teensy Loader](https://www.pjrc.com/teensy/loader.html). Some Linux distributions already provide a binary (may be called `teensy-loader-cli`), so you may prefer to use this.
2. Find a firmware file you like. You can find a few of these in the keymaps subdirectory right here. The file you need ends with .hex, and you can look at its .c counterpart (or its PNG image) to see what you'll be getting. You can also use the [Massdrop configurator](https://keyboard-configurator.massdrop.com/ext/ergodox) to create a firmware Hex file you like.
2. Find a firmware file you like. There are [dozens of community-contributed keymaps](http://qmk.fm/keyboards/ergodox/) you can browse and download. You can also use the [Massdrop configurator](https://keyboard-configurator.massdrop.com/ext/ergodox) to create a firmware Hex file you like.
3. Download the firmware file
4. Connect the keyboard, press its Reset button (gently insert a paperclip into the hole in the top-right corner) and flash it using the Teensy loader you installed on step 1 and the firmware you downloaded.
## More technical: compile an existing keymap, or create your own totally custom firmware by editing the source files.
This requires a little bit of familiarity with coding.
This requires a little bit of familiarity with coding.
If you are just compiling an existing keymap and don't want to create your own, you can skip step 4, 5 and 8.
1. Go to https://github.com/jackhumbert/qmk_firmware and read the readme at the base of this repository, top to bottom. Then come back here :)
2. Clone the repository (download it)
3. Set up a build environment as per [the build guide](/doc/BUILD_GUIDE.md)
- Using a Mac and have homebrew? just run `brew tap osx-cross/avr && brew install avr-libc`
3. Set up a build environment as per the readme.
4. Copy `keyboards/ergodox/keymaps/default/keymap.c` into `keymaps/your_name/keymap.c` (for example, `keymaps/german/keymap.c`)
5. Edit this file, changing keycodes to your liking (see "Finding the keycodes you need" below). Try to edit the comments as well, so the "text graphics" represent your layout correctly. See below for more tips on sharing your work.
6. Compile your firmware by running `make keymap=keymap_name`. For example, `make keymap=german`. This will result in a hex file, which will be called `ergodox_ez_keymap_name.hex`, e.g. `ergodox_ez_german.hex`. For **Infinity ErgoDox** you need to add `subproject=infinity` to the make command.
@ -32,12 +29,12 @@ Good luck! :)
## Contributing your keymap
The ErgoDox firmware is open-source, so it would be wonderful to have your contribution! Within a very short time after launching we already amassed almost 20 user-contributed keymaps, with all sorts of creative improvements and tweaks. This is very valuable for people who aren't comfortable coding, but do want to customize their ErgoDox. To make it easy for these people to use your layout, I recommend submitting your PR in the following format.
The QMK firmware is open-source, so it would be wonderful to have your contribution! Within a very short time after launching we already amassed dozens of user-contributed keymaps, with all sorts of creative improvements and tweaks. This is very valuable for people who aren't comfortable coding, but do want to customize their ErgoDox. To make it easy for these people to use your layout, I recommend submitting your PR in the following format.
1. All work goes inside your keymap subdirectory (`keymaps/german` in this example).
2. `keymap.c` - this is your actual keymap file; please update the ASCII comments in the file so they correspond with what you did.
3. `readme.md` - a readme file, which GitHub would display by default when people go to your directory. Explain what's different about your keymap, what you tweaked or how it works. No specific format to follow, just communicate what you did. :)
4. Any graphics you wish to add. This is absolutely not a must. If you feel like it, you can use [Keyboard Layout Editor](http://keyboard-layout-editor.com) to make something and grab a screenshot, but it's really not a must. If you do have graphics, your readme can just embed the graphic as a link, just like I did with the default layout.
4. Any graphics you wish to add. This is absolutely not a must. If you feel like it, you can use [Keyboard Layout Editor](http://keyboard-layout-editor.com) to make something and grab a screenshot, but it's really not a must. If you do have graphics, your readme can just embed the graphic as a link, just like I did with the default layout.
@ -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=<keyboard>` - specifies the keyboard (only to be used in root)
* `make keymap=<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=<keyboard>]` - builds all of the keymaps for whatever keyboard folder you're in, or specified by `<keyboard>`
* `make all-keyboards-quick`, `make all-keyboards-default-quick` and `make all-keymaps-quick [keyboard=<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=<keyboard>]` - like the normal "make-all-*" commands, but the last string aftter the `-` (for example clean) is passed to the keyboard make command.
Joshua T
8 years ago