forked from forks/qmk_firmware
Overhaul the Getting Started section and add a FAQ section
This commit is contained in:
parent
89bcdde927
commit
e6c638bed1
|
@ -1,11 +1,15 @@
|
|||
* [Getting started](README.md)
|
||||
* [QMK Overview](qmk_overview.md)
|
||||
* [Build Environment Setup](build_environment_setup.md)
|
||||
* [Vagrant Guide](vagrant_guide.md)
|
||||
* [Make instructions](make_instructions.md)
|
||||
* [FAQ: Creating a Keymap](faq_keymap.md)
|
||||
* [FAQ: Compiling QMK](faq_build.md)
|
||||
* [How to Github](how_to_github.md)
|
||||
* [QMK Introduction](getting_started_introduction.md)
|
||||
* [Install Build Tools](getting_started_build_tools.md)
|
||||
* Alternative: [Vagrant Guide](getting_started_vagrant_guide.md)
|
||||
* [Build/Compile instructions](getting_started_make_guide.md)
|
||||
* [How to Use Github](getting_started_github.md)
|
||||
|
||||
* [FAQ](faq.md)
|
||||
* [General FAQ](faq_general.md)
|
||||
* [Build/Compile QMK](faq_build.md)
|
||||
* [Debugging/Troubleshooting QMK](faq_debug.md)
|
||||
* [Keymap](faq_keymap.md)
|
||||
|
||||
* [Features](features.md)
|
||||
* [Layer switching](key_functions.md)
|
||||
|
@ -43,5 +47,4 @@
|
|||
* [Understanding QMK](understanding_qmk.md)
|
||||
|
||||
* Other Topics
|
||||
* [General FAQ](faq.md)
|
||||
* [Using Eclipse with QMK](eclipse.md)
|
||||
|
|
218
docs/faq.md
218
docs/faq.md
|
@ -1,216 +1,6 @@
|
|||
# Frequently Asked Questions
|
||||
|
||||
## General
|
||||
|
||||
### What is QMK?
|
||||
|
||||
[QMK](https://github.com/qmk), short for Quantum Mechanical Keyboard, is a group of people building tools for custom keyboards. We started with the [QMK firmware](https://github.com/qmk/qmk_firmware), a heavily modified fork of [TMK](https://github.com/tmk/tmk_keyboard).
|
||||
|
||||
### Why the name Quantum?
|
||||
|
||||
<!-- FIXME -->
|
||||
|
||||
### What Differences Are There Between QMK and TMK?
|
||||
|
||||
TMK was originally designed and implemented by [Jun Wako](https://github.com/tmk). QMK started as [Jack Humbert's](https://github.com/jackhumbert) fork of TMK for the Planck. After a while Jack's fork had diverged quite a bit from TMK, and in 2015 Jack decided to rename his fork to QMK.
|
||||
|
||||
From a technical standpoint QMK builds upon TMK by adding several new features. Most notably QMK has expanded the number of available keycodes and uses these to implement advanced features like `S()`, `LCTL()`, and `MO()`. You can see a complete list of these keycodes in [Quantum Keycodes](quantum_keycodes.html).
|
||||
|
||||
From a project and community management standpoint TMK maintains all the officially supported keyboards by himself, with a bit of community support. Separate community maintained forks exist or can be created for other keyboards. Only a few keymaps are provided by default, so users typically don't share keymaps with each other. QMK encourages sharing of both keyboards and keymaps through a centrally managed repository, accepting all pull requests that follows the quality standards. These are mostly community maintained, but the QMK team also helps when necessary.
|
||||
|
||||
Both approaches have their merits and their drawbacks, and code flows freely between TMK and QMK when it makes sense.
|
||||
|
||||
# Building
|
||||
|
||||
## Windows
|
||||
|
||||
### I'm on Windows Vista, 7, or 8, how do I setup my build environment?
|
||||
|
||||
Follow the build instructions to [install MHV AVR Tools](https://docs.qmk.fm/build_environment_setup.html#windows-vista-and-later).
|
||||
|
||||
### I'm on Windows 10 without the Creators Update. Do I have to install it?
|
||||
|
||||
No, but if you don't install the creators update you will not be able to build and flash with a single command. You will be able to build but to flash you will have to use a separate program, such as [QMK Flasher](https://github.com/qmk/qmk_flasher).
|
||||
|
||||
# Troubleshooting
|
||||
|
||||
## Debug Console
|
||||
### hid_listen can't recognize device
|
||||
When debug console of your device is not ready you will see like this:
|
||||
|
||||
```
|
||||
Waiting for device:.........
|
||||
```
|
||||
|
||||
once the device is pluged in then *hid_listen* finds it you will get this message:
|
||||
|
||||
```
|
||||
Waiting for new device:.........................
|
||||
Listening:
|
||||
```
|
||||
|
||||
If you can't get this 'Listening:' message try building with `CONSOLE_ENABLE=yes` in [Makefile]
|
||||
|
||||
You may need privilege to access the device on OS like Linux.
|
||||
- try `sudo hid_listen`
|
||||
|
||||
### Can't get message on console
|
||||
Check:
|
||||
- *hid_listen* finds your device. See above.
|
||||
- Enable debug with pressing **Magic**+d. See [Magic Commands](https://github.com/tmk/tmk_keyboard#magic-commands).
|
||||
- set `debug_enable=true` usually in `matrix_init()` in **matrix.c**.
|
||||
- try using 'print' function instead of debug print. See **common/print.h**.
|
||||
- disconnect other devices with console function. See [Issue #97](https://github.com/tmk/tmk_keyboard/issues/97).
|
||||
|
||||
### Linux or UNIX like system requires Super User privilege
|
||||
Just use 'sudo' to execute *hid_listen* with privilege.
|
||||
```
|
||||
$ sudo hid_listen
|
||||
```
|
||||
|
||||
Or add an *udev rule* for TMK devices with placing a file in rules directory. The directory may vary on each system.
|
||||
|
||||
File: /etc/udev/rules.d/52-tmk-keyboard.rules(in case of Ubuntu)
|
||||
```
|
||||
# tmk keyboard products https://github.com/tmk/tmk_keyboard
|
||||
SUBSYSTEMS=="usb", ATTRS{idVendor}=="feed", MODE:="0666"
|
||||
```
|
||||
|
||||
## Software Issues
|
||||
|
||||
### NKRO Doesn't work
|
||||
First you have to compile frimware with this build option `NKRO_ENABLE` in **Makefile**.
|
||||
|
||||
Try `Magic` **N** command(`LShift+RShift+N` by default) when **NKRO** still doesn't work. You can use this command to toggle between **NKRO** and **6KRO** mode temporarily. In some situations **NKRO** doesn't work you need to switch to **6KRO** mode, in particular when you are in BIOS.
|
||||
|
||||
If your firmeare built with `BOOTMAGIC_ENABLE` you need to turn its switch on by `BootMagic` **N** command(`Space+N` by default). This setting is stored in EEPROM and keeped over power cycles.
|
||||
|
||||
https://github.com/tmk/tmk_keyboard#boot-magic-configuration---virtual-dip-switch
|
||||
|
||||
### Can't read column of matrix beyond 16
|
||||
Use `1UL<<16` instead of `1<<16` in `read_cols()` in [matrix.h] when your columns goes beyond 16.
|
||||
|
||||
In C `1` means one of [int] type which is [16bit] in case of AVR so you can't shift left more than 15. You will get unexpected zero when you say `1<<16`. You have to use [unsigned long] type with `1UL`.
|
||||
|
||||
http://deskthority.net/workshop-f7/rebuilding-and-redesigning-a-classic-thinkpad-keyboard-t6181-60.html#p146279
|
||||
|
||||
|
||||
### Bootloader jump doesn't work
|
||||
Properly configure bootloader size in **Makefile**. With wrong section size bootloader won't probably start with **Magic command** and **Boot Magic**.
|
||||
```
|
||||
# Size of Bootloaders in bytes:
|
||||
# Atmel DFU loader(ATmega32U4) 4096
|
||||
# Atmel DFU loader(AT90USB128) 8192
|
||||
# LUFA bootloader(ATmega32U4) 4096
|
||||
# Arduino Caterina(ATmega32U4) 4096
|
||||
# USBaspLoader(ATmega***) 2048
|
||||
# Teensy halfKay(ATmega32U4) 512
|
||||
# Teensy++ halfKay(AT90USB128) 2048
|
||||
OPT_DEFS += -DBOOTLOADER_SIZE=4096
|
||||
```
|
||||
AVR Boot section size are defined by setting **BOOTSZ** fuse in fact. Consult with your MCU datasheet.
|
||||
Note that **Word**(2 bytes) size and address are used in datasheet while TMK uses **Byte**.
|
||||
|
||||
AVR Boot section is located at end of Flash memory like the followings.
|
||||
```
|
||||
byte Atmel/LUFA(ATMega32u4) byte Atmel(AT90SUB1286)
|
||||
0x0000 +---------------+ 0x00000 +---------------+
|
||||
| | | |
|
||||
| | | |
|
||||
| Application | | Application |
|
||||
| | | |
|
||||
= = = =
|
||||
| | 32KB-4KB | | 128KB-8KB
|
||||
0x6000 +---------------+ 0x1E000 +---------------+
|
||||
| Bootloader | 4KB | Bootloader | 8KB
|
||||
0x7FFF +---------------+ 0x1FFFF +---------------+
|
||||
|
||||
|
||||
byte Teensy(ATMega32u4) byte Teensy++(AT90SUB1286)
|
||||
0x0000 +---------------+ 0x00000 +---------------+
|
||||
| | | |
|
||||
| | | |
|
||||
| Application | | Application |
|
||||
| | | |
|
||||
= = = =
|
||||
| | 32KB-512B | | 128KB-2KB
|
||||
0x7E00 +---------------+ 0x1FC00 +---------------+
|
||||
| Bootloader | 512B | Bootloader | 2KB
|
||||
0x7FFF +---------------+ 0x1FFFF +---------------+
|
||||
```
|
||||
|
||||
And see this discussion for further reference.
|
||||
https://github.com/tmk/tmk_keyboard/issues/179
|
||||
|
||||
|
||||
### Special Extra key doesn't work(System, Audio control keys)
|
||||
You need to define `EXTRAKEY_ENABLE` in `rules.mk` to use them in QMK.
|
||||
|
||||
```
|
||||
EXTRAKEY_ENABLE = yes # Audio control and System control
|
||||
```
|
||||
|
||||
### Wakeup from sleep doesn't work
|
||||
|
||||
In Windows check `Allow this device to wake the computer` setting in Power **Management property** tab of **Device Manager**. Also check BIOS setting.
|
||||
|
||||
Pressing any key during sleep should wake host.
|
||||
|
||||
## Hardware Issues
|
||||
|
||||
### TrackPoint needs reset circuit(PS/2 mouse support)
|
||||
Without reset circuit you will have inconsistent reuslt due to improper initialize of the hardware. See circuit schematic of TPM754.
|
||||
|
||||
- http://geekhack.org/index.php?topic=50176.msg1127447#msg1127447
|
||||
- http://www.mikrocontroller.net/attachment/52583/tpm754.pdf
|
||||
|
||||
### Using Arduino?
|
||||
|
||||
**Note that Arduino pin naming is different from actual chip.** For example, Arduino pin `D0` is not `PD0`. Check circuit with its schematics yourself.
|
||||
|
||||
- http://arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf
|
||||
- http://arduino.cc/en/uploads/Main/arduino-micro-schematic.pdf
|
||||
|
||||
Arduino leonardo and micro have **ATMega32U4** and can be used for TMK, though Arduino bootloader may be a problem.
|
||||
|
||||
### Using PF4-7 pins of USB AVR?
|
||||
You need to set JTD bit of MCUCR yourself to use PF4-7 as GPIO. Those pins are configured to serve JTAG function by default. MCUs like ATMega*U* or AT90USB* are affeteced with this.
|
||||
|
||||
If you are using Teensy this isn't needed. Teensy is shipped with JTAGEN fuse bit unprogrammed to disable the function.
|
||||
|
||||
See this code.
|
||||
```
|
||||
// JTAG disable for PORT F. write JTD bit twice within four cycles.
|
||||
MCUCR |= (1<<JTD);
|
||||
MCUCR |= (1<<JTD);
|
||||
```
|
||||
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hbkb/matrix.c#L67
|
||||
|
||||
And read **26.5.1 MCU Control Register – MCUCR** of ATMega32U4 datasheet.
|
||||
|
||||
|
||||
### Program Arduino Micro/Leonardo
|
||||
Push reset button and then run command like this within 8 seconds.
|
||||
|
||||
```
|
||||
avrdude -patmega32u4 -cavr109 -b57600 -Uflash:w:adb_usb.hex -P/dev/ttyACM0
|
||||
```
|
||||
|
||||
Device name will vary depending on your system.
|
||||
|
||||
http://arduino.cc/en/Main/ArduinoBoardMicro
|
||||
https://geekhack.org/index.php?topic=14290.msg1563867#msg1563867
|
||||
|
||||
### Problem on BIOS(UEFI)/Resume(Sleep&Wake)/Power cycles
|
||||
Some people reported their keyboard stops working on BIOS and/or after resume(power cycles).
|
||||
|
||||
As of now root of its cause is not clear but some build options seem to be related. In Makefile try to disable those options like `CONSOLE_ENABLE`, `NKRO_ENABLE`, `SLEEP_LED_ENABLE` and/or others.
|
||||
|
||||
https://github.com/tmk/tmk_keyboard/issues/266
|
||||
https://geekhack.org/index.php?topic=41989.msg1967778#msg1967778
|
||||
|
||||
## Flashing Problems
|
||||
|
||||
### Can't use dfu-programmer or QMK Flasher to flash on Windows
|
||||
|
||||
Windows requires a driver to support the keyboard in DFU mode. You can use [QMK Driver Installer](https://github.com/qmk/qmk_driver_installer/releases) to install the necessary drivers.
|
||||
* [General](faq_general.md)
|
||||
* [Building or Compiling QMK](faq_build.md)
|
||||
* [Debugging and Troubleshooting QMK](faq_debug.md)
|
||||
* [Keymap](faq_keymap.md)
|
||||
|
|
203
docs/faq_debug.md
Normal file
203
docs/faq_debug.md
Normal file
|
@ -0,0 +1,203 @@
|
|||
# Debugging FAQ
|
||||
|
||||
This page details various common questions people have about troubleshooting their keyboards.
|
||||
|
||||
# Debug Console
|
||||
|
||||
## hid_listen can't recognize device
|
||||
When debug console of your device is not ready you will see like this:
|
||||
|
||||
```
|
||||
Waiting for device:.........
|
||||
```
|
||||
|
||||
once the device is pluged in then *hid_listen* finds it you will get this message:
|
||||
|
||||
```
|
||||
Waiting for new device:.........................
|
||||
Listening:
|
||||
```
|
||||
|
||||
If you can't get this 'Listening:' message try building with `CONSOLE_ENABLE=yes` in [Makefile]
|
||||
|
||||
You may need privilege to access the device on OS like Linux.
|
||||
- try `sudo hid_listen`
|
||||
|
||||
## Can't get message on console
|
||||
Check:
|
||||
- *hid_listen* finds your device. See above.
|
||||
- Enable debug with pressing **Magic**+d. See [Magic Commands](https://github.com/tmk/tmk_keyboard#magic-commands).
|
||||
- set `debug_enable=true` usually in `matrix_init()` in **matrix.c**.
|
||||
- try using 'print' function instead of debug print. See **common/print.h**.
|
||||
- disconnect other devices with console function. See [Issue #97](https://github.com/tmk/tmk_keyboard/issues/97).
|
||||
|
||||
## Linux or UNIX like system requires Super User privilege
|
||||
Just use 'sudo' to execute *hid_listen* with privilege.
|
||||
```
|
||||
$ sudo hid_listen
|
||||
```
|
||||
|
||||
Or add an *udev rule* for TMK devices with placing a file in rules directory. The directory may vary on each system.
|
||||
|
||||
File: /etc/udev/rules.d/52-tmk-keyboard.rules(in case of Ubuntu)
|
||||
```
|
||||
# tmk keyboard products https://github.com/tmk/tmk_keyboard
|
||||
SUBSYSTEMS=="usb", ATTRS{idVendor}=="feed", MODE:="0666"
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
# Miscellaneous
|
||||
## NKRO Doesn't work
|
||||
First you have to compile frimware with this build option `NKRO_ENABLE` in **Makefile**.
|
||||
|
||||
Try `Magic` **N** command(`LShift+RShift+N` by default) when **NKRO** still doesn't work. You can use this command to toggle between **NKRO** and **6KRO** mode temporarily. In some situations **NKRO** doesn't work you need to switch to **6KRO** mode, in particular when you are in BIOS.
|
||||
|
||||
If your firmeare built with `BOOTMAGIC_ENABLE` you need to turn its switch on by `BootMagic` **N** command(`Space+N` by default). This setting is stored in EEPROM and keeped over power cycles.
|
||||
|
||||
https://github.com/tmk/tmk_keyboard#boot-magic-configuration---virtual-dip-switch
|
||||
|
||||
|
||||
## TrackPoint needs reset circuit(PS/2 mouse support)
|
||||
Without reset circuit you will have inconsistent reuslt due to improper initialize of the hardware. See circuit schematic of TPM754.
|
||||
|
||||
- http://geekhack.org/index.php?topic=50176.msg1127447#msg1127447
|
||||
- http://www.mikrocontroller.net/attachment/52583/tpm754.pdf
|
||||
|
||||
|
||||
## Can't read column of matrix beyond 16
|
||||
Use `1UL<<16` instead of `1<<16` in `read_cols()` in [matrix.h] when your columns goes beyond 16.
|
||||
|
||||
In C `1` means one of [int] type which is [16bit] in case of AVR so you can't shift left more than 15. You will get unexpected zero when you say `1<<16`. You have to use [unsigned long] type with `1UL`.
|
||||
|
||||
http://deskthority.net/workshop-f7/rebuilding-and-redesigning-a-classic-thinkpad-keyboard-t6181-60.html#p146279
|
||||
|
||||
|
||||
## Bootloader jump doesn't work
|
||||
Properly configure bootloader size in **Makefile**. With wrong section size bootloader won't probably start with **Magic command** and **Boot Magic**.
|
||||
```
|
||||
# Size of Bootloaders in bytes:
|
||||
# Atmel DFU loader(ATmega32U4) 4096
|
||||
# Atmel DFU loader(AT90USB128) 8192
|
||||
# LUFA bootloader(ATmega32U4) 4096
|
||||
# Arduino Caterina(ATmega32U4) 4096
|
||||
# USBaspLoader(ATmega***) 2048
|
||||
# Teensy halfKay(ATmega32U4) 512
|
||||
# Teensy++ halfKay(AT90USB128) 2048
|
||||
OPT_DEFS += -DBOOTLOADER_SIZE=4096
|
||||
```
|
||||
AVR Boot section size are defined by setting **BOOTSZ** fuse in fact. Consult with your MCU datasheet.
|
||||
Note that **Word**(2 bytes) size and address are used in datasheet while TMK uses **Byte**.
|
||||
|
||||
AVR Boot section is located at end of Flash memory like the followings.
|
||||
```
|
||||
byte Atmel/LUFA(ATMega32u4) byte Atmel(AT90SUB1286)
|
||||
0x0000 +---------------+ 0x00000 +---------------+
|
||||
| | | |
|
||||
| | | |
|
||||
| Application | | Application |
|
||||
| | | |
|
||||
= = = =
|
||||
| | 32KB-4KB | | 128KB-8KB
|
||||
0x6000 +---------------+ 0x1E000 +---------------+
|
||||
| Bootloader | 4KB | Bootloader | 8KB
|
||||
0x7FFF +---------------+ 0x1FFFF +---------------+
|
||||
|
||||
|
||||
byte Teensy(ATMega32u4) byte Teensy++(AT90SUB1286)
|
||||
0x0000 +---------------+ 0x00000 +---------------+
|
||||
| | | |
|
||||
| | | |
|
||||
| Application | | Application |
|
||||
| | | |
|
||||
= = = =
|
||||
| | 32KB-512B | | 128KB-2KB
|
||||
0x7E00 +---------------+ 0x1FC00 +---------------+
|
||||
| Bootloader | 512B | Bootloader | 2KB
|
||||
0x7FFF +---------------+ 0x1FFFF +---------------+
|
||||
```
|
||||
|
||||
And see this discussion for further reference.
|
||||
https://github.com/tmk/tmk_keyboard/issues/179
|
||||
|
||||
|
||||
## Special Extra key doesn't work(System, Audio control keys)
|
||||
You need to define `EXTRAKEY_ENABLE` in `rules.mk` to use them in QMK.
|
||||
|
||||
```
|
||||
EXTRAKEY_ENABLE = yes # Audio control and System control
|
||||
```
|
||||
|
||||
## Wakeup from sleep doesn't work
|
||||
|
||||
In Windows check `Allow this device to wake the computer` setting in Power **Management property** tab of **Device Manager**. Also check BIOS setting.
|
||||
|
||||
Pressing any key during sleep should wake host.
|
||||
|
||||
## Using Arduino?
|
||||
|
||||
**Note that Arduino pin naming is different from actual chip.** For example, Arduino pin `D0` is not `PD0`. Check circuit with its schematics yourself.
|
||||
|
||||
- http://arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf
|
||||
- http://arduino.cc/en/uploads/Main/arduino-micro-schematic.pdf
|
||||
|
||||
Arduino leonardo and micro have **ATMega32U4** and can be used for TMK, though Arduino bootloader may be a problem.
|
||||
|
||||
|
||||
## Using PF4-7 pins of USB AVR?
|
||||
You need to set JTD bit of MCUCR yourself to use PF4-7 as GPIO. Those pins are configured to serve JTAG function by default. MCUs like ATMega*U* or AT90USB* are affeteced with this.
|
||||
|
||||
If you are using Teensy this isn't needed. Teensy is shipped with JTAGEN fuse bit unprogrammed to disable the function.
|
||||
|
||||
See this code.
|
||||
```
|
||||
// JTAG disable for PORT F. write JTD bit twice within four cycles.
|
||||
MCUCR |= (1<<JTD);
|
||||
MCUCR |= (1<<JTD);
|
||||
```
|
||||
https://github.com/tmk/tmk_keyboard/blob/master/keyboard/hbkb/matrix.c#L67
|
||||
|
||||
And read **26.5.1 MCU Control Register – MCUCR** of ATMega32U4 datasheet.
|
||||
|
||||
|
||||
## Adding LED indicators of Lock keys
|
||||
You need your own LED indicators for CapsLock, ScrollLock and NumLock? See this post.
|
||||
|
||||
http://deskthority.net/workshop-f7/tmk-keyboard-firmware-collection-t4478-120.html#p191560
|
||||
|
||||
## Program Arduino Micro/Leonardo
|
||||
Push reset button and then run command like this within 8 seconds.
|
||||
|
||||
```
|
||||
avrdude -patmega32u4 -cavr109 -b57600 -Uflash:w:adb_usb.hex -P/dev/ttyACM0
|
||||
```
|
||||
|
||||
Device name will vary depending on your system.
|
||||
|
||||
http://arduino.cc/en/Main/ArduinoBoardMicro
|
||||
https://geekhack.org/index.php?topic=14290.msg1563867#msg1563867
|
||||
|
||||
|
||||
## USB 3 compatibility
|
||||
I heard some people have a problem with USB 3 port, try USB 2 port.
|
||||
|
||||
|
||||
## Mac compatibility
|
||||
### OS X 10.11 and Hub
|
||||
https://geekhack.org/index.php?topic=14290.msg1884034#msg1884034
|
||||
|
||||
|
||||
## Problem on BIOS(UEFI)/Resume(Sleep&Wake)/Power cycles
|
||||
Some people reported their keyboard stops working on BIOS and/or after resume(power cycles).
|
||||
|
||||
As of now root of its cause is not clear but some build options seem to be related. In Makefile try to disable those options like `CONSOLE_ENABLE`, `NKRO_ENABLE`, `SLEEP_LED_ENABLE` and/or others.
|
||||
|
||||
https://github.com/tmk/tmk_keyboard/issues/266
|
||||
https://geekhack.org/index.php?topic=41989.msg1967778#msg1967778
|
||||
|
||||
|
||||
|
||||
## FLIP doesn't work
|
||||
### AtLibUsbDfu.dll not found
|
||||
Remove current driver and reinstall one FLIP provides from DeviceManager.
|
||||
http://imgur.com/a/bnwzy
|
20
docs/faq_general.md
Normal file
20
docs/faq_general.md
Normal file
|
@ -0,0 +1,20 @@
|
|||
# Frequently Asked Questions
|
||||
|
||||
## What is QMK?
|
||||
|
||||
[QMK](https://github.com/qmk), short for Quantum Mechanical Keyboard, is a group of people building tools for custom keyboards. We started with the [QMK firmware](https://github.com/qmk/qmk_firmware), a heavily modified fork of [TMK](https://github.com/tmk/tmk_keyboard).
|
||||
|
||||
### Why the name Quantum?
|
||||
|
||||
<!-- FIXME -->
|
||||
|
||||
## What Differences Are There Between QMK and TMK?
|
||||
|
||||
TMK was originally designed and implemented by [Jun Wako](https://github.com/tmk). QMK started as [Jack Humbert's](https://github.com/jackhumbert) fork of TMK for the Planck. After a while Jack's fork had diverged quite a bit from TMK, and in 2015 Jack decided to rename his fork to QMK.
|
||||
|
||||
From a technical standpoint QMK builds upon TMK by adding several new features. Most notably QMK has expanded the number of available keycodes and uses these to implement advanced features like `S()`, `LCTL()`, and `MO()`. You can see a complete list of these keycodes in [Quantum Keycodes](quantum_keycodes.html).
|
||||
|
||||
From a project and community management standpoint TMK maintains all the officially supported keyboards by himself, with a bit of community support. Separate community maintained forks exist or can be created for other keyboards. Only a few keymaps are provided by default, so users typically don't share keymaps with each other. QMK encourages sharing of both keyboards and keymaps through a centrally managed repository, accepting all pull requests that follows the quality standards. These are mostly community maintained, but the QMK team also helps when necessary.
|
||||
|
||||
Both approaches have their merits and their drawbacks, and code flows freely between TMK and QMK when it makes sense.
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Frequently Asked Keymap Questions
|
||||
# Keymap FAQ
|
||||
|
||||
This page covers questions people often have about keymaps. If you haven't you should read [Keymap Overview](keymap.html) first.
|
||||
|
||||
|
|
|
@ -1,71 +1,10 @@
|
|||
# Build Environment Setup
|
||||
# Installing Build Tools
|
||||
|
||||
This page describes setting up the build environment for QMK. These instructions cover AVR processors (such as the atmega32u4.)
|
||||
|
||||
<!-- FIXME: We should have ARM instructions somewhere. -->
|
||||
|
||||
# Windows 10
|
||||
|
||||
## Creators Update
|
||||
If you have Windows 10 with Creators Update or later, you can build and flash the firmware directly. Before the Creators Update, only building was possible. If you don't have it yet or if are unsure, follow [these instructions](https://support.microsoft.com/en-us/instantanswers/d4efb316-79f0-1aa1-9ef3-dcada78f3fa0/get-the-windows-10-creators-update).
|
||||
|
||||
## Windows Subsystem for Linux
|
||||
In addition to the Creators Update, you need Windows 10 Subystem for Linux, so install it following [these instructions](http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/). If you already have the Windows 10 Subsystem for Linux from the Anniversary update it's recommended that you [upgrade](https://betanews.com/2017/04/14/upgrade-windows-subsystem-for-linux/) it to 16.04LTS, because some keyboards don't compile with the toolchains included in 14.04LTS. Note that you need to know what your are doing if you chose the `sudo do-release-upgrade` method.
|
||||
|
||||
## Git
|
||||
If you already have cloned the repository on your Windows file system you can ignore this section.
|
||||
|
||||
You will need to clone the repository to your Windows file system using the normal Git for Windows and **not** the WSL Git. So if you haven't installed Git before, [download](https://git-scm.com/download/win) and install it. Then [set it up](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup), it's important that you setup the e-mail and user name, especially if you are planning to contribute.
|
||||
|
||||
Once Git is installed, open the Git bash command and change the directory to where you want to clone QMK, note that you have to use forward slashes, and that your c drive is accessed like this `/c/path/to/where/you/want/to/go`. Then run `git clone --recurse-submodules https://github.com/qmk/qmk_firmware`, this will create a new folder `qmk_firmware` as a subfolder of the current one.
|
||||
|
||||
## Toolchain setup
|
||||
The Toolchain setup is done through the Windows Subsystem for Linux, and the process is fully automated. If you want to do everything manually, there are no other instructions than the scripts themselves, but you can always open issues and ask for more information.
|
||||
|
||||
1. Open "Bash On Ubuntu On Windows" from the start menu.
|
||||
2. Go to the directory where you cloned `qmk_firmware`. Note that the paths start with `/mnt/` in the WSL, so you have to write for example `cd /mnt/c/path/to/qmk_firmware`.
|
||||
3. Run `util/wsl_install.sh` and follow the on-screen instructions.
|
||||
4. Close the Bash command window, and re-open it.
|
||||
5. You are ready to compile and flash the firmware!
|
||||
|
||||
## Some important things to keep in mind
|
||||
* You can run `util/wsl_install.sh` again to get all the newest updates.
|
||||
* Your QMK repository need to be on a Windows file system path, since WSL can't run executables outside it.
|
||||
* The WSL Git is **not** compatible with the Windows Git, so use the Windows Git Bash or a windows Git GUI for all Git operations
|
||||
* You can edit files either inside WSL or normally using Windows, but note that if you edit makefiles or shell scripts, make sure you are using an editor that saves the files with Unix line endings. Otherwise the compilation might not work.
|
||||
|
||||
# Windows (Vista and later)
|
||||
1. If you have ever installed WinAVR, uninstall it.
|
||||
2. Install [MHV AVR Tools](https://infernoembedded.com/sites/default/files/project/MHV_AVR_Tools_20131101.exe). Disable smatch, but **be sure to leave the option to add the tools to the PATH checked**.
|
||||
3. If you are going to flash Infinity based keyboards you will need to install dfu-util, refer to the instructions by [Input Club](https://github.com/kiibohd/controller/wiki/Loading-DFU-Firmware).
|
||||
4. Install [MinGW](https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download). During installation, uncheck the option to install a graphical user interface. **DO NOT change the default installation folder.** The scripts depend on the default location.
|
||||
5. Clone this repository. [This link will download it as a zip file, which you'll need to extract.](https://github.com/qmk/qmk_firmware/archive/master.zip) Open the extracted folder in Windows Explorer.
|
||||
6. Open the `\util` folder.
|
||||
7. Double-click on the `1-setup-path-win` batch script to run it. You'll need to accept a User Account Control prompt. Press the spacebar to dismiss the success message in the command prompt that pops up.
|
||||
8. Right-click on the `2-setup-environment-win` batch script, select "Run as administrator", and accept the User Account Control prompt. This part may take a couple of minutes, and you'll need to approve a driver installation, but once it finishes, your environment is complete!
|
||||
|
||||
If you have trouble and want to ask for help, it is useful to generate a *Win_Check_Output.txt* file by running `Win_Check.bat` in the `\util` folder.
|
||||
|
||||
# Mac
|
||||
If you're using [homebrew,](http://brew.sh/) you can use the following commands:
|
||||
|
||||
brew tap osx-cross/avr
|
||||
brew install avr-gcc
|
||||
brew install dfu-programmer
|
||||
|
||||
This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line. Note that the `make` and `make install` portion during the homebrew installation of avr-gcc can take over 20 minutes and exhibit high CPU usage.
|
||||
|
||||
You can also try these instructions:
|
||||
|
||||
1. Install Xcode from the App Store.
|
||||
2. Install the Command Line Tools from `Xcode->Preferences->Downloads`.
|
||||
3. Install [DFU-Programmer](https://dfu-programmer.github.io/).
|
||||
|
||||
If you are going to flash Infinity based keyboards you will also need dfu-util
|
||||
|
||||
brew install dfu-util
|
||||
|
||||
# Linux
|
||||
## 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`.**
|
||||
|
||||
|
@ -97,7 +36,72 @@ Debian/Ubuntu example:
|
|||
sudo apt-get update
|
||||
sudo apt-get install gcc unzip wget zip gcc-avr binutils-avr avr-libc dfu-programmer dfu-util gcc-arm-none-eabi binutils-arm-none-eabi libnewlib-arm-none-eabi
|
||||
|
||||
# Docker
|
||||
# Mac
|
||||
If you're using [homebrew,](http://brew.sh/) you can use the following commands:
|
||||
|
||||
brew tap osx-cross/avr
|
||||
brew install avr-libc
|
||||
brew install dfu-programmer
|
||||
|
||||
This is the recommended method. If you don't have homebrew, [install it!](http://brew.sh/) It's very much worth it for anyone who works in the command line. Note that the `make` and `make install` portion during the homebrew installation of avr-libc can take over 20 minutes and exhibit high CPU usage.
|
||||
|
||||
## Windows with msys2 (recommended)
|
||||
|
||||
The best environment to use, for Windows Vista through any later version (tested on 7 and 10,) is [msys2](http://www.msys2.org).
|
||||
|
||||
* Install msys2 by downloading and following the instructions here: http://www.msys2.org
|
||||
* Open the "MSYS2 MingGW 64-bit" shortcut
|
||||
* Navigate to your qmk checkout. For example, if it's in the root of your c drive:
|
||||
* `$ cd /c/qmk_firmware`
|
||||
* Run `util/msys2_install.sh` and follow the prompts
|
||||
|
||||
## Windows 10 (deprecated)
|
||||
These are the old instructions for Windows 10. We recommend you use [MSYS2 as outlined above](#windows-with-msys2-recommended).
|
||||
|
||||
### Creators Update
|
||||
If you have Windows 10 with Creators Update or later, you can build and flash the firmware directly. Before the Creators Update, only building was possible. If you don't have it yet or if are unsure, follow [these instructions](https://support.microsoft.com/en-us/instantanswers/d4efb316-79f0-1aa1-9ef3-dcada78f3fa0/get-the-windows-10-creators-update).
|
||||
|
||||
### Windows Subsystem for Linux
|
||||
In addition to the Creators Update, you need Windows 10 Subystem for Linux, so install it following [these instructions](http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/). If you already have the Windows 10 Subsystem for Linux from the Anniversary update it's recommended that you [upgrade](https://betanews.com/2017/04/14/upgrade-windows-subsystem-for-linux/) it to 16.04LTS, because some keyboards don't compile with the toolchains included in 14.04LTS. Note that you need to know what your are doing if you chose the `sudo do-release-upgrade` method.
|
||||
|
||||
### Git
|
||||
If you already have cloned the repository on your Windows file system you can ignore this section.
|
||||
|
||||
You will need to clone the repository to your Windows file system using the normal Git for Windows and **not** the WSL Git. So if you haven't installed Git before, [download](https://git-scm.com/download/win) and install it. Then [set it up](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup), it's important that you setup the e-mail and user name, especially if you are planning to contribute.
|
||||
|
||||
Once Git is installed, open the Git bash command and change the directory to where you want to clone QMK, note that you have to use forward slashes, and that your c drive is accessed like this `/c/path/to/where/you/want/to/go`. Then run `git clone --recurse-submodules https://github.com/qmk/qmk_firmware`, this will create a new folder `qmk_firmware` as a subfolder of the current one.
|
||||
|
||||
### Toolchain setup
|
||||
The Toolchain setup is done through the Windows Subsystem for Linux, and the process is fully automated. If you want to do everything manually, there are no other instructions than the scripts themselves, but you can always open issues and ask for more information.
|
||||
|
||||
1. Open "Bash On Ubuntu On Windows" from the start menu.
|
||||
2. Go to the directory where you cloned `qmk_firmware`. Note that the paths start with `/mnt/` in the WSL, so you have to write for example `cd /mnt/c/path/to/qmk_firmware`.
|
||||
3. Run `util/wsl_install.sh` and follow the on-screen instructions.
|
||||
4. Close the Bash command window, and re-open it.
|
||||
5. You are ready to compile and flash the firmware!
|
||||
|
||||
### Some important things to keep in mind
|
||||
* You can run `util/wsl_install.sh` again to get all the newest updates.
|
||||
* Your QMK repository need to be on a Windows file system path, since WSL can't run executables outside it.
|
||||
* The WSL Git is **not** compatible with the Windows Git, so use the Windows Git Bash or a windows Git GUI for all Git operations
|
||||
* You can edit files either inside WSL or normally using Windows, but note that if you edit makefiles or shell scripts, make sure you are using an editor that saves the files with Unix line endings. Otherwise the compilation might not work.
|
||||
|
||||
## Windows (Vista and later)
|
||||
|
||||
These are the old instructions for Windows Vista and later. We recommend you use [MSYS2 as outlined above](#windows-with-msys2-recommended).
|
||||
|
||||
1. If you have ever installed WinAVR, uninstall it.
|
||||
2. Install [MHV AVR Tools](https://infernoembedded.com/sites/default/files/project/MHV_AVR_Tools_20131101.exe). Disable smatch, but **be sure to leave the option to add the tools to the PATH checked**.
|
||||
3. If you are going to flash Infinity based keyboards you will need to install dfu-util, refer to the instructions by [Input Club](https://github.com/kiibohd/controller/wiki/Loading-DFU-Firmware).
|
||||
4. Install [MinGW](https://sourceforge.net/projects/mingw/files/Installer/mingw-get-setup.exe/download). During installation, uncheck the option to install a graphical user interface. **DO NOT change the default installation folder.** The scripts depend on the default location.
|
||||
5. Clone this repository. [This link will download it as a zip file, which you'll need to extract.](https://github.com/qmk/qmk_firmware/archive/master.zip) Open the extracted folder in Windows Explorer.
|
||||
6. Open the `\util` folder.
|
||||
7. Double-click on the `1-setup-path-win` batch script to run it. You'll need to accept a User Account Control prompt. Press the spacebar to dismiss the success message in the command prompt that pops up.
|
||||
8. Right-click on the `2-setup-environment-win` batch script, select "Run as administrator", and accept the User Account Control prompt. This part may take a couple of minutes, and you'll need to approve a driver installation, but once it finishes, your environment is complete!
|
||||
|
||||
If you have trouble and want to ask for help, it is useful to generate a *Win_Check_Output.txt* file by running `Win_Check.bat` in the `\util` folder.
|
||||
|
||||
## 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 command at the root of the QMK folder to build a keyboard/keymap:
|
||||
|
||||
|
@ -115,11 +119,5 @@ docker run -e keymap=default -e subproject=ez -e keyboard=ergobox --rm -v D:/Use
|
|||
|
||||
This will compile the targeted keyboard/keymap and leave it in your QMK directory for you to flash.
|
||||
|
||||
# Vagrant
|
||||
## 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](vagrant_guide.md).
|
||||
|
||||
# Verify Your Installation
|
||||
1. If you haven't already, obtain this repository ([https://github.com/qmk/qmk_firmware](https://github.com/qmk/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.
|
||||
2. Open up a terminal or command prompt and navigate to the `qmk_firmware` folder using the `cd` command. The command prompt will typically open to your home directory. If, for example, you cloned the repository to your Documents folder, then you would type `cd Documents/qmk_firmware`. If you extracted the file from a zip, then it may be named `qmk_firmware-master` instead.
|
||||
3. To confirm that you're in the correct location, you can display the contents of your current folder using the `dir` command on Windows, or the `ls` command on Linux or Mac. You should see several files, including `readme.md` and a `quantum` folder. From here, you need to navigate to the appropriate folder under `keyboards/`. For example, if you're building for a Planck, run `cd keyboards/planck`.
|
||||
4. Once you're in the correct keyboard-specific folder, run the `make` command. This should output a lot of information about the build process. More information about the `make` command can be found below.
|
47
docs/getting_started_instroduction.md
Normal file
47
docs/getting_started_instroduction.md
Normal file
|
@ -0,0 +1,47 @@
|
|||
# Introduction
|
||||
|
||||
This page attempts to explain the basic information you need to know to work with the QMK project. It assumes that you are familiar with navigating a UNIX shell, but does not assume you are familiar with C or with compiling using make.
|
||||
|
||||
## Basic QMK structure
|
||||
|
||||
QMK is a fork of @tmk's [tmk_keyboard](https://github.com/tmk/tmk_keyboard) project. The original TMK code, with modifications, can be found in the `tmk` folder. The QMK additions to the project may be found in the `quantum` folder. Keyboard projects may be found in the `handwired` and `keyboard` folders.
|
||||
|
||||
### Keyboard project structure
|
||||
|
||||
Within the `handwired` and `keyboard` folders is a directory for each keyboard project, for example `qmk_firmware/keyboards/clueboard`. Within you'll find the following structure:
|
||||
|
||||
* `keymaps/`: Different keymaps that can be built
|
||||
* `rules.mk`: The file that sets the default "make" options. Do not edit this file directly, instead use a keymap specific `Makefile`.
|
||||
* `config.h`: The file that sets the default compile time options. Do not edit this file directly, instead use a keymap specific `config.h`.
|
||||
|
||||
### Keymap structure
|
||||
|
||||
In every keymap folder, the following files may be found. Only `keymap.c` is required, if the rest of the files are not found the default options will be chosen.
|
||||
|
||||
* `config.h`: the options to configure your keymap
|
||||
* `keymap.c`: all of your keymap code, required
|
||||
* `rules.mk`: the features of QMK that are enabled
|
||||
* `readme.md`: a description of your keymap, how others might use it, and explanations of features. Please upload images to a service like imgur.
|
||||
|
||||
# The `config.h` file
|
||||
|
||||
There are 2 `config.h` locations:
|
||||
|
||||
* keyboard (`/keyboards/<keyboard>/config.h`)
|
||||
* keymap (`/keyboards/<keyboard>/keymaps/<keymap>/config.h`)
|
||||
|
||||
If the keymap `config.h` exists that file is included by the build system and the keyboard `config.h` is not included. If you wish to override settings in your keymap's `config.h` you will need to include some glue code:
|
||||
|
||||
```
|
||||
#ifndef CONFIG_USER_H
|
||||
#define CONFIG_USER_H
|
||||
|
||||
#include "../../config.h"
|
||||
```
|
||||
|
||||
If you want to override a setting from the parent `config.h` file, you need to `#undef` and then `#define` the setting again, like this:
|
||||
|
||||
```c
|
||||
#undef MY_SETTING
|
||||
#define MY_SETTING 4
|
||||
```
|
|
@ -1,75 +0,0 @@
|
|||
# QMK Overview
|
||||
|
||||
This page attempts to explain the basic information you need to know to work with the QMK project. It assumes that you are familiar with navigating a UNIX shell, but does not assume you are familiar with C or with compiling using make.
|
||||
|
||||
# Basic QMK structure
|
||||
|
||||
QMK is a fork of @tmk's [tmk_keyboard](https://github.com/tmk/tmk_keyboard) project. The original TMK code, with modifications, can be found in the `tmk` folder. The QMK additions to the project may be found in the `quantum` folder. Keyboard projects may be found in the `handwired` and `keyboard` folders.
|
||||
|
||||
## Keyboard project structure
|
||||
|
||||
Within the `handwired` and `keyboard` folders is a directory for each keyboard project, for example `qmk_firmware/keyboards/clueboard`. Within you'll find the following structure:
|
||||
|
||||
* `keymaps/`: Different keymaps that can be built
|
||||
* `rules.mk`: The file that sets the default "make" options. Do not edit this file directly, instead use a keymap specific `Makefile`.
|
||||
* `config.h`: The file that sets the default compile time options. Do not edit this file directly, instead use a keymap specific `config.h`.
|
||||
|
||||
### Keymap structure
|
||||
|
||||
In every keymap folder, the following files may be found. Only `keymap.c` is required, if the rest of the files are not found the default options will be chosen.
|
||||
|
||||
* `config.h`: the options to configure your keymap
|
||||
* `keymap.c`: all of your keymap code, required
|
||||
* `Makefile`: the features of QMK that are enabled, required to run `make` in your keymap folder
|
||||
* `readme.md`: a description of your keymap, how others might use it, and explanations of features
|
||||
* Other files: Some people choose to include an image depicting the layout, and other files that help people to use or understand a particular keymap.
|
||||
|
||||
# The `make` command
|
||||
|
||||
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). It it recommended that you always run make from within the `root` folder.
|
||||
|
||||
**NOTE:** To abort a make command press `Ctrl-c`
|
||||
|
||||
For more details on the QMK build process see [Make Instructions](make_instructions.md).
|
||||
|
||||
### Simple instructions for building and uploading a keyboard
|
||||
|
||||
**Most keyboards have more specific instructions in the keyboard specific readme.md file, so please check that first**
|
||||
|
||||
1. Enter the `root` folder
|
||||
2. Run `make <keyboard>-<subproject>-<keymap>-<programmer>`
|
||||
|
||||
In the above commands, replace:
|
||||
|
||||
* `<keyboard>` with the name of your keyboard
|
||||
* `<keymap>` with the name of your keymap
|
||||
* `<subproject>` with the name of the subproject (revision or sub-model of your keyboard). For example, for Ergodox it can be `ez` or `infinity`, and for Planck `rev3` or `rev4`.
|
||||
* If the keyboard doesn't have a subproject, or if you are happy with the default (defined in `rules.mk` file of the `keyboard` folder), you can leave it out. But remember to also remove the dash (`-`) from the command.
|
||||
* `<programmer>` The programmer to use. Most keyboards use `dfu`, but some use `teensy`. Infinity keyboards use `dfu-util`. Check the readme file in the keyboard folder to find out which programmer to use.
|
||||
* If you don't add `-<programmer` to the command line, the firmware will be still be compiled into a hex file, but the upload will be skipped.
|
||||
|
||||
**NOTE:** Some operating systems will refuse to program unless you run the make command as root for example `sudo make clueboard-default-dfu`
|
||||
|
||||
## Make Examples
|
||||
|
||||
* Build all Clueboard keymaps: `make clueboard`
|
||||
* Build the default Planck keymap: `make planck-rev4-default`
|
||||
* Build and flash your ergodox-ez: `make ergodox-ez-default-teensy`
|
||||
|
||||
# The `config.h` file
|
||||
|
||||
There are 2 `config.h` locations:
|
||||
|
||||
* keyboard (`/keyboards/<keyboard>/`)
|
||||
* keymap (`/keyboards/<keyboard>/keymaps/<keymap>/`)
|
||||
|
||||
The keyboard `config.h` is included only if the keymap one doesn't exist. The format to use for your custom one [is here](https://github.com/qmk/qmk_firmware/blob/master/doc/keymap_config_h_example.h). If you want to override a setting from the parent `config.h` file, you need to do this:
|
||||
|
||||
```c
|
||||
#undef MY_SETTING
|
||||
#define MY_SETTING 4
|
||||
```
|
||||
|
||||
For a value of `4` for this imaginary setting. So we `undef` it first, then `define` it.
|
||||
|
||||
You can then override any settings, rather than having to copy and paste the whole thing.
|
Loading…
Reference in a new issue