[docs] Organize driver & feature docs into subfolders (#23848)
Co-authored-by: Nick Brassel <nick@tzarc.org>
This commit is contained in:
parent
fa6d23235b
commit
78a0adfbb4
97 changed files with 282 additions and 285 deletions
|
@ -126,7 +126,7 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
|
|||
- commented-out functions removed too
|
||||
- `matrix_init_board()` etc. migrated to `keyboard_pre_init_kb()`, see: [keyboard_pre_init*](custom_quantum_functions#keyboard_pre_init_-function-documentation)
|
||||
- prefer `CUSTOM_MATRIX = lite` if custom matrix used, allows for standard debounce, see [custom matrix 'lite'](custom_matrix#lite)
|
||||
- prefer LED indicator [Configuration Options](feature_led_indicators#configuration-options) to custom `led_update_*()` implementations where possible
|
||||
- prefer LED indicator [Configuration Options](features/led_indicators#configuration-options) to custom `led_update_*()` implementations where possible
|
||||
- hardware that's enabled at the keyboard level and requires configuration such as OLED displays or encoders should have basic functionality implemented here
|
||||
- `<keyboard>.h`
|
||||
- `#include "quantum.h"` appears at the top
|
||||
|
@ -135,12 +135,12 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
|
|||
- no duplication of `rules.mk` or `config.h` from keyboard
|
||||
- `keymaps/default/keymap.c`
|
||||
- `QMKBEST`/`QMKURL` example macros removed
|
||||
- if using `MO(1)` and `MO(2)` keycodes together to access a third layer, the [Tri Layer](feature_tri_layer) feature should be used, rather than manually implementing this using `layer_on/off()` and `update_tri_layer()` functions in the keymap's `process_record_user()`.
|
||||
- if using `MO(1)` and `MO(2)` keycodes together to access a third layer, the [Tri Layer](features/tri_layer) feature should be used, rather than manually implementing this using `layer_on/off()` and `update_tri_layer()` functions in the keymap's `process_record_user()`.
|
||||
- default (and via) keymaps should be "pristine"
|
||||
- bare minimum to be used as a "clean slate" for another user to develop their own user-specific keymap
|
||||
- what does pristine mean? no custom keycodes. no advanced features like tap dance or macros. basic mod taps and home row mods would be acceptable where their use is necessary
|
||||
- standard layouts preferred in these keymaps, if possible
|
||||
- should use [encoder map feature](feature_encoders#encoder-map), rather than `encoder_update_user()`
|
||||
- should use [encoder map feature](features/encoders#encoder-map), rather than `encoder_update_user()`
|
||||
- default keymap should not enable VIA -- the VIA integration documentation requires a keymap called `via`
|
||||
- submitters can add an example (or bells-and-whistles) keymap showcasing capabilities in the same PR but it shouldn't be embedded in the 'default' keymap
|
||||
- submitters can also have a "manufacturer-matching" keymap that mirrors existing functionality of the commercial product, if porting an existing board
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue