mirror of
https://github.com/qmk/qmk_firmware.git
synced 2025-04-26 17:11:28 +00:00
Deploying to gh-pages from @ qmk/qmk_firmware@959f4cbb62 🚀
This commit is contained in:
parent
41bae9f114
commit
b6a10ac6c0
@ -21,7 +21,7 @@ This service is an asynchronous API for compiling custom keymaps. You POST some
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports mulitple `LAYOUT` macros you can specify which macro to use.
|
As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports multiple `LAYOUT` macros you can specify which macro to use.
|
||||||
|
|
||||||
## Submitting a Compile Job
|
## Submitting a Compile Job
|
||||||
|
|
||||||
|
@ -223,7 +223,7 @@ Check your environment and report problems only:
|
|||||||
|
|
||||||
## `qmk format-json`
|
## `qmk format-json`
|
||||||
|
|
||||||
Formats a JSON file in a (mostly) human-friendly way. Will usually correctly detect the format of the JSON (info.json or keymap.json) but you can override this with `--format` if neccesary.
|
Formats a JSON file in a (mostly) human-friendly way. Will usually correctly detect the format of the JSON (info.json or keymap.json) but you can override this with `--format` if necessary.
|
||||||
|
|
||||||
**Usage**:
|
**Usage**:
|
||||||
|
|
||||||
|
@ -162,7 +162,7 @@ del(cli.config.<section>.<key>)
|
|||||||
|
|
||||||
## Writing The Configuration File
|
## Writing The Configuration File
|
||||||
|
|
||||||
The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberitely using `qmk config`.
|
The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberately using `qmk config`.
|
||||||
|
|
||||||
You can use `cli.save_config()` to write out the configuration.
|
You can use `cli.save_config()` to write out the configuration.
|
||||||
|
|
||||||
|
@ -24,7 +24,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
|
|||||||
* Readability is more important than consistency.
|
* Readability is more important than consistency.
|
||||||
* Follow the file's existing style. If the file is mixed, follow the style that makes sense for the section you are modifying.
|
* Follow the file's existing style. If the file is mixed, follow the style that makes sense for the section you are modifying.
|
||||||
* When indenting, keep the hash at the start of the line and add whitespace between `#` and `if`, starting with 4 spaces after the `#`.
|
* When indenting, keep the hash at the start of the line and add whitespace between `#` and `if`, starting with 4 spaces after the `#`.
|
||||||
* You can follow the indention level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
|
* You can follow the indentation level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
|
||||||
|
|
||||||
Here is an example for easy reference:
|
Here is an example for easy reference:
|
||||||
|
|
||||||
|
@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
Most of our style follows PEP8 with some local modifications to make things less nit-picky.
|
Most of our style follows PEP8 with some local modifications to make things less nit-picky.
|
||||||
|
|
||||||
* We target Python 3.7 for compatability with all supported platforms.
|
* We target Python 3.7 for compatibility with all supported platforms.
|
||||||
* We indent using four (4) spaces (soft tabs)
|
* We indent using four (4) spaces (soft tabs)
|
||||||
* We encourage liberal use of comments
|
* We encourage liberal use of comments
|
||||||
* Think of them as a story describing the feature
|
* Think of them as a story describing the feature
|
||||||
@ -21,7 +21,7 @@ You can use [yapf](https://github.com/google/yapf) to style your code. We provid
|
|||||||
|
|
||||||
We don't have a hard and fast rule for when to use `import ...` vs `from ... import ...`. Understandability and maintainability is our ultimate goal.
|
We don't have a hard and fast rule for when to use `import ...` vs `from ... import ...`. Understandability and maintainability is our ultimate goal.
|
||||||
|
|
||||||
Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatability module.
|
Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatibility module.
|
||||||
|
|
||||||
Imports should be one line per module. We group import statements together using the standard python rules- system, 3rd party, local.
|
Imports should be one line per module. We group import statements together using the standard python rules- system, 3rd party, local.
|
||||||
|
|
||||||
|
@ -195,7 +195,7 @@ If you define these options you will enable the associated feature, which may in
|
|||||||
* `#define COMBO_TERM 200`
|
* `#define COMBO_TERM 200`
|
||||||
* how long for the Combo keys to be detected. Defaults to `TAPPING_TERM` if not defined.
|
* how long for the Combo keys to be detected. Defaults to `TAPPING_TERM` if not defined.
|
||||||
* `#define COMBO_MUST_HOLD_MODS`
|
* `#define COMBO_MUST_HOLD_MODS`
|
||||||
* Flag for enabling extending timeout on Combos containing modifers
|
* Flag for enabling extending timeout on Combos containing modifiers
|
||||||
* `#define COMBO_MOD_TERM 200`
|
* `#define COMBO_MOD_TERM 200`
|
||||||
* Allows for extending COMBO_TERM for mod keys while mid-combo.
|
* Allows for extending COMBO_TERM for mod keys while mid-combo.
|
||||||
* `#define COMBO_MUST_HOLD_PER_COMBO`
|
* `#define COMBO_MUST_HOLD_PER_COMBO`
|
||||||
|
@ -374,7 +374,7 @@ This will clear all keys besides the mods currently pressed.
|
|||||||
This macro will register `KC_LALT` and tap `KC_TAB`, then wait for 1000ms. If the key is tapped again, it will send another `KC_TAB`; if there is no tap, `KC_LALT` will be unregistered, thus allowing you to cycle through windows.
|
This macro will register `KC_LALT` and tap `KC_TAB`, then wait for 1000ms. If the key is tapped again, it will send another `KC_TAB`; if there is no tap, `KC_LALT` will be unregistered, thus allowing you to cycle through windows.
|
||||||
|
|
||||||
```c
|
```c
|
||||||
bool is_alt_tab_active = false; // ADD this near the begining of keymap.c
|
bool is_alt_tab_active = false; // ADD this near the beginning of keymap.c
|
||||||
uint16_t alt_tab_timer = 0; // we will be using them soon.
|
uint16_t alt_tab_timer = 0; // we will be using them soon.
|
||||||
|
|
||||||
enum custom_keycodes { // Make sure have the awesome keycode ready
|
enum custom_keycodes { // Make sure have the awesome keycode ready
|
||||||
|
@ -259,12 +259,12 @@ void oled_render(void);
|
|||||||
void oled_set_cursor(uint8_t col, uint8_t line);
|
void oled_set_cursor(uint8_t col, uint8_t line);
|
||||||
|
|
||||||
// Advances the cursor to the next page, writing ' ' if true
|
// Advances the cursor to the next page, writing ' ' if true
|
||||||
// Wraps to the begining when out of bounds
|
// Wraps to the beginning when out of bounds
|
||||||
void oled_advance_page(bool clearPageRemainder);
|
void oled_advance_page(bool clearPageRemainder);
|
||||||
|
|
||||||
// Moves the cursor forward 1 character length
|
// Moves the cursor forward 1 character length
|
||||||
// Advance page if there is not enough room for the next character
|
// Advance page if there is not enough room for the next character
|
||||||
// Wraps to the begining when out of bounds
|
// Wraps to the beginning when out of bounds
|
||||||
void oled_advance_char(void);
|
void oled_advance_char(void);
|
||||||
|
|
||||||
// Writes a single character to the buffer at current cursor position
|
// Writes a single character to the buffer at current cursor position
|
||||||
|
@ -270,7 +270,7 @@ Configure the hardware via your `config.h`:
|
|||||||
| `ISSI_CONFIGURATION` | (Optional) Configuration for the Configuration Register | |
|
| `ISSI_CONFIGURATION` | (Optional) Configuration for the Configuration Register | |
|
||||||
| `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF |
|
| `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF |
|
||||||
| `ISSI_PULLDOWNUP` | (Optional) Configuration for the Pull Up & Pull Down Register | |
|
| `ISSI_PULLDOWNUP` | (Optional) Configuration for the Pull Up & Pull Down Register | |
|
||||||
| `ISSI_TEMP` | (Optional) Configuration for the Tempature Register | |
|
| `ISSI_TEMP` | (Optional) Configuration for the Temperature Register | |
|
||||||
| `ISSI_PWM_ENABLE` | (Optional) Configuration for the PWM Enable Register | |
|
| `ISSI_PWM_ENABLE` | (Optional) Configuration for the PWM Enable Register | |
|
||||||
| `ISSI_PWM_SET` | (Optional) Configuration for the PWM Setting Register | |
|
| `ISSI_PWM_SET` | (Optional) Configuration for the PWM Setting Register | |
|
||||||
| `ISSI_SCAL_RED` | (Optional) Configuration for the RED LEDs in Scaling Registers | 0xFF |
|
| `ISSI_SCAL_RED` | (Optional) Configuration for the RED LEDs in Scaling Registers | 0xFF |
|
||||||
|
Loading…
Reference in New Issue
Block a user