import { _ as _export_sfc, c as createElementBlock, o as openBlock, a8 as createStaticVNode } from "./chunks/framework.B9AX-CPi.js"; const __pageData = JSON.parse('{"title":"Configuring QMK","description":"","frontmatter":{},"headers":[],"relativePath":"config_options.md","filePath":"config_options.md","lastUpdated":null}'); const _sfc_main = { name: "config_options.md" }; const _hoisted_1 = /* @__PURE__ */ createStaticVNode('

Configuring QMK

QMK is nearly infinitely configurable. Wherever possible we err on the side of allowing users to customize their keyboard, even at the expense of code size. That level of flexibility makes for a daunting configuration experience, however.

There are three main types of configuration files in QMK:

This page will only discuss the first two types, config.h and rules.mk.

TIP

While not all settings have data-driven equivalents yet, keyboard makers are encouraged to utilize the info.json file to set the metadata for their boards when possible. See the info.json Format page for more details.

These files exist at various levels in QMK and all files of the same type are combined to build the final configuration. The levels, from lowest priority to highest priority, are:

QMK Default

Every available setting in QMK has a default. If that setting is not set at the Keyboard, Folder, or Keymap level this is the setting that will be used.

Keyboard

This level contains config options that should apply to the whole keyboard. Some settings won't change in revisions, or most keymaps. Other settings are merely defaults for this keyboard and can be overridden by folders and/or keymaps.

Folders

Some keyboards have folders and sub-folders to allow for different hardware configurations. Most keyboards only go 1 folder deep, but QMK supports structures up to 5 folders deep. Each folder can have its own config.h and rules.mk files that are incorporated into the final configuration.

Keymap

This level contains all of the options for that particular keymap. If you wish to override a previous declaration, you can use #undef <variable> to undefine it, where you can then redefine it without an error.

The config.h File

This is a C header file that is one of the first things included, and will persist over the whole project (if included). Lots of variables can be set here and accessed elsewhere. The config.h file shouldn't be including other config.h files.

Hardware Options

Features That Can Be Disabled

If you define these options you will disable the associated feature, which can save on code size.

Features That Can Be Enabled

If you define these options you will enable the associated feature, which may increase your code size.

Behaviors That Can Be Configured

RGB Light Configuration

Mouse Key Options

Split Keyboard Options

Split Keyboard specific options, make sure you have 'SPLIT_KEYBOARD = yes' in your rules.mk

Setting Handedness

One thing to remember, the side that the USB port is plugged into is always the master half. The side not plugged into USB is the slave.

There are a few different ways to set handedness for split keyboards (listed in order of precedence):

  1. Set SPLIT_HAND_PIN: Reads a pin to determine handedness. If pin is high, it's the left side, if low, the half is determined to be the right side
  2. Set EE_HANDS and flash eeprom-lefthand.eep/eeprom-righthand.eep to each half
  3. Set MASTER_RIGHT: Half that is plugged into the USB port is determined to be the master and right half (inverse of the default)
  4. Default: The side that is plugged into the USB port is the master half and is assumed to be the left half. The slave side is the right half

Defines for handedness

Other Options

The rules.mk File

This is a make file that is included by the top-level Makefile. It is used to set some information about the MCU that we will be compiling for as well as enabling and disabling certain features.

Build Options

AVR MCU Options

Feature Options

Use these to enable or disable building certain features. The more you have enabled the bigger your firmware will be, and you run the risk of building a firmware too large for your MCU.

USB Endpoint Limitations

In order to provide services over USB, QMK has to use USB endpoints. These are a finite resource: each microcontroller has only a certain number. This limits what features can be enabled together. If the available endpoints are exceeded, a build error is thrown.

The following features can require separate endpoints:

In order to improve utilisation of the endpoints, the HID features can be combined to use a single endpoint. By default, MOUSEKEY, EXTRAKEY, and NKRO are combined into a single endpoint.

The base keyboard functionality can also be combined into the endpoint, by setting KEYBOARD_SHARED_EP = yes. This frees up one more endpoint, but it can prevent the keyboard working in some BIOSes, as they do not implement Boot Keyboard protocol switching.

Combining the mouse also breaks Boot Mouse compatibility. The mouse can be uncombined by setting MOUSE_SHARED_EP = no if this functionality is required.

', 59); const _hoisted_60 = [ _hoisted_1 ]; function _sfc_render(_ctx, _cache, $props, $setup, $data, $options) { return openBlock(), createElementBlock("div", null, _hoisted_60); } const config_options = /* @__PURE__ */ _export_sfc(_sfc_main, [["render", _sfc_render]]); export { __pageData, config_options as default };