mirror of
https://github.com/qmk/qmk_firmware.git
synced 2025-02-27 01:56:43 +00:00
16 lines
10 KiB
JavaScript
16 lines
10 KiB
JavaScript
|
import { _ as _export_sfc, c as createElementBlock, o as openBlock, a8 as createStaticVNode } from "./chunks/framework.DyMmIvSC.js";
|
|||
|
const __pageData = JSON.parse('{"title":"Data Driven Configuration","description":"","frontmatter":{},"headers":[],"relativePath":"data_driven_config.md","filePath":"data_driven_config.md"}');
|
|||
|
const _sfc_main = { name: "data_driven_config.md" };
|
|||
|
const _hoisted_1 = /* @__PURE__ */ createStaticVNode('<h1 id="data-driven-configuration" tabindex="-1">Data Driven Configuration <a class="header-anchor" href="#data-driven-configuration" aria-label="Permalink to "Data Driven Configuration""></a></h1><p>This page describes how QMK's data driven JSON configuration system works. It is aimed at developers who want to work on QMK itself.</p><h2 id="history" tabindex="-1">History <a class="header-anchor" href="#history" aria-label="Permalink to "History""></a></h2><p>Historically QMK has been configured through a combination of two mechanisms- <code>rules.mk</code> and <code>config.h</code>. While this worked well when QMK was only a handful of keyboards we've grown to encompass nearly 4000 supported keyboards. That extrapolates out to 6000 configuration files under <code>keyboards/</code> alone! The freeform nature of these files and the unique patterns people have used to avoid duplication have made ongoing maintenance a challenge, and a large number of our keyboards follow patterns that are outdated and sometimes harder to understand.</p><p>We have also been working on bringing the power of QMK to people who aren't comformable with a CLI, and other projects such as VIA are working to make using QMK as easy as installing a program. These tools need information about how a keyboard is laid out or what pins and features are available so that users can take full advantage of QMK. We introduced <code>info.json</code> as a first step towards this. The QMK API is an effort to combine these 3 sources of information- <code>config.h</code>, <code>rules.mk</code>, and <code>info.json</code>- into a single source of truth that end-user tools can use.</p><p>Now we have support for generating <code>rules.mk</code> and <code>config.h</code> values from <code>info.json</code>, allowing us to have a single source of truth. This will allow us to use automated tooling to maintain keyboards saving a lot of time and maintenance work.</p><h2 id="overview" tabindex="-1">Overview <a class="header-anchor" href="#overview" aria-label="Permalink to "Overview""></a></h2><p>On the C side of things nothing changes. When you need to create a new rule or define you follow the same process:</p><ol><li>Add it to <code>docs/config_options.md</code></li><li>Set a default in the appropriate core file</li><li>Add your ifdef statements as needed</li></ol><p>You will then need to add support for your new configuration to <code>info.json</code>. The basic process is:</p><ol><li>Add it to the schema in <code>data/schemas/keyboards.jsonschema</code></li><li>Add a mapping in <code>data/maps</code></li><li>(optional and discouraged) Add code to extract/generate it to:</li></ol><ul><li><code>lib/python/qmk/info.py</code></li><li><code>lib/python/qmk/cli/generate/config_h.py</code></li><li><code>lib/python/qmk/cli/generate/rules_mk.py</code></li></ul><h2 id="adding-an-option-to-info-json" tabindex="-1">Adding an option to info.json <a class="header-anchor" href="#adding-an-option-to-info-json" aria-label="Permalink to "Adding an option to info.json""></a></h2><p>This section describes adding support for a <code>config.h</code>/<code>rules.mk</code> value to info.json.</p><h3 id="add-it-to-the-schema" tabindex="-1">Add it to the schema <a class="header-anchor" href="#add-it-to-the-schema" aria-label="Permalink to "Add it to the schema""></a></h3><p>QMK maintains <a href="https://json-schema.org/" target="_blank" rel="noreferrer">jsonschema</a> files in <code>data/schemas</code>. The values that go into keyboard-specific <code>info.json</code> files are kept in <code>keyboard.jsonschema</code>. Any value you want to make available to end users to edit must go in here.</p><p>In some cases you can simply add a new top-level key. Some examples to follow are <code>keyboard_name</code>, <code>maintainer</code>, <code>processor</code>, and <code>url</code>. This is appropriate when your option is self-contained and not directly related to other optio
|
|||
|
const _hoisted_39 = [
|
|||
|
_hoisted_1
|
|||
|
];
|
|||
|
function _sfc_render(_ctx, _cache, $props, $setup, $data, $options) {
|
|||
|
return openBlock(), createElementBlock("div", null, _hoisted_39);
|
|||
|
}
|
|||
|
const data_driven_config = /* @__PURE__ */ _export_sfc(_sfc_main, [["render", _sfc_render]]);
|
|||
|
export {
|
|||
|
__pageData,
|
|||
|
data_driven_config as default
|
|||
|
};
|