Merge branch 'merge-2024-06-23' into vial
This commit is contained in:
commit
94ee834a94
2
.clangd
2
.clangd
@ -1,4 +1,4 @@
|
||||
CompileFlags:
|
||||
Add: [-Wno-unknown-attributes, -Wno-maybe-uninitialized, -Wno-unknown-warning-option]
|
||||
Remove: [-W*, -mcall-prologues]
|
||||
Remove: [-W*, -mmcu=*, -mcpu=*, -mfpu=*, -mfloat-abi=*, -mno-unaligned-access, -mno-thumb-interwork, -mcall-prologues]
|
||||
Compiler: clang
|
||||
|
123
.github/workflows/ci_build_major_branch.yml
vendored
Normal file
123
.github/workflows/ci_build_major_branch.yml
vendored
Normal file
@ -0,0 +1,123 @@
|
||||
name: CI Build Major Branch
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
actions: write
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [master, develop]
|
||||
workflow_dispatch:
|
||||
inputs:
|
||||
branch:
|
||||
type: choice
|
||||
description: "Branch to build"
|
||||
options: [master, develop]
|
||||
|
||||
env:
|
||||
# https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits
|
||||
# We've decreased it from 20 to 15 to allow for other GHA to run unimpeded
|
||||
CONCURRENT_JOBS: 15
|
||||
|
||||
# Ensure we only have one build running at a time, cancelling any active builds if a new commit is pushed to the respective branch
|
||||
concurrency:
|
||||
group: ci_build-${{ github.event.inputs.branch || github.ref_name }}
|
||||
cancel-in-progress: true
|
||||
|
||||
jobs:
|
||||
determine_concurrency:
|
||||
name: "Determine concurrency"
|
||||
if: github.repository == 'qmk/qmk_firmware'
|
||||
runs-on: ubuntu-latest
|
||||
container: ghcr.io/qmk/qmk_cli
|
||||
|
||||
outputs:
|
||||
slice_length: ${{ steps.generate_slice_length.outputs.slice_length }}
|
||||
|
||||
steps:
|
||||
- name: Install prerequisites
|
||||
run: |
|
||||
apt-get update
|
||||
apt-get install -y jq
|
||||
|
||||
- name: Disable safe.directory check
|
||||
run: |
|
||||
git config --global --add safe.directory '*'
|
||||
|
||||
- name: Checkout QMK Firmware
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Determine concurrency
|
||||
id: generate_slice_length
|
||||
run: |
|
||||
target_count=$( {
|
||||
qmk find -km default 2>/dev/null
|
||||
qmk find -km via 2>/dev/null
|
||||
} | sort | uniq | wc -l)
|
||||
slice_length=$((target_count / ($CONCURRENT_JOBS - 1))) # Err on the side of caution as we're splitting default and via
|
||||
echo "slice_length=$slice_length" >> $GITHUB_OUTPUT
|
||||
|
||||
build_targets:
|
||||
name: "Compile keymap ${{ matrix.keymap }}"
|
||||
needs: determine_concurrency
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
keymap: [default, via]
|
||||
uses: ./.github/workflows/ci_build_major_branch_keymap.yml
|
||||
with:
|
||||
branch: ${{ inputs.branch || github.ref_name }}
|
||||
keymap: ${{ matrix.keymap }}
|
||||
slice_length: ${{ needs.determine_concurrency.outputs.slice_length }}
|
||||
secrets: inherit
|
||||
|
||||
rollup_tasks:
|
||||
name: "Consolidation"
|
||||
needs: build_targets
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Download firmwares
|
||||
uses: actions/download-artifact@v4
|
||||
with:
|
||||
pattern: firmware-*
|
||||
path: firmwares
|
||||
merge-multiple: true
|
||||
|
||||
- name: Upload to https://ci.qmk.fm/${{ inputs.branch || github.ref_name }}/${{ github.sha }}
|
||||
uses: jakejarvis/s3-sync-action@master
|
||||
with:
|
||||
args: --acl public-read --follow-symlinks --delete
|
||||
env:
|
||||
AWS_S3_BUCKET: ${{ vars.CI_QMK_FM_SPACES_BUCKET }}
|
||||
AWS_ACCESS_KEY_ID: ${{ secrets.CI_QMK_FM_SPACES_KEY }}
|
||||
AWS_SECRET_ACCESS_KEY: ${{ secrets.CI_QMK_FM_SPACES_SECRET }}
|
||||
AWS_REGION: ${{ vars.CI_QMK_FM_SPACES_REGION }}
|
||||
AWS_S3_ENDPOINT: ${{ vars.CI_QMK_FM_SPACES_ENDPOINT }}
|
||||
SOURCE_DIR: firmwares
|
||||
DEST_DIR: ${{ inputs.branch || github.ref_name }}/${{ github.sha }}
|
||||
|
||||
- name: Upload to https://ci.qmk.fm/${{ inputs.branch || github.ref_name }}/latest
|
||||
uses: jakejarvis/s3-sync-action@master
|
||||
with:
|
||||
args: --acl public-read --follow-symlinks --delete
|
||||
env:
|
||||
AWS_S3_BUCKET: ${{ vars.CI_QMK_FM_SPACES_BUCKET }}
|
||||
AWS_ACCESS_KEY_ID: ${{ secrets.CI_QMK_FM_SPACES_KEY }}
|
||||
AWS_SECRET_ACCESS_KEY: ${{ secrets.CI_QMK_FM_SPACES_SECRET }}
|
||||
AWS_REGION: ${{ vars.CI_QMK_FM_SPACES_REGION }}
|
||||
AWS_S3_ENDPOINT: ${{ vars.CI_QMK_FM_SPACES_ENDPOINT }}
|
||||
SOURCE_DIR: firmwares
|
||||
DEST_DIR: ${{ inputs.branch || github.ref_name }}/latest
|
||||
|
||||
- name: Check if failure marker file exists
|
||||
id: check_failure_marker
|
||||
uses: andstor/file-existence-action@v3
|
||||
with:
|
||||
files: firmwares/.failed
|
||||
|
||||
- name: Fail build if needed
|
||||
if: steps.check_failure_marker.outputs.files_exists == 'true'
|
||||
run: |
|
||||
# Exit with failure if the compilation stage failed
|
||||
exit 1
|
181
.github/workflows/ci_build_major_branch_keymap.yml
vendored
Normal file
181
.github/workflows/ci_build_major_branch_keymap.yml
vendored
Normal file
@ -0,0 +1,181 @@
|
||||
name: CI Build Major Branch Keymap
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
actions: write
|
||||
|
||||
on:
|
||||
workflow_call:
|
||||
inputs:
|
||||
branch:
|
||||
type: string
|
||||
required: true
|
||||
keymap:
|
||||
type: string
|
||||
required: true
|
||||
slice_length:
|
||||
type: string
|
||||
required: true
|
||||
|
||||
jobs:
|
||||
generate_targets:
|
||||
name: "Generate targets (${{ inputs.keymap }})"
|
||||
runs-on: ubuntu-latest
|
||||
container: ghcr.io/qmk/qmk_cli
|
||||
|
||||
outputs:
|
||||
targets: ${{ steps.generate_targets.outputs.targets }}
|
||||
|
||||
steps:
|
||||
- name: Install prerequisites
|
||||
run: |
|
||||
apt-get update
|
||||
apt-get install -y jq
|
||||
|
||||
- name: Disable safe.directory check
|
||||
run: |
|
||||
git config --global --add safe.directory '*'
|
||||
|
||||
- name: Checkout QMK Firmware
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Generate build targets
|
||||
id: generate_targets
|
||||
run: |
|
||||
{ # Intentionally use `shuf` here so that we share manufacturers across all build groups -- some have a lot of ARM-based boards which inherently take longer
|
||||
counter=0
|
||||
echo -n '{'
|
||||
qmk find -km ${{ inputs.keymap }} 2>/dev/null | sort | uniq | shuf | xargs -L${{ inputs.slice_length }} | while IFS=$'\n' read target ; do
|
||||
if [ $counter -gt 0 ]; then
|
||||
echo -n ','
|
||||
fi
|
||||
counter=$((counter+1))
|
||||
printf "\"group %02d\":{" $counter
|
||||
echo -n '"targets":"'
|
||||
echo $target | tr ' ' '\n' | sort | uniq | xargs echo -n
|
||||
echo -n '"}'
|
||||
done
|
||||
echo -n '}'
|
||||
} | sed -e 's@\n@@g' > targets.json
|
||||
|
||||
# Output the target keys as a variable
|
||||
echo "targets=$(jq -c 'keys' targets.json)" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Upload targets json
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: targets-${{ inputs.keymap }}
|
||||
path: targets.json
|
||||
|
||||
build_targets:
|
||||
name: "Compile ${{ matrix.target }} (${{ inputs.keymap }})"
|
||||
needs: generate_targets
|
||||
runs-on: ubuntu-latest
|
||||
container: ghcr.io/qmk/qmk_cli
|
||||
continue-on-error: true
|
||||
|
||||
strategy:
|
||||
matrix:
|
||||
target: ${{ fromJson(needs.generate_targets.outputs.targets) }}
|
||||
|
||||
steps:
|
||||
- name: Install prerequisites
|
||||
run: |
|
||||
apt-get update
|
||||
apt-get install -y jq
|
||||
|
||||
- name: Disable safe.directory check
|
||||
run: |
|
||||
git config --global --add safe.directory '*'
|
||||
|
||||
- name: Checkout QMK Firmware
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Get target definitions
|
||||
uses: actions/download-artifact@v4
|
||||
with:
|
||||
name: targets-${{ inputs.keymap }}
|
||||
path: .
|
||||
|
||||
- name: Deploy submodules
|
||||
run: |
|
||||
qmk git-submodule -f
|
||||
|
||||
- name: Dump targets
|
||||
run: |
|
||||
jq -r '.["${{ matrix.target }}"].targets' targets.json | tr ' ' '\n' | sort
|
||||
|
||||
- name: Build targets
|
||||
continue-on-error: true
|
||||
run: |
|
||||
export NCPUS=$(( $(nproc 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null || getconf _NPROCESSORS_ONLN 2>/dev/null) -1 ))
|
||||
qmk mass-compile -t -j $NCPUS -e DUMP_CI_METADATA=yes $(jq -r '.["${{ matrix.target }}"].targets' targets.json) || touch .failed
|
||||
|
||||
- name: Upload binaries
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: firmware-${{ inputs.keymap }}-${{ matrix.target }}
|
||||
if-no-files-found: ignore
|
||||
path: |
|
||||
*.bin
|
||||
*.hex
|
||||
*.uf2
|
||||
.build/failed.*
|
||||
.failed
|
||||
|
||||
- name: Fail build if any group failed
|
||||
run: |
|
||||
# Exit with failure if the compilation stage failed
|
||||
[ ! -f .failed ] || exit 1
|
||||
|
||||
repack_firmware:
|
||||
if: always()
|
||||
name: "Repack artifacts"
|
||||
needs: build_targets
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout QMK Firmware
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Download firmwares
|
||||
uses: actions/download-artifact@v4
|
||||
with:
|
||||
pattern: firmware-${{ inputs.keymap }}-*
|
||||
path: .
|
||||
merge-multiple: true
|
||||
|
||||
- name: Upload all firmwares
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: firmware-${{ inputs.keymap }}
|
||||
if-no-files-found: ignore
|
||||
path: |
|
||||
*.bin
|
||||
*.hex
|
||||
*.uf2
|
||||
.build/failed.*
|
||||
.failed
|
||||
|
||||
- name: Generate output logs
|
||||
run: |
|
||||
# Generate the step summary markdown
|
||||
./util/ci/generate_failure_markdown.sh > $GITHUB_STEP_SUMMARY || true
|
||||
# Truncate to a maximum of 1MB to deal with GitHub workflow limit
|
||||
truncate --size='<960K' $GITHUB_STEP_SUMMARY || true
|
||||
|
||||
- name: Delete temporary build artifacts
|
||||
uses: geekyeggo/delete-artifact@v5
|
||||
with:
|
||||
name: |
|
||||
firmware-${{ inputs.keymap }}-*
|
||||
targets-${{ inputs.keymap }}
|
||||
|
||||
- name: 'CI Discord Notification'
|
||||
if: always()
|
||||
working-directory: util/ci/
|
||||
env:
|
||||
DISCORD_WEBHOOK: ${{ secrets.CI_DISCORD_WEBHOOK }}
|
||||
run: |
|
||||
python3 -m pip install -r requirements.txt
|
||||
python3 ./discord-results.py --branch ${{ inputs.branch || github.ref_name }} --keymap ${{ inputs.keymap }} --url ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
|
1
.gitignore
vendored
1
.gitignore
vendored
@ -38,6 +38,7 @@ quantum/version.h
|
||||
|
||||
# DD config at wrong location
|
||||
/keyboards/**/keymaps/*/info.json
|
||||
/keyboards/**/keymaps/*/keyboard.json
|
||||
|
||||
# Old-style QMK Makefiles
|
||||
/keyboards/**/Makefile
|
||||
|
2
Doxyfile
2
Doxyfile
@ -21,7 +21,7 @@ DOXYFILE_ENCODING = UTF-8
|
||||
PROJECT_NAME = "QMK Firmware"
|
||||
PROJECT_NUMBER = https://github.com/qmk/qmk_firmware
|
||||
PROJECT_BRIEF = "Keyboard controller firmware for Atmel AVR and ARM USB families"
|
||||
OUTPUT_DIRECTORY = .build/doxygen
|
||||
OUTPUT_DIRECTORY = .build/docs/static/doxygen
|
||||
ALLOW_UNICODE_NAMES = NO
|
||||
OUTPUT_LANGUAGE = English
|
||||
BRIEF_MEMBER_DESC = YES
|
||||
|
15
Makefile
15
Makefile
@ -465,3 +465,18 @@ distclean_userspace: clean
|
||||
rm -f $(QMK_USERSPACE)/*.bin $(QMK_USERSPACE)/*.hex $(QMK_USERSPACE)/*.uf2
|
||||
echo 'done.'
|
||||
endif
|
||||
|
||||
# Extra targets for formatting and/or pytest, running within the qmk/qmk_cli container to match GHA.
|
||||
CONTAINER_PREAMBLE := export HOME="/tmp"; export PATH="/tmp/.local/bin:\$$PATH"; python3 -m pip install --upgrade pip; python3 -m pip install -r requirements-dev.txt
|
||||
|
||||
.PHONY: format-core
|
||||
format-core:
|
||||
RUNTIME=docker ./util/docker_cmd.sh bash -lic "$(CONTAINER_PREAMBLE); qmk format-c --core-only -a && qmk format-python -a"
|
||||
|
||||
.PHONY: pytest
|
||||
pytest:
|
||||
RUNTIME=docker ./util/docker_cmd.sh bash -lic "$(CONTAINER_PREAMBLE); qmk pytest"
|
||||
|
||||
.PHONY: format-and-pytest
|
||||
format-and-pytest:
|
||||
RUNTIME=docker ./util/docker_cmd.sh bash -lic "$(CONTAINER_PREAMBLE); qmk format-c --core-only -a && qmk format-python -a && qmk pytest"
|
||||
|
@ -120,7 +120,7 @@ MAIN_KEYMAP_PATH_3 := $(KEYBOARD_PATH_3)/keymaps/$(KEYMAP)
|
||||
MAIN_KEYMAP_PATH_4 := $(KEYBOARD_PATH_4)/keymaps/$(KEYMAP)
|
||||
MAIN_KEYMAP_PATH_5 := $(KEYBOARD_PATH_5)/keymaps/$(KEYMAP)
|
||||
|
||||
# Pull in rules from info.json
|
||||
# Pull in rules from DD keyboard config
|
||||
INFO_RULES_MK = $(shell $(QMK_BIN) generate-rules-mk --quiet --escape --keyboard $(KEYBOARD) --output $(INTERMEDIATE_OUTPUT)/src/info_rules.mk)
|
||||
include $(INFO_RULES_MK)
|
||||
|
||||
@ -222,7 +222,7 @@ include $(BUILDDEFS_PATH)/converters.mk
|
||||
MCU_ORIG := $(MCU)
|
||||
include $(wildcard $(PLATFORM_PATH)/*/mcu_selection.mk)
|
||||
|
||||
# PLATFORM_KEY should be detected in info.json via key 'processor' (or rules.mk 'MCU')
|
||||
# PLATFORM_KEY should be detected in DD keyboard config via key 'processor' (or rules.mk 'MCU')
|
||||
ifeq ($(PLATFORM_KEY),)
|
||||
$(call CATASTROPHIC_ERROR,Platform not defined)
|
||||
endif
|
||||
@ -336,38 +336,54 @@ ifneq ("$(wildcard $(KEYBOARD_PATH_5)/post_config.h)","")
|
||||
POST_CONFIG_H += $(KEYBOARD_PATH_5)/post_config.h
|
||||
endif
|
||||
|
||||
# Pull in stuff from info.json
|
||||
INFO_JSON_FILES :=
|
||||
# Create dependencies on DD keyboard config - structure validated elsewhere
|
||||
DD_CONFIG_FILES :=
|
||||
ifneq ("$(wildcard $(KEYBOARD_PATH_1)/info.json)","")
|
||||
INFO_JSON_FILES += $(KEYBOARD_PATH_1)/info.json
|
||||
DD_CONFIG_FILES += $(KEYBOARD_PATH_1)/info.json
|
||||
endif
|
||||
ifneq ("$(wildcard $(KEYBOARD_PATH_2)/info.json)","")
|
||||
INFO_JSON_FILES += $(KEYBOARD_PATH_2)/info.json
|
||||
DD_CONFIG_FILES += $(KEYBOARD_PATH_2)/info.json
|
||||
endif
|
||||
ifneq ("$(wildcard $(KEYBOARD_PATH_3)/info.json)","")
|
||||
INFO_JSON_FILES += $(KEYBOARD_PATH_3)/info.json
|
||||
DD_CONFIG_FILES += $(KEYBOARD_PATH_3)/info.json
|
||||
endif
|
||||
ifneq ("$(wildcard $(KEYBOARD_PATH_4)/info.json)","")
|
||||
INFO_JSON_FILES += $(KEYBOARD_PATH_4)/info.json
|
||||
DD_CONFIG_FILES += $(KEYBOARD_PATH_4)/info.json
|
||||
endif
|
||||
ifneq ("$(wildcard $(KEYBOARD_PATH_5)/info.json)","")
|
||||
INFO_JSON_FILES += $(KEYBOARD_PATH_5)/info.json
|
||||
DD_CONFIG_FILES += $(KEYBOARD_PATH_5)/info.json
|
||||
endif
|
||||
|
||||
ifneq ("$(wildcard $(KEYBOARD_PATH_1)/keyboard.json)","")
|
||||
DD_CONFIG_FILES += $(KEYBOARD_PATH_1)/keyboard.json
|
||||
endif
|
||||
ifneq ("$(wildcard $(KEYBOARD_PATH_2)/keyboard.json)","")
|
||||
DD_CONFIG_FILES += $(KEYBOARD_PATH_2)/keyboard.json
|
||||
endif
|
||||
ifneq ("$(wildcard $(KEYBOARD_PATH_3)/keyboard.json)","")
|
||||
DD_CONFIG_FILES += $(KEYBOARD_PATH_3)/keyboard.json
|
||||
endif
|
||||
ifneq ("$(wildcard $(KEYBOARD_PATH_4)/keyboard.json)","")
|
||||
DD_CONFIG_FILES += $(KEYBOARD_PATH_4)/keyboard.json
|
||||
endif
|
||||
ifneq ("$(wildcard $(KEYBOARD_PATH_5)/keyboard.json)","")
|
||||
DD_CONFIG_FILES += $(KEYBOARD_PATH_5)/keyboard.json
|
||||
endif
|
||||
|
||||
CONFIG_H += $(INTERMEDIATE_OUTPUT)/src/info_config.h
|
||||
KEYBOARD_SRC += $(INTERMEDIATE_OUTPUT)/src/default_keyboard.c
|
||||
|
||||
$(INTERMEDIATE_OUTPUT)/src/info_config.h: $(INFO_JSON_FILES)
|
||||
$(INTERMEDIATE_OUTPUT)/src/info_config.h: $(DD_CONFIG_FILES)
|
||||
@$(SILENT) || printf "$(MSG_GENERATING) $@" | $(AWK_CMD)
|
||||
$(eval CMD=$(QMK_BIN) generate-config-h --quiet --keyboard $(KEYBOARD) --output $(INTERMEDIATE_OUTPUT)/src/info_config.h)
|
||||
@$(BUILD_CMD)
|
||||
|
||||
$(INTERMEDIATE_OUTPUT)/src/default_keyboard.c: $(INFO_JSON_FILES)
|
||||
$(INTERMEDIATE_OUTPUT)/src/default_keyboard.c: $(DD_CONFIG_FILES)
|
||||
@$(SILENT) || printf "$(MSG_GENERATING) $@" | $(AWK_CMD)
|
||||
$(eval CMD=$(QMK_BIN) generate-keyboard-c --quiet --keyboard $(KEYBOARD) --output $(INTERMEDIATE_OUTPUT)/src/default_keyboard.c)
|
||||
@$(BUILD_CMD)
|
||||
|
||||
$(INTERMEDIATE_OUTPUT)/src/default_keyboard.h: $(INFO_JSON_FILES)
|
||||
$(INTERMEDIATE_OUTPUT)/src/default_keyboard.h: $(DD_CONFIG_FILES)
|
||||
@$(SILENT) || printf "$(MSG_GENERATING) $@" | $(AWK_CMD)
|
||||
$(eval CMD=$(QMK_BIN) generate-keyboard-h --quiet --keyboard $(KEYBOARD) --include $(FOUND_KEYBOARD_H) --output $(INTERMEDIATE_OUTPUT)/src/default_keyboard.h)
|
||||
@$(BUILD_CMD)
|
||||
@ -506,22 +522,14 @@ ifeq ($(strip $(KEEP_INTERMEDIATES)), yes)
|
||||
OPT_DEFS += -save-temps=obj
|
||||
endif
|
||||
|
||||
# TODO: remove this bodge?
|
||||
PROJECT_DEFS := $(OPT_DEFS)
|
||||
PROJECT_INC := $(VPATH) $(EXTRAINCDIRS) $(KEYBOARD_PATHS)
|
||||
PROJECT_CONFIG := $(CONFIG_H)
|
||||
|
||||
CONFIG_H += $(POST_CONFIG_H)
|
||||
ALL_CONFIGS := $(PROJECT_CONFIG) $(CONFIG_H)
|
||||
|
||||
OUTPUTS := $(INTERMEDIATE_OUTPUT)
|
||||
$(INTERMEDIATE_OUTPUT)_SRC := $(SRC) $(PLATFORM_SRC)
|
||||
$(INTERMEDIATE_OUTPUT)_DEFS := $(OPT_DEFS) \
|
||||
$(INTERMEDIATE_OUTPUT)_DEFS := \
|
||||
-DQMK_KEYBOARD=\"$(KEYBOARD)\" -DQMK_KEYBOARD_H=\"$(INTERMEDIATE_OUTPUT)/src/default_keyboard.h\" \
|
||||
-DQMK_KEYMAP=\"$(KEYMAP)\" -DQMK_KEYMAP_H=\"$(KEYMAP).h\" -DQMK_KEYMAP_CONFIG_H=\"$(KEYMAP_PATH)/config.h\" \
|
||||
$(PROJECT_DEFS)
|
||||
$(INTERMEDIATE_OUTPUT)_INC := $(VPATH) $(EXTRAINCDIRS) $(PROJECT_INC)
|
||||
$(INTERMEDIATE_OUTPUT)_CONFIG := $(CONFIG_H) $(PROJECT_CONFIG)
|
||||
$(OPT_DEFS)
|
||||
$(INTERMEDIATE_OUTPUT)_INC := $(VPATH) $(EXTRAINCDIRS) $(KEYBOARD_PATHS)
|
||||
$(INTERMEDIATE_OUTPUT)_CONFIG := $(CONFIG_H) $(POST_CONFIG_H)
|
||||
|
||||
# Default target.
|
||||
all: build check-size
|
||||
|
@ -340,7 +340,7 @@ LED_MATRIX_DRIVER := snled27351
|
||||
endif
|
||||
|
||||
LED_MATRIX_ENABLE ?= no
|
||||
VALID_LED_MATRIX_TYPES := is31fl3218 is31fl3729 is31fl3731 is31fl3733 is31fl3736 is31fl3737 is31fl3741 is31fl3742a is31fl3743a is31fl3745 is31fl3746a snled27351 custom
|
||||
VALID_LED_MATRIX_TYPES := is31fl3218 is31fl3236 is31fl3729 is31fl3731 is31fl3733 is31fl3736 is31fl3737 is31fl3741 is31fl3742a is31fl3743a is31fl3745 is31fl3746a snled27351 custom
|
||||
|
||||
ifeq ($(strip $(LED_MATRIX_ENABLE)), yes)
|
||||
ifeq ($(filter $(LED_MATRIX_DRIVER),$(VALID_LED_MATRIX_TYPES)),)
|
||||
@ -353,7 +353,7 @@ ifeq ($(strip $(LED_MATRIX_ENABLE)), yes)
|
||||
COMMON_VPATH += $(QUANTUM_DIR)/led_matrix/animations
|
||||
COMMON_VPATH += $(QUANTUM_DIR)/led_matrix/animations/runners
|
||||
POST_CONFIG_H += $(QUANTUM_DIR)/led_matrix/post_config.h
|
||||
SRC += $(QUANTUM_DIR)/process_keycode/process_backlight.c
|
||||
SRC += $(QUANTUM_DIR)/process_keycode/process_led_matrix.c
|
||||
SRC += $(QUANTUM_DIR)/led_matrix/led_matrix.c
|
||||
SRC += $(QUANTUM_DIR)/led_matrix/led_matrix_drivers.c
|
||||
LIB8TION_ENABLE := yes
|
||||
@ -365,6 +365,12 @@ ifeq ($(strip $(LED_MATRIX_ENABLE)), yes)
|
||||
SRC += is31fl3218-mono.c
|
||||
endif
|
||||
|
||||
ifeq ($(strip $(LED_MATRIX_DRIVER)), is31fl3236)
|
||||
I2C_DRIVER_REQUIRED = yes
|
||||
COMMON_VPATH += $(DRIVER_PATH)/led/issi
|
||||
SRC += is31fl3236-mono.c
|
||||
endif
|
||||
|
||||
ifeq ($(strip $(LED_MATRIX_DRIVER)), is31fl3729)
|
||||
I2C_DRIVER_REQUIRED = yes
|
||||
COMMON_VPATH += $(DRIVER_PATH)/led/issi
|
||||
@ -443,7 +449,7 @@ endif
|
||||
|
||||
RGB_MATRIX_ENABLE ?= no
|
||||
|
||||
VALID_RGB_MATRIX_TYPES := aw20216s is31fl3218 is31fl3729 is31fl3731 is31fl3733 is31fl3736 is31fl3737 is31fl3741 is31fl3742a is31fl3743a is31fl3745 is31fl3746a snled27351 ws2812 custom
|
||||
VALID_RGB_MATRIX_TYPES := aw20216s is31fl3218 is31fl3236 is31fl3729 is31fl3731 is31fl3733 is31fl3736 is31fl3737 is31fl3741 is31fl3742a is31fl3743a is31fl3745 is31fl3746a snled27351 ws2812 custom
|
||||
ifeq ($(strip $(RGB_MATRIX_ENABLE)), yes)
|
||||
ifeq ($(filter $(RGB_MATRIX_DRIVER),$(VALID_RGB_MATRIX_TYPES)),)
|
||||
$(call CATASTROPHIC_ERROR,Invalid RGB_MATRIX_DRIVER,RGB_MATRIX_DRIVER="$(RGB_MATRIX_DRIVER)" is not a valid matrix type)
|
||||
@ -474,6 +480,12 @@ ifeq ($(strip $(RGB_MATRIX_ENABLE)), yes)
|
||||
SRC += is31fl3218.c
|
||||
endif
|
||||
|
||||
ifeq ($(strip $(RGB_MATRIX_DRIVER)), is31fl3236)
|
||||
I2C_DRIVER_REQUIRED = yes
|
||||
COMMON_VPATH += $(DRIVER_PATH)/led/issi
|
||||
SRC += is31fl3236.c
|
||||
endif
|
||||
|
||||
ifeq ($(strip $(RGB_MATRIX_DRIVER)), is31fl3729)
|
||||
I2C_DRIVER_REQUIRED = yes
|
||||
COMMON_VPATH += $(DRIVER_PATH)/led/issi
|
||||
|
5
builddefs/docsgen/.gitignore
vendored
Normal file
5
builddefs/docsgen/.gitignore
vendored
Normal file
@ -0,0 +1,5 @@
|
||||
node_modules
|
||||
.vitepress/cache
|
||||
.vitepress/.temp
|
||||
.vitepress/dist
|
||||
docs
|
51
builddefs/docsgen/.vitepress/config.mts
Normal file
51
builddefs/docsgen/.vitepress/config.mts
Normal file
@ -0,0 +1,51 @@
|
||||
import { defineConfig } from "vitepress";
|
||||
import { tabsMarkdownPlugin } from "vitepress-plugin-tabs";
|
||||
import sidebar from "../../../docs/_sidebar.json";
|
||||
|
||||
// https://vitepress.dev/reference/site-config
|
||||
export default defineConfig(({ mode }) => {
|
||||
const prod = mode === "production";
|
||||
return {
|
||||
title: "QMK Firmware",
|
||||
description: "Documentation for QMK Firmware",
|
||||
|
||||
srcDir: prod ? "docs" : "../../docs",
|
||||
outDir: "../../.build/docs",
|
||||
cleanUrls: true,
|
||||
|
||||
markdown: {
|
||||
config(md) {
|
||||
md.use(tabsMarkdownPlugin);
|
||||
},
|
||||
},
|
||||
|
||||
vite: {
|
||||
resolve: {
|
||||
preserveSymlinks: true,
|
||||
},
|
||||
},
|
||||
|
||||
themeConfig: {
|
||||
// https://vitepress.dev/reference/default-theme-config
|
||||
logo: {
|
||||
light: "/qmk-logo-light.svg",
|
||||
dark: "/qmk-logo-dark.svg",
|
||||
},
|
||||
title: 'QMK Firmware',
|
||||
|
||||
nav: [{ text: "Home", link: "./" }],
|
||||
|
||||
search: {
|
||||
provider: "local",
|
||||
},
|
||||
|
||||
sidebar: sidebar,
|
||||
|
||||
socialLinks: [
|
||||
{ icon: { svg: '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 50 50" width="50px" height="50px"><path d="M 29 3 C 28.0625 3 27.164063 3.382813 26.5 4 C 25.835938 4.617188 25.363281 5.433594 25 6.40625 C 24.355469 8.140625 24.085938 10.394531 24.03125 13.03125 C 19.234375 13.179688 14.820313 14.421875 11.28125 16.46875 C 10.214844 15.46875 8.855469 14.96875 7.5 14.96875 C 6.089844 14.96875 4.675781 15.511719 3.59375 16.59375 C 1.425781 18.761719 1.425781 22.238281 3.59375 24.40625 L 3.84375 24.65625 C 3.3125 26.035156 3 27.488281 3 29 C 3 33.527344 5.566406 37.585938 9.5625 40.4375 C 13.558594 43.289063 19.007813 45 25 45 C 30.992188 45 36.441406 43.289063 40.4375 40.4375 C 44.433594 37.585938 47 33.527344 47 29 C 47 27.488281 46.6875 26.035156 46.15625 24.65625 L 46.40625 24.40625 C 48.574219 22.238281 48.574219 18.761719 46.40625 16.59375 C 45.324219 15.511719 43.910156 14.96875 42.5 14.96875 C 41.144531 14.96875 39.785156 15.46875 38.71875 16.46875 C 35.195313 14.433594 30.800781 13.191406 26.03125 13.03125 C 26.09375 10.546875 26.363281 8.46875 26.875 7.09375 C 27.164063 6.316406 27.527344 5.757813 27.875 5.4375 C 28.222656 5.117188 28.539063 5 29 5 C 29.460938 5 29.683594 5.125 30.03125 5.40625 C 30.378906 5.6875 30.785156 6.148438 31.3125 6.6875 C 32.253906 7.652344 33.695313 8.714844 36.09375 8.9375 C 36.539063 11.238281 38.574219 13 41 13 C 43.75 13 46 10.75 46 8 C 46 5.25 43.75 3 41 3 C 38.605469 3 36.574219 4.710938 36.09375 6.96875 C 34.3125 6.796875 33.527344 6.109375 32.75 5.3125 C 32.300781 4.851563 31.886719 4.3125 31.3125 3.84375 C 30.738281 3.375 29.9375 3 29 3 Z M 41 5 C 42.667969 5 44 6.332031 44 8 C 44 9.667969 42.667969 11 41 11 C 39.332031 11 38 9.667969 38 8 C 38 6.332031 39.332031 5 41 5 Z M 25 15 C 30.609375 15 35.675781 16.613281 39.28125 19.1875 C 42.886719 21.761719 45 25.226563 45 29 C 45 32.773438 42.886719 36.238281 39.28125 38.8125 C 35.675781 41.386719 30.609375 43 25 43 C 19.390625 43 14.324219 41.386719 10.71875 38.8125 C 7.113281 36.238281 5 32.773438 5 29 C 5 25.226563 7.113281 21.761719 10.71875 19.1875 C 14.324219 16.613281 19.390625 15 25 15 Z M 7.5 16.9375 C 8.203125 16.9375 8.914063 17.148438 9.53125 17.59375 C 7.527344 19.03125 5.886719 20.769531 4.75 22.71875 C 3.582031 21.296875 3.660156 19.339844 5 18 C 5.714844 17.285156 6.609375 16.9375 7.5 16.9375 Z M 42.5 16.9375 C 43.390625 16.9375 44.285156 17.285156 45 18 C 46.339844 19.339844 46.417969 21.296875 45.25 22.71875 C 44.113281 20.769531 42.472656 19.03125 40.46875 17.59375 C 41.085938 17.148438 41.796875 16.9375 42.5 16.9375 Z M 17 22 C 14.800781 22 13 23.800781 13 26 C 13 28.199219 14.800781 30 17 30 C 19.199219 30 21 28.199219 21 26 C 21 23.800781 19.199219 22 17 22 Z M 33 22 C 30.800781 22 29 23.800781 29 26 C 29 28.199219 30.800781 30 33 30 C 35.199219 30 37 28.199219 37 26 C 37 23.800781 35.199219 22 33 22 Z M 17 24 C 18.117188 24 19 24.882813 19 26 C 19 27.117188 18.117188 28 17 28 C 15.882813 28 15 27.117188 15 26 C 15 24.882813 15.882813 24 17 24 Z M 33 24 C 34.117188 24 35 24.882813 35 26 C 35 27.117188 34.117188 28 33 28 C 31.882813 28 31 27.117188 31 26 C 31 24.882813 31.882813 24 33 24 Z M 34.15625 33.84375 C 34.101563 33.851563 34.050781 33.859375 34 33.875 C 33.683594 33.9375 33.417969 34.144531 33.28125 34.4375 C 33.28125 34.4375 32.757813 35.164063 31.4375 36 C 30.117188 36.835938 28.058594 37.6875 25 37.6875 C 21.941406 37.6875 19.882813 36.835938 18.5625 36 C 17.242188 35.164063 16.71875 34.4375 16.71875 34.4375 C 16.492188 34.082031 16.066406 33.90625 15.65625 34 C 15.332031 34.082031 15.070313 34.316406 14.957031 34.632813 C 14.84375 34.945313 14.894531 35.292969 15.09375 35.5625 C 15.09375 35.5625 15.863281 36.671875 17.46875 37.6875 C 19.074219 38.703125 21.558594 39.6875 25 39.6875 C 28.441406 39.6875 30.925781 38.703125 32.53125 37.6875 C 34.136719 36.671875 34.90625 35.5625 34.90625 35.5625 C 35.207031 35.273438 35.296875 34.824219 35.128906 34.441406 C 34.960938 34.058594 34.574219 33.820313 34.15625 33.84375 Z"/></svg>' }, link: "https://reddit.com/r/olkb" },
|
||||
{ icon: "discord", link: "https://discord.gg/qmk" },
|
||||
{ icon: "github", link: "https://github.com/qmk/qmk_firmware" },
|
||||
],
|
||||
}
|
||||
};
|
||||
});
|
29
builddefs/docsgen/.vitepress/theme/QMKLayout.vue
Normal file
29
builddefs/docsgen/.vitepress/theme/QMKLayout.vue
Normal file
@ -0,0 +1,29 @@
|
||||
<script setup>
|
||||
import DefaultTheme from 'vitepress/theme'
|
||||
import { useRouter } from 'vitepress'
|
||||
import { onBeforeMount } from 'vue';
|
||||
import aliases from "../../../../docs/_aliases.json";
|
||||
|
||||
const router = useRouter()
|
||||
onBeforeMount(async () => {
|
||||
// Convert from docsify-style to vitepress-style URLs
|
||||
let newUrl = window.location.href.replace(/\/#\//, '/').replace(/\?id=/, '#');
|
||||
|
||||
// Convert any aliases
|
||||
let testUrl = new URL(newUrl);
|
||||
while (testUrl.pathname in aliases) {
|
||||
testUrl.pathname = aliases[testUrl.pathname];
|
||||
}
|
||||
newUrl = testUrl.toString();
|
||||
|
||||
// Redirect if required
|
||||
if (newUrl != window.location.href) {
|
||||
window.history.replaceState({}, '', newUrl);
|
||||
await router.go(newUrl);
|
||||
}
|
||||
});
|
||||
</script>
|
||||
|
||||
<template>
|
||||
<DefaultTheme.Layout/>
|
||||
</template>
|
19
builddefs/docsgen/.vitepress/theme/custom.css
Normal file
19
builddefs/docsgen/.vitepress/theme/custom.css
Normal file
@ -0,0 +1,19 @@
|
||||
/* Override <kbd> as vitepress doesn't put them with borders */
|
||||
kbd {
|
||||
border: 1px solid var(--vp-c-text-1);
|
||||
border-radius: 5px;
|
||||
margin: 0.2em;
|
||||
padding: 0.2em;
|
||||
}
|
||||
|
||||
:root {
|
||||
--vp-nav-logo-height: 32px;
|
||||
|
||||
--vp-layout-max-width: calc(98% + 64px);
|
||||
|
||||
--vp-sidebar-width: 300px;
|
||||
}
|
||||
|
||||
.VPDoc.has-aside .content-container {
|
||||
max-width: unset !important;
|
||||
}
|
13
builddefs/docsgen/.vitepress/theme/index.ts
Normal file
13
builddefs/docsgen/.vitepress/theme/index.ts
Normal file
@ -0,0 +1,13 @@
|
||||
import type { Theme } from 'vitepress'
|
||||
import DefaultTheme from 'vitepress/theme'
|
||||
import { enhanceAppWithTabs } from 'vitepress-plugin-tabs/client'
|
||||
import QMKLayout from './QMKLayout.vue'
|
||||
import './custom.css'
|
||||
|
||||
export default {
|
||||
extends: DefaultTheme,
|
||||
Layout: QMKLayout,
|
||||
enhanceApp({ app }) {
|
||||
enhanceAppWithTabs(app)
|
||||
}
|
||||
} satisfies Theme
|
6
builddefs/docsgen/build-docs.sh
Executable file
6
builddefs/docsgen/build-docs.sh
Executable file
@ -0,0 +1,6 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
cd "$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
|
||||
yarn install
|
||||
[[ -e docs ]] || ln -sf ../../docs docs
|
||||
DEBUG='vitepress:*,vite:*' yarn run docs:build
|
14
builddefs/docsgen/package.json
Normal file
14
builddefs/docsgen/package.json
Normal file
@ -0,0 +1,14 @@
|
||||
{
|
||||
"license": "GPL-2.0-or-later",
|
||||
"devDependencies": {
|
||||
"vite": "^5.2.10",
|
||||
"vitepress": "^1.1.0",
|
||||
"vitepress-plugin-tabs": "^0.5.0",
|
||||
"vue": "^3.4.24"
|
||||
},
|
||||
"scripts": {
|
||||
"docs:dev": "vitepress dev --host 0.0.0.0",
|
||||
"docs:build": "vitepress build",
|
||||
"docs:preview": "vitepress preview --host 0.0.0.0"
|
||||
}
|
||||
}
|
5
builddefs/docsgen/start-docs.sh
Executable file
5
builddefs/docsgen/start-docs.sh
Executable file
@ -0,0 +1,5 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
cd "$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
|
||||
yarn install
|
||||
DEBUG='vitepress:*,vite:*' yarn run docs:dev
|
797
builddefs/docsgen/yarn.lock
Normal file
797
builddefs/docsgen/yarn.lock
Normal file
@ -0,0 +1,797 @@
|
||||
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
|
||||
# yarn lockfile v1
|
||||
|
||||
|
||||
"@algolia/autocomplete-core@1.9.3":
|
||||
version "1.9.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/autocomplete-core/-/autocomplete-core-1.9.3.tgz#1d56482a768c33aae0868c8533049e02e8961be7"
|
||||
integrity sha512-009HdfugtGCdC4JdXUbVJClA0q0zh24yyePn+KUGk3rP7j8FEe/m5Yo/z65gn6nP/cM39PxpzqKrL7A6fP6PPw==
|
||||
dependencies:
|
||||
"@algolia/autocomplete-plugin-algolia-insights" "1.9.3"
|
||||
"@algolia/autocomplete-shared" "1.9.3"
|
||||
|
||||
"@algolia/autocomplete-plugin-algolia-insights@1.9.3":
|
||||
version "1.9.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/autocomplete-plugin-algolia-insights/-/autocomplete-plugin-algolia-insights-1.9.3.tgz#9b7f8641052c8ead6d66c1623d444cbe19dde587"
|
||||
integrity sha512-a/yTUkcO/Vyy+JffmAnTWbr4/90cLzw+CC3bRbhnULr/EM0fGNvM13oQQ14f2moLMcVDyAx/leczLlAOovhSZg==
|
||||
dependencies:
|
||||
"@algolia/autocomplete-shared" "1.9.3"
|
||||
|
||||
"@algolia/autocomplete-preset-algolia@1.9.3":
|
||||
version "1.9.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/autocomplete-preset-algolia/-/autocomplete-preset-algolia-1.9.3.tgz#64cca4a4304cfcad2cf730e83067e0c1b2f485da"
|
||||
integrity sha512-d4qlt6YmrLMYy95n5TB52wtNDr6EgAIPH81dvvvW8UmuWRgxEtY0NJiPwl/h95JtG2vmRM804M0DSwMCNZlzRA==
|
||||
dependencies:
|
||||
"@algolia/autocomplete-shared" "1.9.3"
|
||||
|
||||
"@algolia/autocomplete-shared@1.9.3":
|
||||
version "1.9.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/autocomplete-shared/-/autocomplete-shared-1.9.3.tgz#2e22e830d36f0a9cf2c0ccd3c7f6d59435b77dfa"
|
||||
integrity sha512-Wnm9E4Ye6Rl6sTTqjoymD+l8DjSTHsHboVRYrKgEt8Q7UHm9nYbqhN/i0fhUYA3OAEH7WA8x3jfpnmJm3rKvaQ==
|
||||
|
||||
"@algolia/cache-browser-local-storage@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/cache-browser-local-storage/-/cache-browser-local-storage-4.23.3.tgz#0cc26b96085e1115dac5fcb9d826651ba57faabc"
|
||||
integrity sha512-vRHXYCpPlTDE7i6UOy2xE03zHF2C8MEFjPN2v7fRbqVpcOvAUQK81x3Kc21xyb5aSIpYCjWCZbYZuz8Glyzyyg==
|
||||
dependencies:
|
||||
"@algolia/cache-common" "4.23.3"
|
||||
|
||||
"@algolia/cache-common@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/cache-common/-/cache-common-4.23.3.tgz#3bec79092d512a96c9bfbdeec7cff4ad36367166"
|
||||
integrity sha512-h9XcNI6lxYStaw32pHpB1TMm0RuxphF+Ik4o7tcQiodEdpKK+wKufY6QXtba7t3k8eseirEMVB83uFFF3Nu54A==
|
||||
|
||||
"@algolia/cache-in-memory@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/cache-in-memory/-/cache-in-memory-4.23.3.tgz#3945f87cd21ffa2bec23890c85305b6b11192423"
|
||||
integrity sha512-yvpbuUXg/+0rbcagxNT7un0eo3czx2Uf0y4eiR4z4SD7SiptwYTpbuS0IHxcLHG3lq22ukx1T6Kjtk/rT+mqNg==
|
||||
dependencies:
|
||||
"@algolia/cache-common" "4.23.3"
|
||||
|
||||
"@algolia/client-account@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/client-account/-/client-account-4.23.3.tgz#8751bbf636e6741c95e7c778488dee3ee430ac6f"
|
||||
integrity sha512-hpa6S5d7iQmretHHF40QGq6hz0anWEHGlULcTIT9tbUssWUriN9AUXIFQ8Ei4w9azD0hc1rUok9/DeQQobhQMA==
|
||||
dependencies:
|
||||
"@algolia/client-common" "4.23.3"
|
||||
"@algolia/client-search" "4.23.3"
|
||||
"@algolia/transporter" "4.23.3"
|
||||
|
||||
"@algolia/client-analytics@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/client-analytics/-/client-analytics-4.23.3.tgz#f88710885278fe6fb6964384af59004a5a6f161d"
|
||||
integrity sha512-LBsEARGS9cj8VkTAVEZphjxTjMVCci+zIIiRhpFun9jGDUlS1XmhCW7CTrnaWeIuCQS/2iPyRqSy1nXPjcBLRA==
|
||||
dependencies:
|
||||
"@algolia/client-common" "4.23.3"
|
||||
"@algolia/client-search" "4.23.3"
|
||||
"@algolia/requester-common" "4.23.3"
|
||||
"@algolia/transporter" "4.23.3"
|
||||
|
||||
"@algolia/client-common@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/client-common/-/client-common-4.23.3.tgz#891116aa0db75055a7ecc107649f7f0965774704"
|
||||
integrity sha512-l6EiPxdAlg8CYhroqS5ybfIczsGUIAC47slLPOMDeKSVXYG1n0qGiz4RjAHLw2aD0xzh2EXZ7aRguPfz7UKDKw==
|
||||
dependencies:
|
||||
"@algolia/requester-common" "4.23.3"
|
||||
"@algolia/transporter" "4.23.3"
|
||||
|
||||
"@algolia/client-personalization@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/client-personalization/-/client-personalization-4.23.3.tgz#35fa8e5699b0295fbc400a8eb211dc711e5909db"
|
||||
integrity sha512-3E3yF3Ocr1tB/xOZiuC3doHQBQ2zu2MPTYZ0d4lpfWads2WTKG7ZzmGnsHmm63RflvDeLK/UVx7j2b3QuwKQ2g==
|
||||
dependencies:
|
||||
"@algolia/client-common" "4.23.3"
|
||||
"@algolia/requester-common" "4.23.3"
|
||||
"@algolia/transporter" "4.23.3"
|
||||
|
||||
"@algolia/client-search@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/client-search/-/client-search-4.23.3.tgz#a3486e6af13a231ec4ab43a915a1f318787b937f"
|
||||
integrity sha512-P4VAKFHqU0wx9O+q29Q8YVuaowaZ5EM77rxfmGnkHUJggh28useXQdopokgwMeYw2XUht49WX5RcTQ40rZIabw==
|
||||
dependencies:
|
||||
"@algolia/client-common" "4.23.3"
|
||||
"@algolia/requester-common" "4.23.3"
|
||||
"@algolia/transporter" "4.23.3"
|
||||
|
||||
"@algolia/logger-common@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/logger-common/-/logger-common-4.23.3.tgz#35c6d833cbf41e853a4f36ba37c6e5864920bfe9"
|
||||
integrity sha512-y9kBtmJwiZ9ZZ+1Ek66P0M68mHQzKRxkW5kAAXYN/rdzgDN0d2COsViEFufxJ0pb45K4FRcfC7+33YB4BLrZ+g==
|
||||
|
||||
"@algolia/logger-console@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/logger-console/-/logger-console-4.23.3.tgz#30f916781826c4db5f51fcd9a8a264a06e136985"
|
||||
integrity sha512-8xoiseoWDKuCVnWP8jHthgaeobDLolh00KJAdMe9XPrWPuf1by732jSpgy2BlsLTaT9m32pHI8CRfrOqQzHv3A==
|
||||
dependencies:
|
||||
"@algolia/logger-common" "4.23.3"
|
||||
|
||||
"@algolia/recommend@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/recommend/-/recommend-4.23.3.tgz#53d4f194d22d9c72dc05f3f7514c5878f87c5890"
|
||||
integrity sha512-9fK4nXZF0bFkdcLBRDexsnGzVmu4TSYZqxdpgBW2tEyfuSSY54D4qSRkLmNkrrz4YFvdh2GM1gA8vSsnZPR73w==
|
||||
dependencies:
|
||||
"@algolia/cache-browser-local-storage" "4.23.3"
|
||||
"@algolia/cache-common" "4.23.3"
|
||||
"@algolia/cache-in-memory" "4.23.3"
|
||||
"@algolia/client-common" "4.23.3"
|
||||
"@algolia/client-search" "4.23.3"
|
||||
"@algolia/logger-common" "4.23.3"
|
||||
"@algolia/logger-console" "4.23.3"
|
||||
"@algolia/requester-browser-xhr" "4.23.3"
|
||||
"@algolia/requester-common" "4.23.3"
|
||||
"@algolia/requester-node-http" "4.23.3"
|
||||
"@algolia/transporter" "4.23.3"
|
||||
|
||||
"@algolia/requester-browser-xhr@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/requester-browser-xhr/-/requester-browser-xhr-4.23.3.tgz#9e47e76f60d540acc8b27b4ebc7a80d1b41938b9"
|
||||
integrity sha512-jDWGIQ96BhXbmONAQsasIpTYWslyjkiGu0Quydjlowe+ciqySpiDUrJHERIRfELE5+wFc7hc1Q5hqjGoV7yghw==
|
||||
dependencies:
|
||||
"@algolia/requester-common" "4.23.3"
|
||||
|
||||
"@algolia/requester-common@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/requester-common/-/requester-common-4.23.3.tgz#7dbae896e41adfaaf1d1fa5f317f83a99afb04b3"
|
||||
integrity sha512-xloIdr/bedtYEGcXCiF2muajyvRhwop4cMZo+K2qzNht0CMzlRkm8YsDdj5IaBhshqfgmBb3rTg4sL4/PpvLYw==
|
||||
|
||||
"@algolia/requester-node-http@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/requester-node-http/-/requester-node-http-4.23.3.tgz#c9f94a5cb96a15f48cea338ab6ef16bbd0ff989f"
|
||||
integrity sha512-zgu++8Uj03IWDEJM3fuNl34s746JnZOWn1Uz5taV1dFyJhVM/kTNw9Ik7YJWiUNHJQXcaD8IXD1eCb0nq/aByA==
|
||||
dependencies:
|
||||
"@algolia/requester-common" "4.23.3"
|
||||
|
||||
"@algolia/transporter@4.23.3":
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/@algolia/transporter/-/transporter-4.23.3.tgz#545b045b67db3850ddf0bbecbc6c84ff1f3398b7"
|
||||
integrity sha512-Wjl5gttqnf/gQKJA+dafnD0Y6Yw97yvfY8R9h0dQltX1GXTgNs1zWgvtWW0tHl1EgMdhAyw189uWiZMnL3QebQ==
|
||||
dependencies:
|
||||
"@algolia/cache-common" "4.23.3"
|
||||
"@algolia/logger-common" "4.23.3"
|
||||
"@algolia/requester-common" "4.23.3"
|
||||
|
||||
"@babel/parser@^7.24.4":
|
||||
version "7.24.4"
|
||||
resolved "https://registry.yarnpkg.com/@babel/parser/-/parser-7.24.4.tgz#234487a110d89ad5a3ed4a8a566c36b9453e8c88"
|
||||
integrity sha512-zTvEBcghmeBma9QIGunWevvBAp4/Qu9Bdq+2k0Ot4fVMD6v3dsC9WOcRSKk7tRRyBM/53yKMJko9xOatGQAwSg==
|
||||
|
||||
"@docsearch/css@3.6.0", "@docsearch/css@^3.6.0":
|
||||
version "3.6.0"
|
||||
resolved "https://registry.yarnpkg.com/@docsearch/css/-/css-3.6.0.tgz#0e9f56f704b3a34d044d15fd9962ebc1536ba4fb"
|
||||
integrity sha512-+sbxb71sWre+PwDK7X2T8+bhS6clcVMLwBPznX45Qu6opJcgRjAp7gYSDzVFp187J+feSj5dNBN1mJoi6ckkUQ==
|
||||
|
||||
"@docsearch/js@^3.6.0":
|
||||
version "3.6.0"
|
||||
resolved "https://registry.yarnpkg.com/@docsearch/js/-/js-3.6.0.tgz#f9e46943449b9092d874944f7a80bcc071004cfb"
|
||||
integrity sha512-QujhqINEElrkIfKwyyyTfbsfMAYCkylInLYMRqHy7PHc8xTBQCow73tlo/Kc7oIwBrCLf0P3YhjlOeV4v8hevQ==
|
||||
dependencies:
|
||||
"@docsearch/react" "3.6.0"
|
||||
preact "^10.0.0"
|
||||
|
||||
"@docsearch/react@3.6.0":
|
||||
version "3.6.0"
|
||||
resolved "https://registry.yarnpkg.com/@docsearch/react/-/react-3.6.0.tgz#b4f25228ecb7fc473741aefac592121e86dd2958"
|
||||
integrity sha512-HUFut4ztcVNmqy9gp/wxNbC7pTOHhgVVkHVGCACTuLhUKUhKAF9KYHJtMiLUJxEqiFLQiuri1fWF8zqwM/cu1w==
|
||||
dependencies:
|
||||
"@algolia/autocomplete-core" "1.9.3"
|
||||
"@algolia/autocomplete-preset-algolia" "1.9.3"
|
||||
"@docsearch/css" "3.6.0"
|
||||
algoliasearch "^4.19.1"
|
||||
|
||||
"@esbuild/aix-ppc64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/aix-ppc64/-/aix-ppc64-0.20.2.tgz#a70f4ac11c6a1dfc18b8bbb13284155d933b9537"
|
||||
integrity sha512-D+EBOJHXdNZcLJRBkhENNG8Wji2kgc9AZ9KiPr1JuZjsNtyHzrsfLRrY0tk2H2aoFu6RANO1y1iPPUCDYWkb5g==
|
||||
|
||||
"@esbuild/android-arm64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/android-arm64/-/android-arm64-0.20.2.tgz#db1c9202a5bc92ea04c7b6840f1bbe09ebf9e6b9"
|
||||
integrity sha512-mRzjLacRtl/tWU0SvD8lUEwb61yP9cqQo6noDZP/O8VkwafSYwZ4yWy24kan8jE/IMERpYncRt2dw438LP3Xmg==
|
||||
|
||||
"@esbuild/android-arm@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/android-arm/-/android-arm-0.20.2.tgz#3b488c49aee9d491c2c8f98a909b785870d6e995"
|
||||
integrity sha512-t98Ra6pw2VaDhqNWO2Oph2LXbz/EJcnLmKLGBJwEwXX/JAN83Fym1rU8l0JUWK6HkIbWONCSSatf4sf2NBRx/w==
|
||||
|
||||
"@esbuild/android-x64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/android-x64/-/android-x64-0.20.2.tgz#3b1628029e5576249d2b2d766696e50768449f98"
|
||||
integrity sha512-btzExgV+/lMGDDa194CcUQm53ncxzeBrWJcncOBxuC6ndBkKxnHdFJn86mCIgTELsooUmwUm9FkhSp5HYu00Rg==
|
||||
|
||||
"@esbuild/darwin-arm64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/darwin-arm64/-/darwin-arm64-0.20.2.tgz#6e8517a045ddd86ae30c6608c8475ebc0c4000bb"
|
||||
integrity sha512-4J6IRT+10J3aJH3l1yzEg9y3wkTDgDk7TSDFX+wKFiWjqWp/iCfLIYzGyasx9l0SAFPT1HwSCR+0w/h1ES/MjA==
|
||||
|
||||
"@esbuild/darwin-x64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/darwin-x64/-/darwin-x64-0.20.2.tgz#90ed098e1f9dd8a9381695b207e1cff45540a0d0"
|
||||
integrity sha512-tBcXp9KNphnNH0dfhv8KYkZhjc+H3XBkF5DKtswJblV7KlT9EI2+jeA8DgBjp908WEuYll6pF+UStUCfEpdysA==
|
||||
|
||||
"@esbuild/freebsd-arm64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/freebsd-arm64/-/freebsd-arm64-0.20.2.tgz#d71502d1ee89a1130327e890364666c760a2a911"
|
||||
integrity sha512-d3qI41G4SuLiCGCFGUrKsSeTXyWG6yem1KcGZVS+3FYlYhtNoNgYrWcvkOoaqMhwXSMrZRl69ArHsGJ9mYdbbw==
|
||||
|
||||
"@esbuild/freebsd-x64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/freebsd-x64/-/freebsd-x64-0.20.2.tgz#aa5ea58d9c1dd9af688b8b6f63ef0d3d60cea53c"
|
||||
integrity sha512-d+DipyvHRuqEeM5zDivKV1KuXn9WeRX6vqSqIDgwIfPQtwMP4jaDsQsDncjTDDsExT4lR/91OLjRo8bmC1e+Cw==
|
||||
|
||||
"@esbuild/linux-arm64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/linux-arm64/-/linux-arm64-0.20.2.tgz#055b63725df678379b0f6db9d0fa85463755b2e5"
|
||||
integrity sha512-9pb6rBjGvTFNira2FLIWqDk/uaf42sSyLE8j1rnUpuzsODBq7FvpwHYZxQ/It/8b+QOS1RYfqgGFNLRI+qlq2A==
|
||||
|
||||
"@esbuild/linux-arm@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/linux-arm/-/linux-arm-0.20.2.tgz#76b3b98cb1f87936fbc37f073efabad49dcd889c"
|
||||
integrity sha512-VhLPeR8HTMPccbuWWcEUD1Az68TqaTYyj6nfE4QByZIQEQVWBB8vup8PpR7y1QHL3CpcF6xd5WVBU/+SBEvGTg==
|
||||
|
||||
"@esbuild/linux-ia32@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/linux-ia32/-/linux-ia32-0.20.2.tgz#c0e5e787c285264e5dfc7a79f04b8b4eefdad7fa"
|
||||
integrity sha512-o10utieEkNPFDZFQm9CoP7Tvb33UutoJqg3qKf1PWVeeJhJw0Q347PxMvBgVVFgouYLGIhFYG0UGdBumROyiig==
|
||||
|
||||
"@esbuild/linux-loong64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/linux-loong64/-/linux-loong64-0.20.2.tgz#a6184e62bd7cdc63e0c0448b83801001653219c5"
|
||||
integrity sha512-PR7sp6R/UC4CFVomVINKJ80pMFlfDfMQMYynX7t1tNTeivQ6XdX5r2XovMmha/VjR1YN/HgHWsVcTRIMkymrgQ==
|
||||
|
||||
"@esbuild/linux-mips64el@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/linux-mips64el/-/linux-mips64el-0.20.2.tgz#d08e39ce86f45ef8fc88549d29c62b8acf5649aa"
|
||||
integrity sha512-4BlTqeutE/KnOiTG5Y6Sb/Hw6hsBOZapOVF6njAESHInhlQAghVVZL1ZpIctBOoTFbQyGW+LsVYZ8lSSB3wkjA==
|
||||
|
||||
"@esbuild/linux-ppc64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/linux-ppc64/-/linux-ppc64-0.20.2.tgz#8d252f0b7756ffd6d1cbde5ea67ff8fd20437f20"
|
||||
integrity sha512-rD3KsaDprDcfajSKdn25ooz5J5/fWBylaaXkuotBDGnMnDP1Uv5DLAN/45qfnf3JDYyJv/ytGHQaziHUdyzaAg==
|
||||
|
||||
"@esbuild/linux-riscv64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/linux-riscv64/-/linux-riscv64-0.20.2.tgz#19f6dcdb14409dae607f66ca1181dd4e9db81300"
|
||||
integrity sha512-snwmBKacKmwTMmhLlz/3aH1Q9T8v45bKYGE3j26TsaOVtjIag4wLfWSiZykXzXuE1kbCE+zJRmwp+ZbIHinnVg==
|
||||
|
||||
"@esbuild/linux-s390x@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/linux-s390x/-/linux-s390x-0.20.2.tgz#3c830c90f1a5d7dd1473d5595ea4ebb920988685"
|
||||
integrity sha512-wcWISOobRWNm3cezm5HOZcYz1sKoHLd8VL1dl309DiixxVFoFe/o8HnwuIwn6sXre88Nwj+VwZUvJf4AFxkyrQ==
|
||||
|
||||
"@esbuild/linux-x64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/linux-x64/-/linux-x64-0.20.2.tgz#86eca35203afc0d9de0694c64ec0ab0a378f6fff"
|
||||
integrity sha512-1MdwI6OOTsfQfek8sLwgyjOXAu+wKhLEoaOLTjbijk6E2WONYpH9ZU2mNtR+lZ2B4uwr+usqGuVfFT9tMtGvGw==
|
||||
|
||||
"@esbuild/netbsd-x64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/netbsd-x64/-/netbsd-x64-0.20.2.tgz#e771c8eb0e0f6e1877ffd4220036b98aed5915e6"
|
||||
integrity sha512-K8/DhBxcVQkzYc43yJXDSyjlFeHQJBiowJ0uVL6Tor3jGQfSGHNNJcWxNbOI8v5k82prYqzPuwkzHt3J1T1iZQ==
|
||||
|
||||
"@esbuild/openbsd-x64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/openbsd-x64/-/openbsd-x64-0.20.2.tgz#9a795ae4b4e37e674f0f4d716f3e226dd7c39baf"
|
||||
integrity sha512-eMpKlV0SThJmmJgiVyN9jTPJ2VBPquf6Kt/nAoo6DgHAoN57K15ZghiHaMvqjCye/uU4X5u3YSMgVBI1h3vKrQ==
|
||||
|
||||
"@esbuild/sunos-x64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/sunos-x64/-/sunos-x64-0.20.2.tgz#7df23b61a497b8ac189def6e25a95673caedb03f"
|
||||
integrity sha512-2UyFtRC6cXLyejf/YEld4Hajo7UHILetzE1vsRcGL3earZEW77JxrFjH4Ez2qaTiEfMgAXxfAZCm1fvM/G/o8w==
|
||||
|
||||
"@esbuild/win32-arm64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/win32-arm64/-/win32-arm64-0.20.2.tgz#f1ae5abf9ca052ae11c1bc806fb4c0f519bacf90"
|
||||
integrity sha512-GRibxoawM9ZCnDxnP3usoUDO9vUkpAxIIZ6GQI+IlVmr5kP3zUq+l17xELTHMWTWzjxa2guPNyrpq1GWmPvcGQ==
|
||||
|
||||
"@esbuild/win32-ia32@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/win32-ia32/-/win32-ia32-0.20.2.tgz#241fe62c34d8e8461cd708277813e1d0ba55ce23"
|
||||
integrity sha512-HfLOfn9YWmkSKRQqovpnITazdtquEW8/SoHW7pWpuEeguaZI4QnCRW6b+oZTztdBnZOS2hqJ6im/D5cPzBTTlQ==
|
||||
|
||||
"@esbuild/win32-x64@0.20.2":
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/@esbuild/win32-x64/-/win32-x64-0.20.2.tgz#9c907b21e30a52db959ba4f80bb01a0cc403d5cc"
|
||||
integrity sha512-N49X4lJX27+l9jbLKSqZ6bKNjzQvHaT8IIFUy+YIqmXQdjYCToGWwOItDrfby14c78aDd5NHQl29xingXfCdLQ==
|
||||
|
||||
"@jridgewell/sourcemap-codec@^1.4.15":
|
||||
version "1.4.15"
|
||||
resolved "https://registry.yarnpkg.com/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.4.15.tgz#d7c6e6755c78567a951e04ab52ef0fd26de59f32"
|
||||
integrity sha512-eF2rxCRulEKXHTRiDrDy6erMYWqNw4LPdQ8UQA4huuxaQsVeRPFl2oM8oDGxMFhJUWZf9McpLtJasDDZb/Bpeg==
|
||||
|
||||
"@rollup/rollup-android-arm-eabi@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-android-arm-eabi/-/rollup-android-arm-eabi-4.16.4.tgz#5e8930291f1e5ead7fb1171d53ba5c87718de062"
|
||||
integrity sha512-GkhjAaQ8oUTOKE4g4gsZ0u8K/IHU1+2WQSgS1TwTcYvL+sjbaQjNHFXbOJ6kgqGHIO1DfUhI/Sphi9GkRT9K+Q==
|
||||
|
||||
"@rollup/rollup-android-arm64@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-android-arm64/-/rollup-android-arm64-4.16.4.tgz#ffb84f1359c04ec8a022a97110e18a5600f5f638"
|
||||
integrity sha512-Bvm6D+NPbGMQOcxvS1zUl8H7DWlywSXsphAeOnVeiZLQ+0J6Is8T7SrjGTH29KtYkiY9vld8ZnpV3G2EPbom+w==
|
||||
|
||||
"@rollup/rollup-darwin-arm64@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-darwin-arm64/-/rollup-darwin-arm64-4.16.4.tgz#b2fcee8d4806a0b1b9185ac038cc428ddedce9f4"
|
||||
integrity sha512-i5d64MlnYBO9EkCOGe5vPR/EeDwjnKOGGdd7zKFhU5y8haKhQZTN2DgVtpODDMxUr4t2K90wTUJg7ilgND6bXw==
|
||||
|
||||
"@rollup/rollup-darwin-x64@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-darwin-x64/-/rollup-darwin-x64-4.16.4.tgz#fcb25ccbaa3dd33a6490e9d1c64bab2e0e16b932"
|
||||
integrity sha512-WZupV1+CdUYehaZqjaFTClJI72fjJEgTXdf4NbW69I9XyvdmztUExBtcI2yIIU6hJtYvtwS6pkTkHJz+k08mAQ==
|
||||
|
||||
"@rollup/rollup-linux-arm-gnueabihf@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-arm-gnueabihf/-/rollup-linux-arm-gnueabihf-4.16.4.tgz#40d46bdfe667e5eca31bf40047460e326d2e26bb"
|
||||
integrity sha512-ADm/xt86JUnmAfA9mBqFcRp//RVRt1ohGOYF6yL+IFCYqOBNwy5lbEK05xTsEoJq+/tJzg8ICUtS82WinJRuIw==
|
||||
|
||||
"@rollup/rollup-linux-arm-musleabihf@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-arm-musleabihf/-/rollup-linux-arm-musleabihf-4.16.4.tgz#7741df2448c11c56588b50835dbfe91b1a10b375"
|
||||
integrity sha512-tJfJaXPiFAG+Jn3cutp7mCs1ePltuAgRqdDZrzb1aeE3TktWWJ+g7xK9SNlaSUFw6IU4QgOxAY4rA+wZUT5Wfg==
|
||||
|
||||
"@rollup/rollup-linux-arm64-gnu@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-arm64-gnu/-/rollup-linux-arm64-gnu-4.16.4.tgz#0a23b02d2933e4c4872ad18d879890b6a4a295df"
|
||||
integrity sha512-7dy1BzQkgYlUTapDTvK997cgi0Orh5Iu7JlZVBy1MBURk7/HSbHkzRnXZa19ozy+wwD8/SlpJnOOckuNZtJR9w==
|
||||
|
||||
"@rollup/rollup-linux-arm64-musl@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-arm64-musl/-/rollup-linux-arm64-musl-4.16.4.tgz#e37ef259358aa886cc07d782220a4fb83c1e6970"
|
||||
integrity sha512-zsFwdUw5XLD1gQe0aoU2HVceI6NEW7q7m05wA46eUAyrkeNYExObfRFQcvA6zw8lfRc5BHtan3tBpo+kqEOxmg==
|
||||
|
||||
"@rollup/rollup-linux-powerpc64le-gnu@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-powerpc64le-gnu/-/rollup-linux-powerpc64le-gnu-4.16.4.tgz#8c69218b6de05ee2ba211664a2d2ac1e54e43f94"
|
||||
integrity sha512-p8C3NnxXooRdNrdv6dBmRTddEapfESEUflpICDNKXpHvTjRRq1J82CbU5G3XfebIZyI3B0s074JHMWD36qOW6w==
|
||||
|
||||
"@rollup/rollup-linux-riscv64-gnu@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-riscv64-gnu/-/rollup-linux-riscv64-gnu-4.16.4.tgz#d32727dab8f538d9a4a7c03bcf58c436aecd0139"
|
||||
integrity sha512-Lh/8ckoar4s4Id2foY7jNgitTOUQczwMWNYi+Mjt0eQ9LKhr6sK477REqQkmy8YHY3Ca3A2JJVdXnfb3Rrwkng==
|
||||
|
||||
"@rollup/rollup-linux-s390x-gnu@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-s390x-gnu/-/rollup-linux-s390x-gnu-4.16.4.tgz#d46097246a187d99fc9451fe8393b7155b47c5ec"
|
||||
integrity sha512-1xwwn9ZCQYuqGmulGsTZoKrrn0z2fAur2ujE60QgyDpHmBbXbxLaQiEvzJWDrscRq43c8DnuHx3QorhMTZgisQ==
|
||||
|
||||
"@rollup/rollup-linux-x64-gnu@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-x64-gnu/-/rollup-linux-x64-gnu-4.16.4.tgz#6356c5a03a4afb1c3057490fc51b4764e109dbc7"
|
||||
integrity sha512-LuOGGKAJ7dfRtxVnO1i3qWc6N9sh0Em/8aZ3CezixSTM+E9Oq3OvTsvC4sm6wWjzpsIlOCnZjdluINKESflJLA==
|
||||
|
||||
"@rollup/rollup-linux-x64-musl@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-x64-musl/-/rollup-linux-x64-musl-4.16.4.tgz#03a5831a9c0d05877b94653b5ddd3020d3c6fb06"
|
||||
integrity sha512-ch86i7KkJKkLybDP2AtySFTRi5fM3KXp0PnHocHuJMdZwu7BuyIKi35BE9guMlmTpwwBTB3ljHj9IQXnTCD0vA==
|
||||
|
||||
"@rollup/rollup-win32-arm64-msvc@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-win32-arm64-msvc/-/rollup-win32-arm64-msvc-4.16.4.tgz#6cc0db57750376b9303bdb6f5482af8974fcae35"
|
||||
integrity sha512-Ma4PwyLfOWZWayfEsNQzTDBVW8PZ6TUUN1uFTBQbF2Chv/+sjenE86lpiEwj2FiviSmSZ4Ap4MaAfl1ciF4aSA==
|
||||
|
||||
"@rollup/rollup-win32-ia32-msvc@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-win32-ia32-msvc/-/rollup-win32-ia32-msvc-4.16.4.tgz#aea0b7e492bd9ed46971cb80bc34f1eb14e07789"
|
||||
integrity sha512-9m/ZDrQsdo/c06uOlP3W9G2ENRVzgzbSXmXHT4hwVaDQhYcRpi9bgBT0FTG9OhESxwK0WjQxYOSfv40cU+T69w==
|
||||
|
||||
"@rollup/rollup-win32-x64-msvc@4.16.4":
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-win32-x64-msvc/-/rollup-win32-x64-msvc-4.16.4.tgz#c09ad9a132ccb5a67c4f211d909323ab1294f95f"
|
||||
integrity sha512-YunpoOAyGLDseanENHmbFvQSfVL5BxW3k7hhy0eN4rb3gS/ct75dVD0EXOWIqFT/nE8XYW6LP6vz6ctKRi0k9A==
|
||||
|
||||
"@shikijs/core@1.3.0", "@shikijs/core@^1.3.0":
|
||||
version "1.3.0"
|
||||
resolved "https://registry.yarnpkg.com/@shikijs/core/-/core-1.3.0.tgz#5b93b51ddb8def1e3a1543107f9b5b0540f716f6"
|
||||
integrity sha512-7fedsBfuILDTBmrYZNFI8B6ATTxhQAasUHllHmjvSZPnoq4bULWoTpHwmuQvZ8Aq03/tAa2IGo6RXqWtHdWaCA==
|
||||
|
||||
"@shikijs/transformers@^1.3.0":
|
||||
version "1.3.0"
|
||||
resolved "https://registry.yarnpkg.com/@shikijs/transformers/-/transformers-1.3.0.tgz#b03c5733ef61e25e4f53666bf11889f8876f34e9"
|
||||
integrity sha512-3mlpg2I9CjhjE96dEWQOGeCWoPcyTov3s4aAsHmgvnTHa8MBknEnCQy8/xivJPSpD+olqOqIEoHnLfbNJK29AA==
|
||||
dependencies:
|
||||
shiki "1.3.0"
|
||||
|
||||
"@types/estree@1.0.5":
|
||||
version "1.0.5"
|
||||
resolved "https://registry.yarnpkg.com/@types/estree/-/estree-1.0.5.tgz#a6ce3e556e00fd9895dd872dd172ad0d4bd687f4"
|
||||
integrity sha512-/kYRxGDLWzHOB7q+wtSUQlFrtcdUccpfy+X+9iMBpHK8QLLhx2wIPYuS5DYtR9Wa/YlZAbIovy7qVdB1Aq6Lyw==
|
||||
|
||||
"@types/linkify-it@*":
|
||||
version "3.0.5"
|
||||
resolved "https://registry.yarnpkg.com/@types/linkify-it/-/linkify-it-3.0.5.tgz#1e78a3ac2428e6d7e6c05c1665c242023a4601d8"
|
||||
integrity sha512-yg6E+u0/+Zjva+buc3EIb+29XEg4wltq7cSmd4Uc2EE/1nUVmxyzpX6gUXD0V8jIrG0r7YeOGVIbYRkxeooCtw==
|
||||
|
||||
"@types/markdown-it@^14.0.1":
|
||||
version "14.0.1"
|
||||
resolved "https://registry.yarnpkg.com/@types/markdown-it/-/markdown-it-14.0.1.tgz#3d3fdf9dba83b69edececc070d39ec72b84270a7"
|
||||
integrity sha512-6WfOG3jXR78DW8L5cTYCVVGAsIFZskRHCDo5tbqa+qtKVt4oDRVH7hyIWu1SpDQJlmIoEivNQZ5h+AGAOrgOtQ==
|
||||
dependencies:
|
||||
"@types/linkify-it" "*"
|
||||
"@types/mdurl" "*"
|
||||
|
||||
"@types/mdurl@*":
|
||||
version "1.0.5"
|
||||
resolved "https://registry.yarnpkg.com/@types/mdurl/-/mdurl-1.0.5.tgz#3e0d2db570e9fb6ccb2dc8fde0be1d79ac810d39"
|
||||
integrity sha512-6L6VymKTzYSrEf4Nev4Xa1LCHKrlTlYCBMTlQKFuddo1CvQcE52I0mwfOJayueUC7MJuXOeHTcIU683lzd0cUA==
|
||||
|
||||
"@types/web-bluetooth@^0.0.20":
|
||||
version "0.0.20"
|
||||
resolved "https://registry.yarnpkg.com/@types/web-bluetooth/-/web-bluetooth-0.0.20.tgz#f066abfcd1cbe66267cdbbf0de010d8a41b41597"
|
||||
integrity sha512-g9gZnnXVq7gM7v3tJCWV/qw7w+KeOlSHAhgF9RytFyifW6AF61hdT2ucrYhPq9hLs5JIryeupHV3qGk95dH9ow==
|
||||
|
||||
"@vitejs/plugin-vue@^5.0.4":
|
||||
version "5.0.4"
|
||||
resolved "https://registry.yarnpkg.com/@vitejs/plugin-vue/-/plugin-vue-5.0.4.tgz#508d6a0f2440f86945835d903fcc0d95d1bb8a37"
|
||||
integrity sha512-WS3hevEszI6CEVEx28F8RjTX97k3KsrcY6kvTg7+Whm5y3oYvcqzVeGCU3hxSAn4uY2CLCkeokkGKpoctccilQ==
|
||||
|
||||
"@vue/compiler-core@3.4.24":
|
||||
version "3.4.24"
|
||||
resolved "https://registry.yarnpkg.com/@vue/compiler-core/-/compiler-core-3.4.24.tgz#6b4a5ffddcd874a692f2acfa68981201bcd7096b"
|
||||
integrity sha512-vbW/tgbwJYj62N/Ww99x0zhFTkZDTcGh3uwJEuadZ/nF9/xuFMC4693P9r+3sxGXISABpDKvffY5ApH9pmdd1A==
|
||||
dependencies:
|
||||
"@babel/parser" "^7.24.4"
|
||||
"@vue/shared" "3.4.24"
|
||||
entities "^4.5.0"
|
||||
estree-walker "^2.0.2"
|
||||
source-map-js "^1.2.0"
|
||||
|
||||
"@vue/compiler-dom@3.4.24":
|
||||
version "3.4.24"
|
||||
resolved "https://registry.yarnpkg.com/@vue/compiler-dom/-/compiler-dom-3.4.24.tgz#b7335a49f095b6d35e48b6f7be8da513c1fa52b8"
|
||||
integrity sha512-4XgABML/4cNndVsQndG6BbGN7+EoisDwi3oXNovqL/4jdNhwvP8/rfRMTb6FxkxIxUUtg6AI1/qZvwfSjxJiWA==
|
||||
dependencies:
|
||||
"@vue/compiler-core" "3.4.24"
|
||||
"@vue/shared" "3.4.24"
|
||||
|
||||
"@vue/compiler-sfc@3.4.24":
|
||||
version "3.4.24"
|
||||
resolved "https://registry.yarnpkg.com/@vue/compiler-sfc/-/compiler-sfc-3.4.24.tgz#2872e353147ce2a145169a33ddd4d68dc95c3a18"
|
||||
integrity sha512-nRAlJUK02FTWfA2nuvNBAqsDZuERGFgxZ8sGH62XgFSvMxO2URblzulExsmj4gFZ8e+VAyDooU9oAoXfEDNxTA==
|
||||
dependencies:
|
||||
"@babel/parser" "^7.24.4"
|
||||
"@vue/compiler-core" "3.4.24"
|
||||
"@vue/compiler-dom" "3.4.24"
|
||||
"@vue/compiler-ssr" "3.4.24"
|
||||
"@vue/shared" "3.4.24"
|
||||
estree-walker "^2.0.2"
|
||||
magic-string "^0.30.10"
|
||||
postcss "^8.4.38"
|
||||
source-map-js "^1.2.0"
|
||||
|
||||
"@vue/compiler-ssr@3.4.24":
|
||||
version "3.4.24"
|
||||
resolved "https://registry.yarnpkg.com/@vue/compiler-ssr/-/compiler-ssr-3.4.24.tgz#0d11fe54dabd17cbd6393a16bf7f785da1cfab46"
|
||||
integrity sha512-ZsAtr4fhaUFnVcDqwW3bYCSDwq+9Gk69q2r/7dAHDrOMw41kylaMgOP4zRnn6GIEJkQznKgrMOGPMFnLB52RbQ==
|
||||
dependencies:
|
||||
"@vue/compiler-dom" "3.4.24"
|
||||
"@vue/shared" "3.4.24"
|
||||
|
||||
"@vue/devtools-api@^7.0.27":
|
||||
version "7.1.2"
|
||||
resolved "https://registry.yarnpkg.com/@vue/devtools-api/-/devtools-api-7.1.2.tgz#8808b0f008842b756bf1e9c30788837abb62ab3a"
|
||||
integrity sha512-AKd49cN3BdRgttmX5Aw8op7sx6jmaPwaILcDjaa05UKc1yIHDYST7P8yGZs6zd2pKFETAQz40gmyG7+b57slsQ==
|
||||
dependencies:
|
||||
"@vue/devtools-kit" "^7.1.2"
|
||||
|
||||
"@vue/devtools-kit@^7.1.2":
|
||||
version "7.1.2"
|
||||
resolved "https://registry.yarnpkg.com/@vue/devtools-kit/-/devtools-kit-7.1.2.tgz#dfb7306edf895dadc556dd5f0c516809c2f94826"
|
||||
integrity sha512-UTrcUSOhlI9eXqbPMHUWwA6NQiiPT3onzXsVk2JHGR8ZFFSkzsWTTpHyVA1woG8zvgu2HNV/wigW2k87p858zw==
|
||||
dependencies:
|
||||
"@vue/devtools-shared" "^7.1.2"
|
||||
hookable "^5.5.3"
|
||||
mitt "^3.0.1"
|
||||
perfect-debounce "^1.0.0"
|
||||
speakingurl "^14.0.1"
|
||||
|
||||
"@vue/devtools-shared@^7.1.2":
|
||||
version "7.1.2"
|
||||
resolved "https://registry.yarnpkg.com/@vue/devtools-shared/-/devtools-shared-7.1.2.tgz#7b1c1de10bab4756f271c377370a62833b4ee94b"
|
||||
integrity sha512-r9cUf93VMhKSsxF2/cBbf6Lm1nRBx+r1pRuji5CiAf3JIPYPOjeEqJ13OuwP1fauYh1tyBFcCxt3eJPvHT59gg==
|
||||
dependencies:
|
||||
rfdc "^1.3.1"
|
||||
|
||||
"@vue/reactivity@3.4.24":
|
||||
version "3.4.24"
|
||||
resolved "https://registry.yarnpkg.com/@vue/reactivity/-/reactivity-3.4.24.tgz#150584316ca2acc4ed19a24f9f29863c3a17a7b2"
|
||||
integrity sha512-nup3fSYg4i4LtNvu9slF/HF/0dkMQYfepUdORBcMSsankzRPzE7ypAFurpwyRBfU1i7Dn1kcwpYsE1wETSh91g==
|
||||
dependencies:
|
||||
"@vue/shared" "3.4.24"
|
||||
|
||||
"@vue/runtime-core@3.4.24":
|
||||
version "3.4.24"
|
||||
resolved "https://registry.yarnpkg.com/@vue/runtime-core/-/runtime-core-3.4.24.tgz#066c544dc59a07a96c12874a57b750c239124874"
|
||||
integrity sha512-c7iMfj6cJMeAG3s5yOn9Rc5D9e2/wIuaozmGf/ICGCY3KV5H7mbTVdvEkd4ZshTq7RUZqj2k7LMJWVx+EBiY1g==
|
||||
dependencies:
|
||||
"@vue/reactivity" "3.4.24"
|
||||
"@vue/shared" "3.4.24"
|
||||
|
||||
"@vue/runtime-dom@3.4.24":
|
||||
version "3.4.24"
|
||||
resolved "https://registry.yarnpkg.com/@vue/runtime-dom/-/runtime-dom-3.4.24.tgz#4f8e7acbe1e8ffa7c55af1366e4438729ebe9b20"
|
||||
integrity sha512-uXKzuh/Emfad2Y7Qm0ABsLZZV6H3mAJ5ZVqmAOlrNQRf+T5mxpPGZBfec1hkP41t6h6FwF6RSGCs/gd8WbuySQ==
|
||||
dependencies:
|
||||
"@vue/runtime-core" "3.4.24"
|
||||
"@vue/shared" "3.4.24"
|
||||
csstype "^3.1.3"
|
||||
|
||||
"@vue/server-renderer@3.4.24":
|
||||
version "3.4.24"
|
||||
resolved "https://registry.yarnpkg.com/@vue/server-renderer/-/server-renderer-3.4.24.tgz#80dd546f8d6a9f5c4f8b68083fe9cc2d62299332"
|
||||
integrity sha512-H+DLK4sQF6sRgzKyofmlEVBIV/9KrQU6HIV7nt6yIwSGGKvSwlV8pqJlebUKLpbXaNHugdSfAbP6YmXF69lxow==
|
||||
dependencies:
|
||||
"@vue/compiler-ssr" "3.4.24"
|
||||
"@vue/shared" "3.4.24"
|
||||
|
||||
"@vue/shared@3.4.24":
|
||||
version "3.4.24"
|
||||
resolved "https://registry.yarnpkg.com/@vue/shared/-/shared-3.4.24.tgz#278ac71f492b392b9b17fe8fc7d324db1a8842db"
|
||||
integrity sha512-BW4tajrJBM9AGAknnyEw5tO2xTmnqgup0VTnDAMcxYmqOX0RG0b9aSUGAbEKolD91tdwpA6oCwbltoJoNzpItw==
|
||||
|
||||
"@vueuse/core@10.9.0", "@vueuse/core@^10.9.0":
|
||||
version "10.9.0"
|
||||
resolved "https://registry.yarnpkg.com/@vueuse/core/-/core-10.9.0.tgz#7d779a95cf0189de176fee63cee4ba44b3c85d64"
|
||||
integrity sha512-/1vjTol8SXnx6xewDEKfS0Ra//ncg4Hb0DaZiwKf7drgfMsKFExQ+FnnENcN6efPen+1kIzhLQoGSy0eDUVOMg==
|
||||
dependencies:
|
||||
"@types/web-bluetooth" "^0.0.20"
|
||||
"@vueuse/metadata" "10.9.0"
|
||||
"@vueuse/shared" "10.9.0"
|
||||
vue-demi ">=0.14.7"
|
||||
|
||||
"@vueuse/integrations@^10.9.0":
|
||||
version "10.9.0"
|
||||
resolved "https://registry.yarnpkg.com/@vueuse/integrations/-/integrations-10.9.0.tgz#2b1a9556215ad3c1f96d39cbfbef102cf6e0ec05"
|
||||
integrity sha512-acK+A01AYdWSvL4BZmCoJAcyHJ6EqhmkQEXbQLwev1MY7NBnS+hcEMx/BzVoR9zKI+UqEPMD9u6PsyAuiTRT4Q==
|
||||
dependencies:
|
||||
"@vueuse/core" "10.9.0"
|
||||
"@vueuse/shared" "10.9.0"
|
||||
vue-demi ">=0.14.7"
|
||||
|
||||
"@vueuse/metadata@10.9.0":
|
||||
version "10.9.0"
|
||||
resolved "https://registry.yarnpkg.com/@vueuse/metadata/-/metadata-10.9.0.tgz#769a1a9db65daac15cf98084cbf7819ed3758620"
|
||||
integrity sha512-iddNbg3yZM0X7qFY2sAotomgdHK7YJ6sKUvQqbvwnf7TmaVPxS4EJydcNsVejNdS8iWCtDk+fYXr7E32nyTnGA==
|
||||
|
||||
"@vueuse/shared@10.9.0":
|
||||
version "10.9.0"
|
||||
resolved "https://registry.yarnpkg.com/@vueuse/shared/-/shared-10.9.0.tgz#13af2a348de15d07b7be2fd0c7fc9853a69d8fe0"
|
||||
integrity sha512-Uud2IWncmAfJvRaFYzv5OHDli+FbOzxiVEQdLCKQKLyhz94PIyFC3CHcH7EDMwIn8NPtD06+PNbC/PiO0LGLtw==
|
||||
dependencies:
|
||||
vue-demi ">=0.14.7"
|
||||
|
||||
algoliasearch@^4.19.1:
|
||||
version "4.23.3"
|
||||
resolved "https://registry.yarnpkg.com/algoliasearch/-/algoliasearch-4.23.3.tgz#e09011d0a3b0651444916a3e6bbcba064ec44b60"
|
||||
integrity sha512-Le/3YgNvjW9zxIQMRhUHuhiUjAlKY/zsdZpfq4dlLqg6mEm0nL6yk+7f2hDOtLpxsgE4jSzDmvHL7nXdBp5feg==
|
||||
dependencies:
|
||||
"@algolia/cache-browser-local-storage" "4.23.3"
|
||||
"@algolia/cache-common" "4.23.3"
|
||||
"@algolia/cache-in-memory" "4.23.3"
|
||||
"@algolia/client-account" "4.23.3"
|
||||
"@algolia/client-analytics" "4.23.3"
|
||||
"@algolia/client-common" "4.23.3"
|
||||
"@algolia/client-personalization" "4.23.3"
|
||||
"@algolia/client-search" "4.23.3"
|
||||
"@algolia/logger-common" "4.23.3"
|
||||
"@algolia/logger-console" "4.23.3"
|
||||
"@algolia/recommend" "4.23.3"
|
||||
"@algolia/requester-browser-xhr" "4.23.3"
|
||||
"@algolia/requester-common" "4.23.3"
|
||||
"@algolia/requester-node-http" "4.23.3"
|
||||
"@algolia/transporter" "4.23.3"
|
||||
|
||||
csstype@^3.1.3:
|
||||
version "3.1.3"
|
||||
resolved "https://registry.yarnpkg.com/csstype/-/csstype-3.1.3.tgz#d80ff294d114fb0e6ac500fbf85b60137d7eff81"
|
||||
integrity sha512-M1uQkMl8rQK/szD0LNhtqxIPLpimGm8sOBwU7lLnCpSbTyY3yeU1Vc7l4KT5zT4s/yOxHH5O7tIuuLOCnLADRw==
|
||||
|
||||
entities@^4.5.0:
|
||||
version "4.5.0"
|
||||
resolved "https://registry.yarnpkg.com/entities/-/entities-4.5.0.tgz#5d268ea5e7113ec74c4d033b79ea5a35a488fb48"
|
||||
integrity sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==
|
||||
|
||||
esbuild@^0.20.1:
|
||||
version "0.20.2"
|
||||
resolved "https://registry.yarnpkg.com/esbuild/-/esbuild-0.20.2.tgz#9d6b2386561766ee6b5a55196c6d766d28c87ea1"
|
||||
integrity sha512-WdOOppmUNU+IbZ0PaDiTst80zjnrOkyJNHoKupIcVyU8Lvla3Ugx94VzkQ32Ijqd7UhHJy75gNWDMUekcrSJ6g==
|
||||
optionalDependencies:
|
||||
"@esbuild/aix-ppc64" "0.20.2"
|
||||
"@esbuild/android-arm" "0.20.2"
|
||||
"@esbuild/android-arm64" "0.20.2"
|
||||
"@esbuild/android-x64" "0.20.2"
|
||||
"@esbuild/darwin-arm64" "0.20.2"
|
||||
"@esbuild/darwin-x64" "0.20.2"
|
||||
"@esbuild/freebsd-arm64" "0.20.2"
|
||||
"@esbuild/freebsd-x64" "0.20.2"
|
||||
"@esbuild/linux-arm" "0.20.2"
|
||||
"@esbuild/linux-arm64" "0.20.2"
|
||||
"@esbuild/linux-ia32" "0.20.2"
|
||||
"@esbuild/linux-loong64" "0.20.2"
|
||||
"@esbuild/linux-mips64el" "0.20.2"
|
||||
"@esbuild/linux-ppc64" "0.20.2"
|
||||
"@esbuild/linux-riscv64" "0.20.2"
|
||||
"@esbuild/linux-s390x" "0.20.2"
|
||||
"@esbuild/linux-x64" "0.20.2"
|
||||
"@esbuild/netbsd-x64" "0.20.2"
|
||||
"@esbuild/openbsd-x64" "0.20.2"
|
||||
"@esbuild/sunos-x64" "0.20.2"
|
||||
"@esbuild/win32-arm64" "0.20.2"
|
||||
"@esbuild/win32-ia32" "0.20.2"
|
||||
"@esbuild/win32-x64" "0.20.2"
|
||||
|
||||
estree-walker@^2.0.2:
|
||||
version "2.0.2"
|
||||
resolved "https://registry.yarnpkg.com/estree-walker/-/estree-walker-2.0.2.tgz#52f010178c2a4c117a7757cfe942adb7d2da4cac"
|
||||
integrity sha512-Rfkk/Mp/DL7JVje3u18FxFujQlTNR2q6QfMSMB7AvCBx91NGj/ba3kCfza0f6dVDbw7YlRf/nDrn7pQrCCyQ/w==
|
||||
|
||||
focus-trap@^7.5.4:
|
||||
version "7.5.4"
|
||||
resolved "https://registry.yarnpkg.com/focus-trap/-/focus-trap-7.5.4.tgz#6c4e342fe1dae6add9c2aa332a6e7a0bbd495ba2"
|
||||
integrity sha512-N7kHdlgsO/v+iD/dMoJKtsSqs5Dz/dXZVebRgJw23LDk+jMi/974zyiOYDziY2JPp8xivq9BmUGwIJMiuSBi7w==
|
||||
dependencies:
|
||||
tabbable "^6.2.0"
|
||||
|
||||
fsevents@~2.3.2, fsevents@~2.3.3:
|
||||
version "2.3.3"
|
||||
resolved "https://registry.yarnpkg.com/fsevents/-/fsevents-2.3.3.tgz#cac6407785d03675a2a5e1a5305c697b347d90d6"
|
||||
integrity sha512-5xoDfX+fL7faATnagmWPpbFtwh/R77WmMMqqHGS65C3vvB0YHrgF+B1YmZ3441tMj5n63k0212XNoJwzlhffQw==
|
||||
|
||||
hookable@^5.5.3:
|
||||
version "5.5.3"
|
||||
resolved "https://registry.yarnpkg.com/hookable/-/hookable-5.5.3.tgz#6cfc358984a1ef991e2518cb9ed4a778bbd3215d"
|
||||
integrity sha512-Yc+BQe8SvoXH1643Qez1zqLRmbA5rCL+sSmk6TVos0LWVfNIB7PGncdlId77WzLGSIB5KaWgTaNTs2lNVEI6VQ==
|
||||
|
||||
magic-string@^0.30.10:
|
||||
version "0.30.10"
|
||||
resolved "https://registry.yarnpkg.com/magic-string/-/magic-string-0.30.10.tgz#123d9c41a0cb5640c892b041d4cfb3bd0aa4b39e"
|
||||
integrity sha512-iIRwTIf0QKV3UAnYK4PU8uiEc4SRh5jX0mwpIwETPpHdhVM4f53RSwS/vXvN1JhGX+Cs7B8qIq3d6AH49O5fAQ==
|
||||
dependencies:
|
||||
"@jridgewell/sourcemap-codec" "^1.4.15"
|
||||
|
||||
mark.js@8.11.1:
|
||||
version "8.11.1"
|
||||
resolved "https://registry.yarnpkg.com/mark.js/-/mark.js-8.11.1.tgz#180f1f9ebef8b0e638e4166ad52db879beb2ffc5"
|
||||
integrity sha512-1I+1qpDt4idfgLQG+BNWmrqku+7/2bi5nLf4YwF8y8zXvmfiTBY3PV3ZibfrjBueCByROpuBjLLFCajqkgYoLQ==
|
||||
|
||||
minisearch@^6.3.0:
|
||||
version "6.3.0"
|
||||
resolved "https://registry.yarnpkg.com/minisearch/-/minisearch-6.3.0.tgz#985a2f1ca3c73c2d65af94f0616bfe57164b0b6b"
|
||||
integrity sha512-ihFnidEeU8iXzcVHy74dhkxh/dn8Dc08ERl0xwoMMGqp4+LvRSCgicb+zGqWthVokQKvCSxITlh3P08OzdTYCQ==
|
||||
|
||||
mitt@^3.0.1:
|
||||
version "3.0.1"
|
||||
resolved "https://registry.yarnpkg.com/mitt/-/mitt-3.0.1.tgz#ea36cf0cc30403601ae074c8f77b7092cdab36d1"
|
||||
integrity sha512-vKivATfr97l2/QBCYAkXYDbrIWPM2IIKEl7YPhjCvKlG3kE2gm+uBo6nEXK3M5/Ffh/FLpKExzOQ3JJoJGFKBw==
|
||||
|
||||
nanoid@^3.3.7:
|
||||
version "3.3.7"
|
||||
resolved "https://registry.yarnpkg.com/nanoid/-/nanoid-3.3.7.tgz#d0c301a691bc8d54efa0a2226ccf3fe2fd656bd8"
|
||||
integrity sha512-eSRppjcPIatRIMC1U6UngP8XFcz8MQWGQdt1MTBQ7NaAmvXDfvNxbvWV3x2y6CdEUciCSsDHDQZbhYaB8QEo2g==
|
||||
|
||||
perfect-debounce@^1.0.0:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/perfect-debounce/-/perfect-debounce-1.0.0.tgz#9c2e8bc30b169cc984a58b7d5b28049839591d2a"
|
||||
integrity sha512-xCy9V055GLEqoFaHoC1SoLIaLmWctgCUaBaWxDZ7/Zx4CTyX7cJQLJOok/orfjZAh9kEYpjJa4d0KcJmCbctZA==
|
||||
|
||||
picocolors@^1.0.0:
|
||||
version "1.0.0"
|
||||
resolved "https://registry.yarnpkg.com/picocolors/-/picocolors-1.0.0.tgz#cb5bdc74ff3f51892236eaf79d68bc44564ab81c"
|
||||
integrity sha512-1fygroTLlHu66zi26VoTDv8yRgm0Fccecssto+MhsZ0D/DGW2sm8E8AjW7NU5VVTRt5GxbeZ5qBuJr+HyLYkjQ==
|
||||
|
||||
postcss@^8.4.38:
|
||||
version "8.4.38"
|
||||
resolved "https://registry.yarnpkg.com/postcss/-/postcss-8.4.38.tgz#b387d533baf2054288e337066d81c6bee9db9e0e"
|
||||
integrity sha512-Wglpdk03BSfXkHoQa3b/oulrotAkwrlLDRSOb9D0bN86FdRyE9lppSp33aHNPgBa0JKCoB+drFLZkQoRRYae5A==
|
||||
dependencies:
|
||||
nanoid "^3.3.7"
|
||||
picocolors "^1.0.0"
|
||||
source-map-js "^1.2.0"
|
||||
|
||||
preact@^10.0.0:
|
||||
version "10.20.2"
|
||||
resolved "https://registry.yarnpkg.com/preact/-/preact-10.20.2.tgz#0b343299a8c020562311cc25db93b3d832ec5e71"
|
||||
integrity sha512-S1d1ernz3KQ+Y2awUxKakpfOg2CEmJmwOP+6igPx6dgr6pgDvenqYviyokWso2rhHvGtTlWWnJDa7RaPbQerTg==
|
||||
|
||||
rfdc@^1.3.1:
|
||||
version "1.3.1"
|
||||
resolved "https://registry.yarnpkg.com/rfdc/-/rfdc-1.3.1.tgz#2b6d4df52dffe8bb346992a10ea9451f24373a8f"
|
||||
integrity sha512-r5a3l5HzYlIC68TpmYKlxWjmOP6wiPJ1vWv2HeLhNsRZMrCkxeqxiHlQ21oXmQ4F3SiryXBHhAD7JZqvOJjFmg==
|
||||
|
||||
rollup@^4.13.0:
|
||||
version "4.16.4"
|
||||
resolved "https://registry.yarnpkg.com/rollup/-/rollup-4.16.4.tgz#fe328eb41293f20c9593a095ec23bdc4b5d93317"
|
||||
integrity sha512-kuaTJSUbz+Wsb2ATGvEknkI12XV40vIiHmLuFlejoo7HtDok/O5eDDD0UpCVY5bBX5U5RYo8wWP83H7ZsqVEnA==
|
||||
dependencies:
|
||||
"@types/estree" "1.0.5"
|
||||
optionalDependencies:
|
||||
"@rollup/rollup-android-arm-eabi" "4.16.4"
|
||||
"@rollup/rollup-android-arm64" "4.16.4"
|
||||
"@rollup/rollup-darwin-arm64" "4.16.4"
|
||||
"@rollup/rollup-darwin-x64" "4.16.4"
|
||||
"@rollup/rollup-linux-arm-gnueabihf" "4.16.4"
|
||||
"@rollup/rollup-linux-arm-musleabihf" "4.16.4"
|
||||
"@rollup/rollup-linux-arm64-gnu" "4.16.4"
|
||||
"@rollup/rollup-linux-arm64-musl" "4.16.4"
|
||||
"@rollup/rollup-linux-powerpc64le-gnu" "4.16.4"
|
||||
"@rollup/rollup-linux-riscv64-gnu" "4.16.4"
|
||||
"@rollup/rollup-linux-s390x-gnu" "4.16.4"
|
||||
"@rollup/rollup-linux-x64-gnu" "4.16.4"
|
||||
"@rollup/rollup-linux-x64-musl" "4.16.4"
|
||||
"@rollup/rollup-win32-arm64-msvc" "4.16.4"
|
||||
"@rollup/rollup-win32-ia32-msvc" "4.16.4"
|
||||
"@rollup/rollup-win32-x64-msvc" "4.16.4"
|
||||
fsevents "~2.3.2"
|
||||
|
||||
shiki@1.3.0, shiki@^1.3.0:
|
||||
version "1.3.0"
|
||||
resolved "https://registry.yarnpkg.com/shiki/-/shiki-1.3.0.tgz#3eda35cb49f6f0a98525e9da48fc072e6c655a3f"
|
||||
integrity sha512-9aNdQy/etMXctnPzsje1h1XIGm9YfRcSksKOGqZWXA/qP9G18/8fpz5Bjpma8bOgz3tqIpjERAd6/lLjFyzoww==
|
||||
dependencies:
|
||||
"@shikijs/core" "1.3.0"
|
||||
|
||||
source-map-js@^1.2.0:
|
||||
version "1.2.0"
|
||||
resolved "https://registry.yarnpkg.com/source-map-js/-/source-map-js-1.2.0.tgz#16b809c162517b5b8c3e7dcd315a2a5c2612b2af"
|
||||
integrity sha512-itJW8lvSA0TXEphiRoawsCksnlf8SyvmFzIhltqAHluXd88pkCd+cXJVHTDwdCr0IzwptSm035IHQktUu1QUMg==
|
||||
|
||||
speakingurl@^14.0.1:
|
||||
version "14.0.1"
|
||||
resolved "https://registry.yarnpkg.com/speakingurl/-/speakingurl-14.0.1.tgz#f37ec8ddc4ab98e9600c1c9ec324a8c48d772a53"
|
||||
integrity sha512-1POYv7uv2gXoyGFpBCmpDVSNV74IfsWlDW216UPjbWufNf+bSU6GdbDsxdcxtfwb4xlI3yxzOTKClUosxARYrQ==
|
||||
|
||||
tabbable@^6.2.0:
|
||||
version "6.2.0"
|
||||
resolved "https://registry.yarnpkg.com/tabbable/-/tabbable-6.2.0.tgz#732fb62bc0175cfcec257330be187dcfba1f3b97"
|
||||
integrity sha512-Cat63mxsVJlzYvN51JmVXIgNoUokrIaT2zLclCXjRd8boZ0004U4KCs/sToJ75C6sdlByWxpYnb5Boif1VSFew==
|
||||
|
||||
vite@^5.2.10, vite@^5.2.9:
|
||||
version "5.2.10"
|
||||
resolved "https://registry.yarnpkg.com/vite/-/vite-5.2.10.tgz#2ac927c91e99d51b376a5c73c0e4b059705f5bd7"
|
||||
integrity sha512-PAzgUZbP7msvQvqdSD+ErD5qGnSFiGOoWmV5yAKUEI0kdhjbH6nMWVyZQC/hSc4aXwc0oJ9aEdIiF9Oje0JFCw==
|
||||
dependencies:
|
||||
esbuild "^0.20.1"
|
||||
postcss "^8.4.38"
|
||||
rollup "^4.13.0"
|
||||
optionalDependencies:
|
||||
fsevents "~2.3.3"
|
||||
|
||||
vitepress-plugin-tabs@^0.5.0:
|
||||
version "0.5.0"
|
||||
resolved "https://registry.yarnpkg.com/vitepress-plugin-tabs/-/vitepress-plugin-tabs-0.5.0.tgz#2b193a72ed36b9fcd63e3907d3044fe7b6cf3e4e"
|
||||
integrity sha512-SIhFWwGsUkTByfc2b279ray/E0Jt8vDTsM1LiHxmCOBAEMmvzIBZSuYYT1DpdDTiS3SuJieBheJkYnwCq/yD9A==
|
||||
|
||||
vitepress@^1.1.0:
|
||||
version "1.1.3"
|
||||
resolved "https://registry.yarnpkg.com/vitepress/-/vitepress-1.1.3.tgz#ded22392f5274680aaba8bb81dd4fb1c4741c02e"
|
||||
integrity sha512-hGrIYN0w9IHWs0NQSnlMjKV/v/HLfD+Ywv5QdvCSkiT32mpNOOwUrZjnqZv/JL/WBPpUc94eghTUvmipxw0xrA==
|
||||
dependencies:
|
||||
"@docsearch/css" "^3.6.0"
|
||||
"@docsearch/js" "^3.6.0"
|
||||
"@shikijs/core" "^1.3.0"
|
||||
"@shikijs/transformers" "^1.3.0"
|
||||
"@types/markdown-it" "^14.0.1"
|
||||
"@vitejs/plugin-vue" "^5.0.4"
|
||||
"@vue/devtools-api" "^7.0.27"
|
||||
"@vueuse/core" "^10.9.0"
|
||||
"@vueuse/integrations" "^10.9.0"
|
||||
focus-trap "^7.5.4"
|
||||
mark.js "8.11.1"
|
||||
minisearch "^6.3.0"
|
||||
shiki "^1.3.0"
|
||||
vite "^5.2.9"
|
||||
vue "^3.4.23"
|
||||
|
||||
vue-demi@>=0.14.7:
|
||||
version "0.14.7"
|
||||
resolved "https://registry.yarnpkg.com/vue-demi/-/vue-demi-0.14.7.tgz#8317536b3ef74c5b09f268f7782e70194567d8f2"
|
||||
integrity sha512-EOG8KXDQNwkJILkx/gPcoL/7vH+hORoBaKgGe+6W7VFMvCYJfmF2dGbvgDroVnI8LU7/kTu8mbjRZGBU1z9NTA==
|
||||
|
||||
vue@^3.4.23, vue@^3.4.24:
|
||||
version "3.4.24"
|
||||
resolved "https://registry.yarnpkg.com/vue/-/vue-3.4.24.tgz#f269549939a6c092480f018aa0bd886ba64f4c6f"
|
||||
integrity sha512-NPdx7dLGyHmKHGRRU5bMRYVE+rechR+KDU5R2tSTNG36PuMwbfAJ+amEvOAw7BPfZp5sQulNELSLm5YUkau+Sg==
|
||||
dependencies:
|
||||
"@vue/compiler-dom" "3.4.24"
|
||||
"@vue/compiler-sfc" "3.4.24"
|
||||
"@vue/runtime-dom" "3.4.24"
|
||||
"@vue/server-renderer" "3.4.24"
|
||||
"@vue/shared" "3.4.24"
|
@ -0,0 +1,580 @@
|
||||
{
|
||||
"aliases": {
|
||||
/*
|
||||
* ┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬─────┐
|
||||
* │ \ │ + │ ě │ š │ č │ ř │ ž │ ý │ á │ í │ é │ = │ ' │ │
|
||||
* ├───┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬───┤
|
||||
* │ │ Q │ W │ E │ R │ T │ Y │ U │ I │ O │ P │ ú │ ) │ ¨ │
|
||||
* ├─────┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴───┤
|
||||
* │ │ A │ S │ D │ F │ G │ H │ J │ K │ L │ ů │ § │ │
|
||||
* ├──────┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴──────┤
|
||||
* │ │ Z │ X │ C │ V │ B │ N │ M │ , │ . │ - │ │
|
||||
* ├─────┬──┴─┬─┴───┼───┴───┴───┴───┴───┴───┼───┴─┬─┴──┬─────┤
|
||||
* │ │ │ │ │ │ │ │
|
||||
* └─────┴────┴─────┴───────────────────────┴─────┴────┴─────┘
|
||||
*/
|
||||
"KC_GRV": {
|
||||
"key": "CZ_BSLS",
|
||||
"label": "\\",
|
||||
}
|
||||
"KC_1": {
|
||||
"key": "CZ_PLUS",
|
||||
"label": "+",
|
||||
}
|
||||
"KC_2": {
|
||||
"key": "CZ_ECAR",
|
||||
"label": "ě",
|
||||
}
|
||||
"KC_3": {
|
||||
"key": "CZ_SCAR",
|
||||
"label": "š",
|
||||
}
|
||||
"KC_4": {
|
||||
"key": "CZ_CCAR",
|
||||
"label": "č",
|
||||
}
|
||||
"KC_5": {
|
||||
"key": "CZ_RCAR",
|
||||
"label": "ř",
|
||||
}
|
||||
"KC_6": {
|
||||
"key": "CZ_ZCAR",
|
||||
"label": "ž",
|
||||
}
|
||||
"KC_7": {
|
||||
"key": "CZ_YACU",
|
||||
"label": "ý",
|
||||
}
|
||||
"KC_8": {
|
||||
"key": "CZ_AACU",
|
||||
"label": "á",
|
||||
}
|
||||
"KC_9": {
|
||||
"key": "CZ_IACU",
|
||||
"label": "í",
|
||||
}
|
||||
"KC_0": {
|
||||
"key": "CZ_EACU",
|
||||
"label": "é",
|
||||
}
|
||||
"KC_MINS": {
|
||||
"key": "CZ_EQL",
|
||||
"label": "=",
|
||||
}
|
||||
"KC_EQL": {
|
||||
"key": "CZ_ACUT",
|
||||
"label": "' (dead)",
|
||||
}
|
||||
"KC_Q": {
|
||||
"key": "CZ_Q",
|
||||
"label": "Q",
|
||||
}
|
||||
"KC_W": {
|
||||
"key": "CZ_W",
|
||||
"label": "W",
|
||||
}
|
||||
"KC_E": {
|
||||
"key": "CZ_E",
|
||||
"label": "E",
|
||||
}
|
||||
"KC_R": {
|
||||
"key": "CZ_R",
|
||||
"label": "R",
|
||||
}
|
||||
"KC_T": {
|
||||
"key": "CZ_T",
|
||||
"label": "T",
|
||||
}
|
||||
"KC_Y": {
|
||||
"key": "CZ_Z",
|
||||
"label": "Z",
|
||||
}
|
||||
"KC_U": {
|
||||
"key": "CZ_U",
|
||||
"label": "U",
|
||||
}
|
||||
"KC_I": {
|
||||
"key": "CZ_I",
|
||||
"label": "I",
|
||||
}
|
||||
"KC_O": {
|
||||
"key": "CZ_O",
|
||||
"label": "O",
|
||||
}
|
||||
"KC_P": {
|
||||
"key": "CZ_P",
|
||||
"label": "P",
|
||||
}
|
||||
"KC_LBRC": {
|
||||
"key": "CZ_UACU",
|
||||
"label": "ú",
|
||||
}
|
||||
"KC_RBRC": {
|
||||
"key": "CZ_RPRN",
|
||||
"label": ")",
|
||||
}
|
||||
"KC_NUHS": {
|
||||
"key": "CZ_DIAE",
|
||||
"label": "¨ (dead)",
|
||||
}
|
||||
"KC_A": {
|
||||
"key": "CZ_A",
|
||||
"label": "A",
|
||||
}
|
||||
"KC_S": {
|
||||
"key": "CZ_S",
|
||||
"label": "S",
|
||||
}
|
||||
"KC_D": {
|
||||
"key": "CZ_D",
|
||||
"label": "D",
|
||||
}
|
||||
"KC_F": {
|
||||
"key": "CZ_F",
|
||||
"label": "F",
|
||||
}
|
||||
"KC_G": {
|
||||
"key": "CZ_G",
|
||||
"label": "G",
|
||||
}
|
||||
"KC_H": {
|
||||
"key": "CZ_H",
|
||||
"label": "H",
|
||||
}
|
||||
"KC_J": {
|
||||
"key": "CZ_J",
|
||||
"label": "J",
|
||||
}
|
||||
"KC_K": {
|
||||
"key": "CZ_K",
|
||||
"label": "K",
|
||||
}
|
||||
"KC_L": {
|
||||
"key": "CZ_L",
|
||||
"label": "L",
|
||||
}
|
||||
"KC_SCLN": {
|
||||
"key": "CZ_URNG",
|
||||
"label": "ů",
|
||||
}
|
||||
"KC_QUOT": {
|
||||
"key": "CZ_SECT",
|
||||
"label": "§",
|
||||
}
|
||||
"KC_Z": {
|
||||
"key": "CZ_Y",
|
||||
"label": "Y",
|
||||
}
|
||||
"KC_X": {
|
||||
"key": "CZ_X",
|
||||
"label": "X",
|
||||
}
|
||||
"KC_C": {
|
||||
"key": "CZ_C",
|
||||
"label": "C",
|
||||
}
|
||||
"KC_V": {
|
||||
"key": "CZ_V",
|
||||
"label": "V",
|
||||
}
|
||||
"KC_B": {
|
||||
"key": "CZ_B",
|
||||
"label": "B",
|
||||
}
|
||||
"KC_N": {
|
||||
"key": "CZ_N",
|
||||
"label": "N",
|
||||
}
|
||||
"KC_M": {
|
||||
"key": "CZ_M",
|
||||
"label": "M",
|
||||
}
|
||||
"KC_COMM": {
|
||||
"key": "CZ_COMM",
|
||||
"label": ",",
|
||||
}
|
||||
"KC_DOT": {
|
||||
"key": "CZ_DOT",
|
||||
"label": ".",
|
||||
}
|
||||
"KC_SLSH": {
|
||||
"key": "CZ_MINS",
|
||||
"label": "-",
|
||||
}
|
||||
/* Shifted symbols
|
||||
* ┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬─────┐
|
||||
* │ | │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ 8 │ 9 │ 0 │ % │ ˇ │ │
|
||||
* ├───┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬───┤
|
||||
* │ │ │ │ │ │ │ │ │ │ │ │ / │ ( │ ` │
|
||||
* ├─────┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴───┤
|
||||
* │ │ │ │ │ │ │ │ │ │ │ " │ ! │ │
|
||||
* ├──────┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴──────┤
|
||||
* │ │ │ │ │ │ │ │ │ ? │ : │ _ │ │
|
||||
* ├─────┬──┴─┬─┴───┼───┴───┴───┴───┴───┴───┼───┴─┬─┴──┬─────┤
|
||||
* │ │ │ │ │ │ │ │
|
||||
* └─────┴────┴─────┴───────────────────────┴─────┴────┴─────┘
|
||||
*/
|
||||
"S(CZ_BSLS)": {
|
||||
"key": "CZ_PIPE",
|
||||
"label": "|",
|
||||
}
|
||||
"S(CZ_PLUS)": {
|
||||
"key": "CZ_1",
|
||||
"label": "1",
|
||||
}
|
||||
"S(CZ_ECAR)": {
|
||||
"key": "CZ_2",
|
||||
"label": "2",
|
||||
}
|
||||
"S(CZ_SCAR)": {
|
||||
"key": "CZ_3",
|
||||
"label": "3",
|
||||
}
|
||||
"S(CZ_CCAR)": {
|
||||
"key": "CZ_4",
|
||||
"label": "4",
|
||||
}
|
||||
"S(CZ_RCAR)": {
|
||||
"key": "CZ_5",
|
||||
"label": "5",
|
||||
}
|
||||
"S(CZ_ZCAR)": {
|
||||
"key": "CZ_6",
|
||||
"label": "6",
|
||||
}
|
||||
"S(CZ_YACU)": {
|
||||
"key": "CZ_7",
|
||||
"label": "7",
|
||||
}
|
||||
"S(CZ_AACU)": {
|
||||
"key": "CZ_8",
|
||||
"label": "8",
|
||||
}
|
||||
"S(CZ_IACU)": {
|
||||
"key": "CZ_9",
|
||||
"label": "9",
|
||||
}
|
||||
"S(CZ_EACU)": {
|
||||
"key": "CZ_0",
|
||||
"label": "0",
|
||||
}
|
||||
"S(CZ_EQL)": {
|
||||
"key": "CZ_PERC",
|
||||
"label": "%",
|
||||
}
|
||||
"S(CZ_ACUT)": {
|
||||
"key": "CZ_CARN",
|
||||
"label": "ˇ (dead)",
|
||||
}
|
||||
"S(CZ_UACU)": {
|
||||
"key": "CZ_SLSH",
|
||||
"label": "/",
|
||||
}
|
||||
"S(CZ_RPRN)": {
|
||||
"key": "CZ_LPRN",
|
||||
"label": "(",
|
||||
}
|
||||
"S(CZ_DIAE)": {
|
||||
"key": "CZ_GRV",
|
||||
"label": "`",
|
||||
}
|
||||
"S(CZ_URNG)": {
|
||||
"key": "CZ_DQUO",
|
||||
"label": "\"",
|
||||
}
|
||||
"S(CZ_SECT)": {
|
||||
"key": "CZ_EXLM",
|
||||
"label": "!",
|
||||
}
|
||||
"S(CZ_COMM)": {
|
||||
"key": "CZ_QUES",
|
||||
"label": "?",
|
||||
}
|
||||
"S(CZ_DOT)": {
|
||||
"key": "CZ_COLN",
|
||||
"label": ":",
|
||||
}
|
||||
"S(CZ_MINS)": {
|
||||
"key": "CZ_UNDS",
|
||||
"label": "_",
|
||||
}
|
||||
/* Alted symbols
|
||||
* ┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬─────┐
|
||||
* │ │ │ @ │ # │ $ │ ~ │ ^ │ & │ * │ { │ } │ ° │ ^ │ │
|
||||
* ├───┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬───┤
|
||||
* │ │ │ ė │ ę │ € │ │ │ │ │ │ │ [ │ ] │ │
|
||||
* ├─────┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴───┤
|
||||
* │ │ ą │ ß │ ∂ │ │ │ ‘ │ ’ │ │ ł │ ; │ ' │ │
|
||||
* ├──────┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴──────┤
|
||||
* │ │ │ │ │ │ │ ‚ │ │ < │ > │ – │ │
|
||||
* ├─────┬──┴─┬─┴───┼───┴───┴───┴───┴───┴───┼───┴─┬─┴──┬─────┤
|
||||
* │ │ │ │ │ │ │ │
|
||||
* └─────┴────┴─────┴───────────────────────┴─────┴────┴─────┘
|
||||
*/
|
||||
"A(CZ_ECAR)": {
|
||||
"key": "CZ_AT",
|
||||
"label": "@",
|
||||
}
|
||||
"A(CZ_SCAR)": {
|
||||
"key": "CZ_HASH",
|
||||
"label": "#",
|
||||
}
|
||||
"A(CZ_CCAR)": {
|
||||
"key": "CZ_DLR",
|
||||
"label": "$",
|
||||
}
|
||||
"A(CZ_RCAR)": {
|
||||
"key": "CZ_TILD",
|
||||
"label": "~",
|
||||
}
|
||||
"A(CZ_ZCAR)": {
|
||||
"key": "CZ_CIRC",
|
||||
"label": "^",
|
||||
}
|
||||
"A(CZ_YACU)": {
|
||||
"key": "CZ_AMPR",
|
||||
"label": "&",
|
||||
}
|
||||
"A(CZ_AACU)": {
|
||||
"key": "CZ_ASTR",
|
||||
"label": "*",
|
||||
}
|
||||
"A(CZ_IACU)": {
|
||||
"key": "CZ_LCBR",
|
||||
"label": "{",
|
||||
}
|
||||
"A(CZ_EACU)": {
|
||||
"key": "CZ_RCBR",
|
||||
"label": "}",
|
||||
}
|
||||
"A(CZ_EQL)": {
|
||||
"key": "CZ_RNGA",
|
||||
"label": "° (dead)",
|
||||
}
|
||||
"A(CZ_ACUT)": {
|
||||
"key": "CZ_DCIR",
|
||||
"label": "^ (dead)",
|
||||
}
|
||||
"A(CZ_W)": {
|
||||
"key": "CZ_LEDT",
|
||||
"label": "ė",
|
||||
}
|
||||
"A(CZ_E)": {
|
||||
"key": "CZ_LEOG",
|
||||
"label": "ę",
|
||||
}
|
||||
"A(CZ_R)": {
|
||||
"key": "CZ_EURO",
|
||||
"label": "€",
|
||||
}
|
||||
"A(CZ_Z)": {
|
||||
"key": "CZ_LZDT",
|
||||
"label": "ż",
|
||||
}
|
||||
"A(CZ_UACU)": {
|
||||
"key": "CZ_LBRC",
|
||||
"label": "[",
|
||||
}
|
||||
"A(CZ_RPRN)": {
|
||||
"key": "CZ_RBRC",
|
||||
"label": "]",
|
||||
}
|
||||
"A(CZ_A)": {
|
||||
"key": "CZ_LAOG",
|
||||
"label": "ą",
|
||||
}
|
||||
"A(CZ_S)": {
|
||||
"key": "CZ_SS",
|
||||
"label": "ß",
|
||||
}
|
||||
"A(CZ_D)": {
|
||||
"key": "CZ_PDIF",
|
||||
"label": "∂",
|
||||
}
|
||||
"A(CZ_H)": {
|
||||
"key": "CZ_LSQU",
|
||||
"label": "‘",
|
||||
}
|
||||
"A(CZ_J)": {
|
||||
"key": "CZ_RSQU",
|
||||
"label": "’",
|
||||
}
|
||||
"A(CZ_L)": {
|
||||
"key": "CZ_LLST",
|
||||
"label": "ł",
|
||||
}
|
||||
"A(CZ_URNG)": {
|
||||
"key": "CZ_SCLN",
|
||||
"label": ";",
|
||||
}
|
||||
"A(CZ_SECT)": {
|
||||
"key": "CZ_QUOT",
|
||||
"label": "'",
|
||||
}
|
||||
"A(CZ_N)": {
|
||||
"key": "CZ_SLQU",
|
||||
"label": "‚",
|
||||
}
|
||||
"A(CZ_COMM)": {
|
||||
"key": "CZ_LABK",
|
||||
"label": "<",
|
||||
}
|
||||
"A(CZ_DOT)": {
|
||||
"key": "CZ_RABK",
|
||||
"label": ">",
|
||||
}
|
||||
"A(CZ_MINS)": {
|
||||
"key": "CZ_NDSH",
|
||||
"label": "–",
|
||||
}
|
||||
/* Shift+Alted symbols
|
||||
* ┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬─────┐
|
||||
* │ │ ¬ │ • │ ≠ │ £ │ ◊ │ † │ ¶ │ ÷ │ « │ » │ , │ - │ │
|
||||
* ├───┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬───┤
|
||||
* │ │ │ Ė │ Ę │ ® │ ™ │ Ż │ │ │ │ │ ‹ │ › │ " │
|
||||
* ├─────┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴───┤
|
||||
* │ │ Ą │ ∑ │ ∆ │ │ │ “ │ ” │ │ Ł │ … │ ~ │ │
|
||||
* ├──────┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴──────┤
|
||||
* │ │ │ │ © │ √ │ │ „ │ │ ≤ │ ≥ │ — │ │
|
||||
* ├─────┬──┴─┬─┴───┼───┴───┴───┴───┴───┴───┼───┴─┬─┴──┬─────┤
|
||||
* │ │ │ │ │ │ │ │
|
||||
* └─────┴────┴─────┴───────────────────────┴─────┴────┴─────┘
|
||||
*/
|
||||
"S(A(CZ_1))": {
|
||||
"key": "CZ_NOT",
|
||||
"label": "¬",
|
||||
}
|
||||
"S(A(CZ_2))": {
|
||||
"key": "CZ_BULT",
|
||||
"label": "•",
|
||||
}
|
||||
"S(A(CZ_3))": {
|
||||
"key": "CZ_NEQL",
|
||||
"label": "≠",
|
||||
}
|
||||
"S(A(CZ_4))": {
|
||||
"key": "CZ_PND",
|
||||
"label": "£",
|
||||
}
|
||||
"S(A(CZ_5))": {
|
||||
"key": "CZ_LOZN",
|
||||
"label": "◊",
|
||||
}
|
||||
"S(A(CZ_6))": {
|
||||
"key": "CZ_DAGG",
|
||||
"label": "†",
|
||||
}
|
||||
"S(A(CZ_7))": {
|
||||
"key": "CZ_PARA",
|
||||
"label": "¶",
|
||||
}
|
||||
"S(A(CZ_8))": {
|
||||
"key": "CZ_DIV",
|
||||
"label": "÷",
|
||||
}
|
||||
"S(A(CZ_9))": {
|
||||
"key": "CZ_LDAQ",
|
||||
"label": "«",
|
||||
}
|
||||
"S(A(CZ_0))": {
|
||||
"key": "CZ_RDAQ",
|
||||
"label": "»",
|
||||
}
|
||||
"S(A(CZ_EQL))": {
|
||||
"key": "CZ_DCOM",
|
||||
"label": ", (dead)",
|
||||
}
|
||||
"S(A(CZ_ACUT))": {
|
||||
"key": "CZ_DHPN",
|
||||
"label": "- (dead)",
|
||||
}
|
||||
"S(A(CZ_W))": {
|
||||
"key": "CZ_CEDT",
|
||||
"label": "Ė",
|
||||
}
|
||||
"S(A(CZ_E))": {
|
||||
"key": "CZ_CEOG",
|
||||
"label": "Ę",
|
||||
}
|
||||
"S(A(CZ_R))": {
|
||||
"key": "CZ_REGD",
|
||||
"label": "®",
|
||||
}
|
||||
"S(A(CZ_T))": {
|
||||
"key": "CZ_TM",
|
||||
"label": "™",
|
||||
}
|
||||
"S(A(CZ_Z))": {
|
||||
"key": "CZ_CZDT",
|
||||
"label": "Ż",
|
||||
}
|
||||
"S(A(CZ_UACU))": {
|
||||
"key": "CZ_LSAQ",
|
||||
"label": "‹",
|
||||
}
|
||||
"S(A(CZ_RPRN))": {
|
||||
"key": "CZ_RSAQ",
|
||||
"label": "›",
|
||||
}
|
||||
"S(A(CZ_DIAE))": {
|
||||
"key": "CZ_DDQT",
|
||||
"label": "\" (dead)",
|
||||
}
|
||||
"S(A(CZ_A))": {
|
||||
"key": "CZ_CAOG",
|
||||
"label": "Ą",
|
||||
}
|
||||
"S(A(CZ_S))": {
|
||||
"key": "CZ_NARS",
|
||||
"label": "∑",
|
||||
}
|
||||
"S(A(CZ_D))": {
|
||||
"key": "CZ_INCR",
|
||||
"label": "∆",
|
||||
}
|
||||
"S(A(CZ_H))": {
|
||||
"key": "CZ_LDQU",
|
||||
"label": "“",
|
||||
}
|
||||
"S(A(CZ_J))": {
|
||||
"key": "CZ_RDQU",
|
||||
"label": "”",
|
||||
}
|
||||
"S(A(CZ_L))": {
|
||||
"key": "CZ_CLST",
|
||||
"label": "Ł",
|
||||
}
|
||||
"S(A(CZ_URNG))": {
|
||||
"key": "CZ_ELLP",
|
||||
"label": "…",
|
||||
}
|
||||
"S(A(CZ_SECT))": {
|
||||
"key": "CZ_DTIL",
|
||||
"label": "~ (dead)",
|
||||
}
|
||||
"S(A(CZ_C))": {
|
||||
"key": "CZ_COPY",
|
||||
"label": "©",
|
||||
}
|
||||
"S(A(CZ_V))": {
|
||||
"key": "CZ_SQRT",
|
||||
"label": "√",
|
||||
}
|
||||
"S(A(CZ_N))": {
|
||||
"key": "CZ_DLQU",
|
||||
"label": "„",
|
||||
}
|
||||
"S(A(CZ_COMM))": {
|
||||
"key": "CZ_LEQL",
|
||||
"label": "≤",
|
||||
}
|
||||
"S(A(CZ_DOT))": {
|
||||
"key": "CZ_GEQL",
|
||||
"label": "≥",
|
||||
}
|
||||
"S(A(CZ_MINS))": {
|
||||
"key": "CZ_MDSH",
|
||||
"label": "—",
|
||||
}
|
||||
}
|
||||
}
|
@ -0,0 +1,580 @@
|
||||
{
|
||||
"aliases": {
|
||||
/*
|
||||
* ┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬─────┐
|
||||
* │ │ + │ ě │ š │ č │ ř │ ž │ ý │ á │ í │ é │ = │ ' │ │
|
||||
* ├───┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬───┤
|
||||
* │ │ Q │ W │ E │ R │ T │ Z │ U │ I │ O │ P │ ú │ ) │ │
|
||||
* ├─────┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┐ │
|
||||
* │ │ A │ S │ D │ F │ G │ H │ J │ K │ L │ ů │ § │ ¨ │ │
|
||||
* ├────┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴───┴──┤
|
||||
* │ │ \ │ Y │ X │ C │ V │ B │ N │ M │ , │ . │ - │ │
|
||||
* ├────┴┬──┴─┬─┴───┼───┴───┴───┴───┴───┴───┼───┴─┬─┴──┬─────┤
|
||||
* │ │ │ │ │ │ │ │
|
||||
* └─────┴────┴─────┴───────────────────────┴─────┴────┴─────┘
|
||||
*/
|
||||
"KC_1": {
|
||||
"key": "CZ_PLUS",
|
||||
"label": "+",
|
||||
}
|
||||
"KC_2": {
|
||||
"key": "CZ_ECAR",
|
||||
"label": "ě",
|
||||
}
|
||||
"KC_3": {
|
||||
"key": "CZ_SCAR",
|
||||
"label": "š",
|
||||
}
|
||||
"KC_4": {
|
||||
"key": "CZ_CCAR",
|
||||
"label": "č",
|
||||
}
|
||||
"KC_5": {
|
||||
"key": "CZ_RCAR",
|
||||
"label": "ř",
|
||||
}
|
||||
"KC_6": {
|
||||
"key": "CZ_ZCAR",
|
||||
"label": "ž",
|
||||
}
|
||||
"KC_7": {
|
||||
"key": "CZ_YACU",
|
||||
"label": "ý",
|
||||
}
|
||||
"KC_8": {
|
||||
"key": "CZ_AACU",
|
||||
"label": "á",
|
||||
}
|
||||
"KC_9": {
|
||||
"key": "CZ_IACU",
|
||||
"label": "í",
|
||||
}
|
||||
"KC_0": {
|
||||
"key": "CZ_EACU",
|
||||
"label": "é",
|
||||
}
|
||||
"KC_MINS": {
|
||||
"key": "CZ_EQL",
|
||||
"label": "=",
|
||||
}
|
||||
"KC_EQL": {
|
||||
"key": "CZ_ACUT",
|
||||
"label": "' (dead)",
|
||||
}
|
||||
"KC_Q": {
|
||||
"key": "CZ_Q",
|
||||
"label": "Q",
|
||||
}
|
||||
"KC_W": {
|
||||
"key": "CZ_W",
|
||||
"label": "W",
|
||||
}
|
||||
"KC_E": {
|
||||
"key": "CZ_E",
|
||||
"label": "E",
|
||||
}
|
||||
"KC_R": {
|
||||
"key": "CZ_R",
|
||||
"label": "R",
|
||||
}
|
||||
"KC_T": {
|
||||
"key": "CZ_T",
|
||||
"label": "T",
|
||||
}
|
||||
"KC_Y": {
|
||||
"key": "CZ_Z",
|
||||
"label": "Z",
|
||||
}
|
||||
"KC_U": {
|
||||
"key": "CZ_U",
|
||||
"label": "U",
|
||||
}
|
||||
"KC_I": {
|
||||
"key": "CZ_I",
|
||||
"label": "I",
|
||||
}
|
||||
"KC_O": {
|
||||
"key": "CZ_O",
|
||||
"label": "O",
|
||||
}
|
||||
"KC_P": {
|
||||
"key": "CZ_P",
|
||||
"label": "P",
|
||||
}
|
||||
"KC_LBRC": {
|
||||
"key": "CZ_UACU",
|
||||
"label": "ú",
|
||||
}
|
||||
"KC_RBRC": {
|
||||
"key": "CZ_RPRN",
|
||||
"label": ")",
|
||||
}
|
||||
"KC_A": {
|
||||
"key": "CZ_A",
|
||||
"label": "A",
|
||||
}
|
||||
"KC_S": {
|
||||
"key": "CZ_S",
|
||||
"label": "S",
|
||||
}
|
||||
"KC_D": {
|
||||
"key": "CZ_D",
|
||||
"label": "D",
|
||||
}
|
||||
"KC_F": {
|
||||
"key": "CZ_F",
|
||||
"label": "F",
|
||||
}
|
||||
"KC_G": {
|
||||
"key": "CZ_G",
|
||||
"label": "G",
|
||||
}
|
||||
"KC_H": {
|
||||
"key": "CZ_H",
|
||||
"label": "H",
|
||||
}
|
||||
"KC_J": {
|
||||
"key": "CZ_J",
|
||||
"label": "J",
|
||||
}
|
||||
"KC_K": {
|
||||
"key": "CZ_K",
|
||||
"label": "K",
|
||||
}
|
||||
"KC_L": {
|
||||
"key": "CZ_L",
|
||||
"label": "L",
|
||||
}
|
||||
"KC_SCLN": {
|
||||
"key": "CZ_URNG",
|
||||
"label": "ů",
|
||||
}
|
||||
"KC_QUOT": {
|
||||
"key": "CZ_SECT",
|
||||
"label": "§",
|
||||
}
|
||||
"KC_NUHS": {
|
||||
"key": "CZ_DIAE",
|
||||
"label": "¨ (dead)",
|
||||
}
|
||||
"KC_NUBS": {
|
||||
"key": "CZ_BSLS",
|
||||
"label": "\\",
|
||||
}
|
||||
"KC_Z": {
|
||||
"key": "CZ_Y",
|
||||
"label": "Y",
|
||||
}
|
||||
"KC_X": {
|
||||
"key": "CZ_X",
|
||||
"label": "X",
|
||||
}
|
||||
"KC_C": {
|
||||
"key": "CZ_C",
|
||||
"label": "C",
|
||||
}
|
||||
"KC_V": {
|
||||
"key": "CZ_V",
|
||||
"label": "V",
|
||||
}
|
||||
"KC_B": {
|
||||
"key": "CZ_B",
|
||||
"label": "B",
|
||||
}
|
||||
"KC_N": {
|
||||
"key": "CZ_N",
|
||||
"label": "N",
|
||||
}
|
||||
"KC_M": {
|
||||
"key": "CZ_M",
|
||||
"label": "M",
|
||||
}
|
||||
"KC_COMM": {
|
||||
"key": "CZ_COMM",
|
||||
"label": ",",
|
||||
}
|
||||
"KC_DOT": {
|
||||
"key": "CZ_DOT",
|
||||
"label": ".",
|
||||
}
|
||||
"KC_SLSH": {
|
||||
"key": "CZ_MINS",
|
||||
"label": "-",
|
||||
}
|
||||
/* Shifted symbols
|
||||
* ┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬─────┐
|
||||
* │ │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ 8 │ 9 │ 0 │ % │ ˇ │ │
|
||||
* ├───┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬───┤
|
||||
* │ │ │ │ │ │ │ │ │ │ │ │ / │ ( │ │
|
||||
* ├─────┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┐ │
|
||||
* │ │ │ │ │ │ │ │ │ │ │ " │ ! │ ` │ │
|
||||
* ├────┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴───┴──┤
|
||||
* │ │ | │ │ │ │ │ │ │ │ ? │ : │ _ │ │
|
||||
* ├────┴┬──┴─┬─┴───┼───┴───┴───┴───┴───┴───┼───┴─┬─┴──┬─────┤
|
||||
* │ │ │ │ │ │ │ │
|
||||
* └─────┴────┴─────┴───────────────────────┴─────┴────┴─────┘
|
||||
*/
|
||||
"S(CZ_PLUS)": {
|
||||
"key": "CZ_1",
|
||||
"label": "1",
|
||||
}
|
||||
"S(CZ_ECAR)": {
|
||||
"key": "CZ_2",
|
||||
"label": "2",
|
||||
}
|
||||
"S(CZ_SCAR)": {
|
||||
"key": "CZ_3",
|
||||
"label": "3",
|
||||
}
|
||||
"S(CZ_CCAR)": {
|
||||
"key": "CZ_4",
|
||||
"label": "4",
|
||||
}
|
||||
"S(CZ_RCAR)": {
|
||||
"key": "CZ_5",
|
||||
"label": "5",
|
||||
}
|
||||
"S(CZ_ZCAR)": {
|
||||
"key": "CZ_6",
|
||||
"label": "6",
|
||||
}
|
||||
"S(CZ_YACU)": {
|
||||
"key": "CZ_7",
|
||||
"label": "7",
|
||||
}
|
||||
"S(CZ_AACU)": {
|
||||
"key": "CZ_8",
|
||||
"label": "8",
|
||||
}
|
||||
"S(CZ_IACU)": {
|
||||
"key": "CZ_9",
|
||||
"label": "9",
|
||||
}
|
||||
"S(CZ_EACU)": {
|
||||
"key": "CZ_0",
|
||||
"label": "0",
|
||||
}
|
||||
"S(CZ_EQL)": {
|
||||
"key": "CZ_PERC",
|
||||
"label": "%",
|
||||
}
|
||||
"S(CZ_ACUT)": {
|
||||
"key": "CZ_CARN",
|
||||
"label": "ˇ (dead)",
|
||||
}
|
||||
"S(CZ_UACU)": {
|
||||
"key": "CZ_SLSH",
|
||||
"label": "/",
|
||||
}
|
||||
"S(CZ_RPRN)": {
|
||||
"key": "CZ_LPRN",
|
||||
"label": "(",
|
||||
}
|
||||
"S(CZ_URNG)": {
|
||||
"key": "CZ_DQUO",
|
||||
"label": "\"",
|
||||
}
|
||||
"S(CZ_SECT)": {
|
||||
"key": "CZ_EXLM",
|
||||
"label": "!",
|
||||
}
|
||||
"S(CZ_DIAE)": {
|
||||
"key": "CZ_GRV",
|
||||
"label": "`",
|
||||
}
|
||||
"S(CZ_BSLS)": {
|
||||
"key": "CZ_PIPE",
|
||||
"label": "|",
|
||||
}
|
||||
"S(CZ_COMM)": {
|
||||
"key": "CZ_QUES",
|
||||
"label": "?",
|
||||
}
|
||||
"S(CZ_DOT)": {
|
||||
"key": "CZ_COLN",
|
||||
"label": ":",
|
||||
}
|
||||
"S(CZ_MINS)": {
|
||||
"key": "CZ_UNDS",
|
||||
"label": "_",
|
||||
}
|
||||
/* Alted symbols
|
||||
* ┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬─────┐
|
||||
* │ │ │ @ │ # │ $ │ ~ │ ^ │ & │ * │ { │ } │ ° │ ^ │ │
|
||||
* ├───┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬───┤
|
||||
* │ │ │ ė │ ę │ € │ │ ż │ │ │ │ │ [ │ ] │ │
|
||||
* ├─────┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┐ │
|
||||
* │ │ ą │ ß │ ∂ │ │ │ ‘ │ ’ │ │ ł │ ; │ ' │ │ │
|
||||
* ├────┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴───┴──┤
|
||||
* │ │ │ │ │ │ │ │ ‚ │ │ < │ > │ – │ │
|
||||
* ├────┴┬──┴─┬─┴───┼───┴───┴───┴───┴───┴───┼───┴─┬─┴──┬─────┤
|
||||
* │ │ │ │ │ │ │ │
|
||||
* └─────┴────┴─────┴───────────────────────┴─────┴────┴─────┘
|
||||
*/
|
||||
"A(CZ_ECAR)": {
|
||||
"key": "CZ_AT",
|
||||
"label": "@",
|
||||
}
|
||||
"A(CZ_SCAR)": {
|
||||
"key": "CZ_HASH",
|
||||
"label": "#",
|
||||
}
|
||||
"A(CZ_CCAR)": {
|
||||
"key": "CZ_DLR",
|
||||
"label": "$",
|
||||
}
|
||||
"A(CZ_RCAR)": {
|
||||
"key": "CZ_TILD",
|
||||
"label": "~",
|
||||
}
|
||||
"A(CZ_ZCAR)": {
|
||||
"key": "CZ_CIRC",
|
||||
"label": "^",
|
||||
}
|
||||
"A(CZ_YACU)": {
|
||||
"key": "CZ_AMPR",
|
||||
"label": "&",
|
||||
}
|
||||
"A(CZ_AACU)": {
|
||||
"key": "CZ_ASTR",
|
||||
"label": "*",
|
||||
}
|
||||
"A(CZ_IACU)": {
|
||||
"key": "CZ_LCBR",
|
||||
"label": "{",
|
||||
}
|
||||
"A(CZ_EACU)": {
|
||||
"key": "CZ_RCBR",
|
||||
"label": "}",
|
||||
}
|
||||
"A(CZ_EQL)": {
|
||||
"key": "CZ_RNGA",
|
||||
"label": "° (dead)",
|
||||
}
|
||||
"A(CZ_ACUT)": {
|
||||
"key": "CZ_DCIR",
|
||||
"label": "^ (dead)",
|
||||
}
|
||||
"A(CZ_W)": {
|
||||
"key": "CZ_LEDT",
|
||||
"label": "ė",
|
||||
}
|
||||
"A(CZ_E)": {
|
||||
"key": "CZ_LEOG",
|
||||
"label": "ę",
|
||||
}
|
||||
"A(CZ_R)": {
|
||||
"key": "CZ_EURO",
|
||||
"label": "€",
|
||||
}
|
||||
"A(CZ_Z)": {
|
||||
"key": "CZ_LZDT",
|
||||
"label": "ż",
|
||||
}
|
||||
"A(CZ_UACU)": {
|
||||
"key": "CZ_LBRC",
|
||||
"label": "[",
|
||||
}
|
||||
"A(CZ_RPRN)": {
|
||||
"key": "CZ_RBRC",
|
||||
"label": "]",
|
||||
}
|
||||
"A(CZ_A)": {
|
||||
"key": "CZ_LAOG",
|
||||
"label": "ą",
|
||||
}
|
||||
"A(CZ_S)": {
|
||||
"key": "CZ_SS",
|
||||
"label": "ß",
|
||||
}
|
||||
"A(CZ_D)": {
|
||||
"key": "CZ_PDIF",
|
||||
"label": "∂",
|
||||
}
|
||||
"A(CZ_H)": {
|
||||
"key": "CZ_LSQU",
|
||||
"label": "‘",
|
||||
}
|
||||
"A(CZ_J)": {
|
||||
"key": "CZ_RSQU",
|
||||
"label": "’",
|
||||
}
|
||||
"A(CZ_L)": {
|
||||
"key": "CZ_LLST",
|
||||
"label": "ł",
|
||||
}
|
||||
"A(CZ_URNG)": {
|
||||
"key": "CZ_SCLN",
|
||||
"label": ";",
|
||||
}
|
||||
"A(CZ_SECT)": {
|
||||
"key": "CZ_QUOT",
|
||||
"label": "'",
|
||||
}
|
||||
"A(CZ_N)": {
|
||||
"key": "CZ_SLQU",
|
||||
"label": "‚",
|
||||
}
|
||||
"A(CZ_COMM)": {
|
||||
"key": "CZ_LABK",
|
||||
"label": "<",
|
||||
}
|
||||
"A(CZ_DOT)": {
|
||||
"key": "CZ_RABK",
|
||||
"label": ">",
|
||||
}
|
||||
"A(CZ_MINS)": {
|
||||
"key": "CZ_NDSH",
|
||||
"label": "–",
|
||||
}
|
||||
/* Shift+Alted symbols
|
||||
* ┌───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬─────┐
|
||||
* │ │ ¬ │ • │ ≠ │ £ │ ◊ │ † │ ¶ │ ÷ │ « │ » │ , │ - │ │
|
||||
* ├───┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬───┤
|
||||
* │ │ │ Ė │ Ę │ ® │ ™ │ Ż │ │ │ │ │ ‹ │ › │ │
|
||||
* ├─────┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┬──┴┐ │
|
||||
* │ │ Ą │ ∑ │ ∆ │ │ │ “ │ ” │ │ Ł │ … │ ~ │ " │ │
|
||||
* ├────┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴─┬─┴───┴──┤
|
||||
* │ │ │ │ │ © │ √ │ │ „ │ │ ≤ │ ≥ │ — │ │
|
||||
* ├────┴┬──┴─┬─┴───┼───┴───┴───┴───┴───┴───┼───┴─┬─┴──┬─────┤
|
||||
* │ │ │ │ │ │ │ │
|
||||
* └─────┴────┴─────┴───────────────────────┴─────┴────┴─────┘
|
||||
*/
|
||||
"S(A(CZ_1))": {
|
||||
"key": "CZ_NOT",
|
||||
"label": "¬",
|
||||
}
|
||||
"S(A(CZ_2))": {
|
||||
"key": "CZ_BULT",
|
||||
"label": "•",
|
||||
}
|
||||
"S(A(CZ_3))": {
|
||||
"key": "CZ_NEQL",
|
||||
"label": "≠",
|
||||
}
|
||||
"S(A(CZ_4))": {
|
||||
"key": "CZ_PND",
|
||||
"label": "£",
|
||||
}
|
||||
"S(A(CZ_5))": {
|
||||
"key": "CZ_LOZN",
|
||||
"label": "◊",
|
||||
}
|
||||
"S(A(CZ_6))": {
|
||||
"key": "CZ_DAGG",
|
||||
"label": "†",
|
||||
}
|
||||
"S(A(CZ_7))": {
|
||||
"key": "CZ_PARA",
|
||||
"label": "¶",
|
||||
}
|
||||
"S(A(CZ_8))": {
|
||||
"key": "CZ_DIV",
|
||||
"label": "÷",
|
||||
}
|
||||
"S(A(CZ_9))": {
|
||||
"key": "CZ_LDAQ",
|
||||
"label": "«",
|
||||
}
|
||||
"S(A(CZ_0))": {
|
||||
"key": "CZ_RDAQ",
|
||||
"label": "»",
|
||||
}
|
||||
"S(A(CZ_EQL))": {
|
||||
"key": "CZ_DCOM",
|
||||
"label": ", (dead)",
|
||||
}
|
||||
"S(A(CZ_ACUT))": {
|
||||
"key": "CZ_DHPN",
|
||||
"label": "- (dead)",
|
||||
}
|
||||
"S(A(CZ_W))": {
|
||||
"key": "CZ_CEDT",
|
||||
"label": "Ė",
|
||||
}
|
||||
"S(A(CZ_E))": {
|
||||
"key": "CZ_CEOG",
|
||||
"label": "Ę",
|
||||
}
|
||||
"S(A(CZ_R))": {
|
||||
"key": "CZ_REGD",
|
||||
"label": "®",
|
||||
}
|
||||
"S(A(CZ_T))": {
|
||||
"key": "CZ_TM",
|
||||
"label": "™",
|
||||
}
|
||||
"S(A(CZ_Z))": {
|
||||
"key": "CZ_CZDT",
|
||||
"label": "Ż",
|
||||
}
|
||||
"S(A(CZ_UACU))": {
|
||||
"key": "CZ_LSAQ",
|
||||
"label": "‹",
|
||||
}
|
||||
"S(A(CZ_RPRN))": {
|
||||
"key": "CZ_RSAQ",
|
||||
"label": "›",
|
||||
}
|
||||
"S(A(CZ_A))": {
|
||||
"key": "CZ_CAOG",
|
||||
"label": "Ą",
|
||||
}
|
||||
"S(A(CZ_S))": {
|
||||
"key": "CZ_NARS",
|
||||
"label": "∑",
|
||||
}
|
||||
"S(A(CZ_D))": {
|
||||
"key": "CZ_INCR",
|
||||
"label": "∆",
|
||||
}
|
||||
"S(A(CZ_H))": {
|
||||
"key": "CZ_LDQU",
|
||||
"label": "“",
|
||||
}
|
||||
"S(A(CZ_J))": {
|
||||
"key": "CZ_RDQU",
|
||||
"label": "”",
|
||||
}
|
||||
"S(A(CZ_L))": {
|
||||
"key": "CZ_CLST",
|
||||
"label": "Ł",
|
||||
}
|
||||
"S(A(CZ_URNG))": {
|
||||
"key": "CZ_ELLP",
|
||||
"label": "…",
|
||||
}
|
||||
"S(A(CZ_SECT))": {
|
||||
"key": "CZ_DTIL",
|
||||
"label": "~ (dead)",
|
||||
}
|
||||
"S(A(CZ_DIAE))": {
|
||||
"key": "CZ_DDQT",
|
||||
"label": "\" (dead)",
|
||||
}
|
||||
"S(A(CZ_C))": {
|
||||
"key": "CZ_COPY",
|
||||
"label": "©",
|
||||
}
|
||||
"S(A(CZ_V))": {
|
||||
"key": "CZ_SQRT",
|
||||
"label": "√",
|
||||
}
|
||||
"S(A(CZ_N))": {
|
||||
"key": "CZ_DLQU",
|
||||
"label": "„",
|
||||
}
|
||||
"S(A(CZ_COMM))": {
|
||||
"key": "CZ_LEQL",
|
||||
"label": "≤",
|
||||
}
|
||||
"S(A(CZ_DOT))": {
|
||||
"key": "CZ_GEQL",
|
||||
"label": "≥",
|
||||
}
|
||||
"S(A(CZ_MINS))": {
|
||||
"key": "CZ_MDSH",
|
||||
"label": "—",
|
||||
}
|
||||
}
|
||||
}
|
239
data/constants/keycodes/keycodes_0.0.4_lighting.hjson
Normal file
239
data/constants/keycodes/keycodes_0.0.4_lighting.hjson
Normal file
@ -0,0 +1,239 @@
|
||||
{
|
||||
"keycodes": {
|
||||
"0x7810": {
|
||||
"group": "led_matrix",
|
||||
"key": "QK_LED_MATRIX_ON",
|
||||
"aliases": [
|
||||
"LM_ON"
|
||||
]
|
||||
},
|
||||
"0x7811": {
|
||||
"group": "led_matrix",
|
||||
"key": "QK_LED_MATRIX_OFF",
|
||||
"aliases": [
|
||||
"LM_OFF"
|
||||
]
|
||||
},
|
||||
"0x7812": {
|
||||
"group": "led_matrix",
|
||||
"key": "QK_LED_MATRIX_TOGGLE",
|
||||
"aliases": [
|
||||
"LM_TOGG"
|
||||
]
|
||||
},
|
||||
"0x7813": {
|
||||
"group": "led_matrix",
|
||||
"key": "QK_LED_MATRIX_MODE_NEXT",
|
||||
"aliases": [
|
||||
"LM_NEXT"
|
||||
]
|
||||
},
|
||||
"0x7814": {
|
||||
"group": "led_matrix",
|
||||
"key": "QK_LED_MATRIX_MODE_PREVIOUS",
|
||||
"aliases": [
|
||||
"LM_PREV"
|
||||
]
|
||||
},
|
||||
"0x7815": {
|
||||
"group": "led_matrix",
|
||||
"key": "QK_LED_MATRIX_BRIGHTNESS_UP",
|
||||
"aliases": [
|
||||
"LM_BRIU"
|
||||
]
|
||||
},
|
||||
"0x7816": {
|
||||
"group": "led_matrix",
|
||||
"key": "QK_LED_MATRIX_BRIGHTNESS_DOWN",
|
||||
"aliases": [
|
||||
"LM_BRID"
|
||||
]
|
||||
},
|
||||
"0x7817": {
|
||||
"group": "led_matrix",
|
||||
"key": "QK_LED_MATRIX_SPEED_UP",
|
||||
"aliases": [
|
||||
"LM_SPDU"
|
||||
]
|
||||
},
|
||||
"0x7818": {
|
||||
"group": "led_matrix",
|
||||
"key": "QK_LED_MATRIX_SPEED_DOWN",
|
||||
"aliases": [
|
||||
"LM_SPDD"
|
||||
]
|
||||
},
|
||||
|
||||
"0x7820": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_TOGGLE",
|
||||
"aliases": [
|
||||
"UG_TOGG"
|
||||
]
|
||||
},
|
||||
"0x7821": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_MODE_NEXT",
|
||||
"aliases": [
|
||||
"!reset!",
|
||||
"UG_NEXT"
|
||||
]
|
||||
},
|
||||
"0x7822": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_MODE_PREVIOUS",
|
||||
"aliases": [
|
||||
"!reset!",
|
||||
"UG_PREV"
|
||||
]
|
||||
},
|
||||
"0x7823": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_HUE_UP",
|
||||
"aliases": [
|
||||
"UG_HUEU"
|
||||
]
|
||||
},
|
||||
"0x7824": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_HUE_DOWN",
|
||||
"aliases": [
|
||||
"UG_HUED"
|
||||
]
|
||||
},
|
||||
"0x7825": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_SATURATION_UP",
|
||||
"aliases": [
|
||||
"UG_SATU"
|
||||
]
|
||||
},
|
||||
"0x7826": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_SATURATION_DOWN",
|
||||
"aliases": [
|
||||
"UG_SATD"
|
||||
]
|
||||
},
|
||||
"0x7827": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_VALUE_UP",
|
||||
"aliases": [
|
||||
"UG_VALU"
|
||||
]
|
||||
},
|
||||
"0x7828": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_VALUE_DOWN",
|
||||
"aliases": [
|
||||
"UG_VALD"
|
||||
]
|
||||
},
|
||||
"0x7829": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_SPEED_UP",
|
||||
"aliases": [
|
||||
"UG_SPDU"
|
||||
]
|
||||
},
|
||||
"0x782A": {
|
||||
"group": "underglow",
|
||||
"key": "QK_UNDERGLOW_SPEED_DOWN",
|
||||
"aliases": [
|
||||
"UG_SPDD"
|
||||
]
|
||||
},
|
||||
|
||||
"0x7840": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_ON",
|
||||
"aliases": [
|
||||
"RM_ON"
|
||||
]
|
||||
},
|
||||
"0x7841": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_OFF",
|
||||
"aliases": [
|
||||
"RM_OFF"
|
||||
]
|
||||
},
|
||||
"0x7842": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_TOGGLE",
|
||||
"aliases": [
|
||||
"RM_TOGG"
|
||||
]
|
||||
},
|
||||
"0x7843": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_MODE_NEXT",
|
||||
"aliases": [
|
||||
"RM_NEXT"
|
||||
]
|
||||
},
|
||||
"0x7844": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_MODE_PREVIOUS",
|
||||
"aliases": [
|
||||
"RM_PREV"
|
||||
]
|
||||
},
|
||||
"0x7845": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_HUE_UP",
|
||||
"aliases": [
|
||||
"RM_HUEU"
|
||||
]
|
||||
},
|
||||
"0x7846": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_HUE_DOWN",
|
||||
"aliases": [
|
||||
"RM_HUED"
|
||||
]
|
||||
},
|
||||
"0x7847": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_SATURATION_UP",
|
||||
"aliases": [
|
||||
"RM_SATU"
|
||||
]
|
||||
},
|
||||
"0x7848": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_SATURATION_DOWN",
|
||||
"aliases": [
|
||||
"RM_SATD"
|
||||
]
|
||||
},
|
||||
"0x7849": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_VALUE_UP",
|
||||
"aliases": [
|
||||
"RM_VALU"
|
||||
]
|
||||
},
|
||||
"0x784A": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_VALUE_DOWN",
|
||||
"aliases": [
|
||||
"RM_VALD"
|
||||
]
|
||||
},
|
||||
"0x784B": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_SPEED_UP",
|
||||
"aliases": [
|
||||
"RM_SPDU"
|
||||
]
|
||||
},
|
||||
"0x784C": {
|
||||
"group": "rgb_matrix",
|
||||
"key": "QK_RGB_MATRIX_SPEED_DOWN",
|
||||
"aliases": [
|
||||
"RM_SPDD"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
@ -19,6 +19,8 @@
|
||||
// Audio
|
||||
"AUDIO_DEFAULT_ON": {"info_key": "audio.default.on", "value_type": "bool"},
|
||||
"AUDIO_DEFAULT_CLICKY_ON": {"info_key": "audio.default.clicky", "value_type": "bool"},
|
||||
"AUDIO_POWER_CONTROL_PIN": {"info_key": "audio.power_control.pin"},
|
||||
"AUDIO_POWER_CONTROL_PIN_ON_STATE": {"info_key": "audio.power_control.on_state", "value_type": "int" },
|
||||
"AUDIO_VOICES": {"info_key": "audio.voices", "value_type": "flag"},
|
||||
"SENDSTRING_BELL": {"info_key": "audio.macro_beep", "value_type": "flag"},
|
||||
|
||||
@ -162,7 +164,6 @@
|
||||
"RGBLIGHT_DEFAULT_SAT": {"info_key": "rgblight.default.sat", "value_type": "int"},
|
||||
"RGBLIGHT_DEFAULT_VAL": {"info_key": "rgblight.default.val", "value_type": "int"},
|
||||
"RGBLIGHT_DEFAULT_SPD": {"info_key": "rgblight.default.speed", "value_type": "int"},
|
||||
"RGBW": {"info_key": "rgblight.rgbw", "value_type": "flag"},
|
||||
|
||||
// Secure
|
||||
"SECURE_IDLE_TIMEOUT": {"info_key": "secure.idle_timeout", "value_type": "int"},
|
||||
@ -213,6 +214,7 @@
|
||||
"WS2812_DI_PIN": {"info_key": "ws2812.pin"},
|
||||
"WS2812_I2C_ADDRESS": {"info_key": "ws2812.i2c_address", "value_type": "hex"},
|
||||
"WS2812_I2C_TIMEOUT": {"info_key": "ws2812.i2c_timeout", "value_type": "int"},
|
||||
"WS2812_RGBW": {"info_key": "ws2812.rgbw", "value_type": "flag"},
|
||||
|
||||
"LAYOUTS": {"info_key": "layout_aliases", "value_type": "mapping"},
|
||||
|
||||
@ -227,6 +229,7 @@
|
||||
"PREVENT_STUCK_MODIFIERS": {"info_key": "_invalid.prevent_stuck_mods", "invalid": true},
|
||||
"QMK_KEYS_PER_SCAN": {"info_key": "qmk.keys_per_scan", "value_type": "int", "deprecated": true},
|
||||
"RGB_DI_PIN": {"info_key": "rgblight.pin", "invalid": true, "replace_with": "WS2812_DI_PIN or APA102_DI_PIN"},
|
||||
"RGBW": {"info_key": "rgblight.rgbw", "invalid": true, "replace_with": "WS2812_RGBW"},
|
||||
"RGB_DISABLE_WHEN_USB_SUSPENDED": {"info_key": "_invalid.rgb_matrix_sleep", "invalid": true, "replace_with": "RGB_MATRIX_SLEEP"},
|
||||
"RGBLIGHT_ANIMATIONS": {"info_key": "_invalid.rgblight.animations.all", "value_type": "flag", "invalid": true},
|
||||
"TAPPING_FORCE_HOLD": {"info_key": "tapping.force_hold", "value_type": "flag", "deprecated": true},
|
||||
|
@ -11,6 +11,7 @@
|
||||
// invalid: Default `false`. Set to `true` to generate errors when a value exists
|
||||
// replace_with: use with a key marked deprecated or invalid to designate a replacement
|
||||
|
||||
"AUDIO_DRIVER": {"info_key": "audio.driver"},
|
||||
"BACKLIGHT_DRIVER": {"info_key": "backlight.driver"},
|
||||
"BLUETOOTH_DRIVER": {"info_key": "bluetooth.driver"},
|
||||
"BOARD": {"info_key": "board"},
|
||||
@ -23,6 +24,7 @@
|
||||
"ENCODER_ENABLE": {"info_key": "encoder.enabled", "value_type": "bool"},
|
||||
"ENCODER_DRIVER": {"info_key": "encoder.driver"},
|
||||
"FIRMWARE_FORMAT": {"info_key": "build.firmware_format"},
|
||||
"HAPTIC_DRIVER": {"info_key": "haptic.driver"},
|
||||
"KEYBOARD_SHARED_EP": {"info_key": "usb.shared_endpoint.keyboard", "value_type": "bool"},
|
||||
"LAYOUTS": {"info_key": "community_layouts", "value_type": "list"},
|
||||
"LED_MATRIX_DRIVER": {"info_key": "led_matrix.driver"},
|
||||
@ -43,7 +45,7 @@
|
||||
"SPLIT_TRANSPORT": {"info_key": "split.transport.protocol", "to_c": false},
|
||||
"STENO_ENABLE": {"info_key": "stenography.enabled", "value_type": "bool"},
|
||||
"STENO_PROTOCOL": {"info_key": "stenography.protocol"},
|
||||
"WAIT_FOR_USB": {"info_key": "usb.wait_for", "value_type": "bool"},
|
||||
"USB_WAIT_FOR_ENUMERATION": {"info_key": "usb.wait_for_enumeration", "value_type": "bool"},
|
||||
"WEAR_LEVELING_DRIVER": {"info_key": "eeprom.wear_leveling.driver"},
|
||||
"WS2812_DRIVER": {"info_key": "ws2812.driver"},
|
||||
|
||||
|
@ -306,13 +306,13 @@
|
||||
"target": "jacky_studio/piggy60/rev1"
|
||||
},
|
||||
"jj40": {
|
||||
"target": "kprepublic/jj40"
|
||||
"target": "kprepublic/jj40/rev1"
|
||||
},
|
||||
"jj4x4": {
|
||||
"target": "kprepublic/jj4x4"
|
||||
},
|
||||
"jj50": {
|
||||
"target": "kprepublic/jj50"
|
||||
"target": "kprepublic/jj50/rev1"
|
||||
},
|
||||
"jm60": {
|
||||
"target": "kbdfans/jm60"
|
||||
@ -1518,5 +1518,12 @@
|
||||
// Moved during 2023 Q4 cycle
|
||||
"ymdk/melody96": {
|
||||
"target": "ymdk/melody96/soldered"
|
||||
},
|
||||
// Moved during 2024 Q2 cycle
|
||||
"kprepublic/jj40": {
|
||||
"target": "kprepublic/jj40/rev1"
|
||||
},
|
||||
"kprepublic/jj50": {
|
||||
"target": "kprepublic/jj50/rev1"
|
||||
}
|
||||
}
|
||||
|
@ -40,7 +40,8 @@
|
||||
"pattern": "^[0-9a-z_/\\-]+\\.json$"
|
||||
},
|
||||
"key_unit": {
|
||||
"type": "number"
|
||||
"type": "number",
|
||||
"minimum": 0
|
||||
},
|
||||
"keyboard": {
|
||||
"type": "string",
|
||||
|
@ -133,8 +133,20 @@
|
||||
"clicky": {"type": "boolean"}
|
||||
}
|
||||
},
|
||||
"driver": {
|
||||
"type": "string",
|
||||
"enum": ["dac_additive", "dac_basic", "pwm_software", "pwm_hardware"]
|
||||
},
|
||||
"macro_beep": {"type": "boolean"},
|
||||
"pins": {"$ref": "qmk.definitions.v1#/mcu_pin_array"},
|
||||
"power_control": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
"properties": {
|
||||
"on_state": {"$ref": "qmk.definitions.v1#/bit"},
|
||||
"pin": {"$ref": "qmk.definitions.v1#/mcu_pin"}
|
||||
}
|
||||
},
|
||||
"voices": {"type": "boolean"}
|
||||
}
|
||||
},
|
||||
@ -380,6 +392,15 @@
|
||||
}
|
||||
}
|
||||
},
|
||||
"haptic": {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"driver": {
|
||||
"type": "string",
|
||||
"enum": ["drv2605l", "solenoid"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"leader_key": {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
@ -446,6 +467,7 @@
|
||||
"enum": [
|
||||
"custom",
|
||||
"is31fl3218",
|
||||
"is31fl3236",
|
||||
"is31fl3729",
|
||||
"is31fl3731",
|
||||
"is31fl3733",
|
||||
@ -494,8 +516,8 @@
|
||||
"minimum": 0
|
||||
}
|
||||
},
|
||||
"x": {"$ref": "qmk.definitions.v1#/key_unit"},
|
||||
"y": {"$ref": "qmk.definitions.v1#/key_unit"},
|
||||
"x": {"$ref": "qmk.definitions.v1#/unsigned_int"},
|
||||
"y": {"$ref": "qmk.definitions.v1#/unsigned_int"},
|
||||
"flags": {"$ref": "qmk.definitions.v1#/unsigned_int_8"}
|
||||
}
|
||||
}
|
||||
@ -528,6 +550,7 @@
|
||||
"aw20216s",
|
||||
"custom",
|
||||
"is31fl3218",
|
||||
"is31fl3236",
|
||||
"is31fl3729",
|
||||
"is31fl3731",
|
||||
"is31fl3733",
|
||||
@ -579,8 +602,8 @@
|
||||
"minimum": 0
|
||||
}
|
||||
},
|
||||
"x": {"$ref": "qmk.definitions.v1#/key_unit"},
|
||||
"y": {"$ref": "qmk.definitions.v1#/key_unit"},
|
||||
"x": {"$ref": "qmk.definitions.v1#/unsigned_int"},
|
||||
"y": {"$ref": "qmk.definitions.v1#/unsigned_int"},
|
||||
"flags": {"$ref": "qmk.definitions.v1#/unsigned_int_8"}
|
||||
}
|
||||
}
|
||||
@ -639,7 +662,10 @@
|
||||
"$ref": "qmk.definitions.v1#/mcu_pin",
|
||||
"$comment": "Deprecated: use ws2812.pin instead"
|
||||
},
|
||||
"rgbw": {"type": "boolean"},
|
||||
"rgbw": {
|
||||
"type": "boolean",
|
||||
"$comment": "Deprecated: use ws2812.rgbw instead"
|
||||
},
|
||||
"saturation_steps": {"$ref": "qmk.definitions.v1#/unsigned_int"},
|
||||
"sleep": {"type": "boolean"},
|
||||
"split": {"type": "boolean"},
|
||||
@ -780,7 +806,7 @@
|
||||
"properties": {
|
||||
"protocol": {
|
||||
"type": "string",
|
||||
"enum": ["custom", "i2c", "serial", "serial_usart"]
|
||||
"enum": ["custom", "i2c", "serial"]
|
||||
},
|
||||
"sync": {
|
||||
"type": "object",
|
||||
@ -876,7 +902,7 @@
|
||||
}
|
||||
},
|
||||
"suspend_wakeup_delay": {"$ref": "qmk.definitions.v1#/unsigned_int"},
|
||||
"wait_for": {"type": "boolean"}
|
||||
"wait_for_enumeration": {"type": "boolean"}
|
||||
}
|
||||
},
|
||||
"qmk": {
|
||||
@ -915,6 +941,7 @@
|
||||
"enum": ["bitbang", "custom", "i2c", "pwm", "spi", "vendor"]
|
||||
},
|
||||
"pin": {"$ref": "qmk.definitions.v1#/mcu_pin"},
|
||||
"rgbw": {"type": "boolean"},
|
||||
"i2c_address": {"$ref": "qmk.definitions.v1#/hex_number_2d"},
|
||||
"i2c_timeout": {"$ref": "qmk.definitions.v1#/unsigned_int"}
|
||||
}
|
||||
|
@ -1,20 +0,0 @@
|
||||
// Copyright %YEAR% %REAL_NAME% (@%USER_NAME%)
|
||||
// SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
#pragma once
|
||||
|
||||
/*
|
||||
* Feature disable options
|
||||
* These options are also useful to firmware size reduction.
|
||||
*/
|
||||
|
||||
/* disable debug print */
|
||||
//#define NO_DEBUG
|
||||
|
||||
/* disable print */
|
||||
//#define NO_PRINT
|
||||
|
||||
/* disable action features */
|
||||
//#define NO_ACTION_LAYER
|
||||
//#define NO_ACTION_TAPPING
|
||||
//#define NO_ACTION_ONESHOT
|
@ -1 +0,0 @@
|
||||
docs.qmk.fm
|
@ -20,7 +20,7 @@ This document marks the inaugural Breaking Change merge. A list of changes follo
|
||||
|
||||
* `fn_actions` is deprecated, and its functionality has been superseded by direct keycodes and `process_record_user()`
|
||||
* The end result of removing this obsolete feature should result in a decent reduction in firmware size and code complexity
|
||||
* All keymaps affected are recommended to switch away from `fn_actions` in favour of the [custom keycode](https://docs.qmk.fm/#/custom_quantum_functions) and [macro](https://docs.qmk.fm/#/feature_macros) features
|
||||
* All keymaps affected are recommended to switch away from `fn_actions` in favour of the [custom keycode](../custom_quantum_functions) and [macro](../feature_macros) features
|
||||
|
||||
## Update Atreus to current code conventions
|
||||
|
||||
@ -43,7 +43,7 @@ This document marks the inaugural Breaking Change merge. A list of changes follo
|
||||
|
||||
* `fn_actions` is deprecated, and its functionality has been superseded by direct keycodes and `process_record_user()`
|
||||
* All keymaps using these actions have had the relevant `KC_FN*` keys replaced with the equivalent `BL_*` keys
|
||||
* If you currently use `KC_FN*` you will need to replace `fn_actions` with the [custom keycode](https://docs.qmk.fm/#/custom_quantum_functions) and [macro](https://docs.qmk.fm/#/feature_macros) features
|
||||
* If you currently use `KC_FN*` you will need to replace `fn_actions` with the [custom keycode](../custom_quantum_functions) and [macro](../feature_macros) features
|
||||
|
||||
## Remove `KC_DELT` alias in favor of `KC_DEL`
|
||||
|
||||
|
@ -51,7 +51,7 @@ Four times a year QMK runs a process for merging Breaking Changes. A Breaking Ch
|
||||
|
||||
* `fn_actions` is deprecated, and its functionality has been superseded by direct keycodes and `process_record_user()`
|
||||
* The end result of removing this obsolete feature should result in a decent reduction in firmware size and code complexity
|
||||
* All keymaps affected are recommended to switch away from `fn_actions` in favour of the [custom keycode](https://docs.qmk.fm/#/custom_quantum_functions) and [macro](https://docs.qmk.fm/#/feature_macros) features
|
||||
* All keymaps affected are recommended to switch away from `fn_actions` in favour of the [custom keycode](../custom_quantum_functions) and [macro](../feature_macros) features
|
||||
|
||||
|
||||
## Moving backlight keycode handling to `process_keycode/`
|
||||
|
@ -3,9 +3,9 @@
|
||||
Four times a year QMK runs a process for merging Breaking Changes. A Breaking Change is any change which modifies how QMK behaves in a way that is incompatible or potentially dangerous. We limit these changes to 4 times per year so that users can have confidence that updating their QMK tree will not break their keymaps.
|
||||
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Relocated Keyboards :id=relocated-keyboards
|
||||
### Relocated Keyboards {#relocated-keyboards}
|
||||
|
||||
#### The Key Company project consolidation ([#9547](https://github.com/qmk/qmk_firmware/pull/9547))
|
||||
#### relocating boards by flehrad to flehrad/ folder ([#9635](https://github.com/qmk/qmk_firmware/pull/9635))
|
||||
@ -24,7 +24,7 @@ handwired/numbrero | flehrad/numbrero
|
||||
snagpad | flehrad/snagpad
|
||||
handwired/tradestation | flehrad/tradestation
|
||||
|
||||
### Updated Keyboard Codebases :id=keyboard-updates
|
||||
### Updated Keyboard Codebases {#keyboard-updates}
|
||||
|
||||
#### Keebio RGB wiring update ([#7754](https://github.com/qmk/qmk_firmware/pull/7754))
|
||||
|
||||
@ -46,7 +46,7 @@ This change affects:
|
||||
* Quefrency rev1
|
||||
* Viterbi, revs. 1 and 2
|
||||
|
||||
### Changes to Core Functionality :id=core-updates
|
||||
### Changes to Core Functionality {#core-updates}
|
||||
|
||||
* Bigger Combo index ([#9318](https://github.com/qmk/qmk_firmware/pull/9318))
|
||||
|
||||
@ -58,14 +58,14 @@ Any fork that uses `process_combo_event` needs to update the function's first ar
|
||||
* New function: `void process_combo_event(uint16_t combo_index, bool pressed)`
|
||||
|
||||
|
||||
## Core Changes :id=core-changes
|
||||
## Core Changes {#core-changes}
|
||||
|
||||
### Fixes :id=core-fixes
|
||||
### Fixes {#core-fixes}
|
||||
|
||||
* Mousekeys: scrolling acceleration is no longer coupled to mouse movement acceleration ([#9174](https://github.com/qmk/qmk_firmware/pull/9174))
|
||||
* Keymap Extras: correctly assign Question Mark in Czech layout ([#9987](https://github.com/qmk/qmk_firmware/pull/9987))
|
||||
|
||||
### Additions and Enhancements :id=core-additions
|
||||
### Additions and Enhancements {#core-additions}
|
||||
|
||||
* allow for WS2812 PWM to work on DMAMUX-capable devices ([#9471](https://github.com/qmk/qmk_firmware/pull/9471))
|
||||
* Newer STM32 MCUs have a DMAMUX peripheral, which allows mapping of DMAs to different DMA streams, rather than hard-defining the target streams in silicon.
|
||||
@ -109,7 +109,7 @@ Any fork that uses `process_combo_event` needs to update the function's first ar
|
||||
* The K-Type has been refactored to use QMK's native matrix scanning routine, and now has partial support for the RGB Matrix feature.
|
||||
* Joysticks can now be used without defining analog pins ([#10169](https://github.com/qmk/qmk_firmware/pull/10169))
|
||||
|
||||
### Clean-ups and Optimizations :id=core-optimizations
|
||||
### Clean-ups and Optimizations {#core-optimizations}
|
||||
|
||||
* iWRAP protocol removed ([#9284](https://github.com/qmk/qmk_firmware/pull/9284))
|
||||
* work begun for consolidation of ChibiOS platform files ([#8327](https://github.com/qmk/qmk_firmware/pull/8327) and [#9315](https://github.com/qmk/qmk_firmware/pull/9315))
|
||||
@ -140,7 +140,7 @@ Any fork that uses `process_combo_event` needs to update the function's first ar
|
||||
* remove support for Adafruit EZ Key Bluetooth controller ([#10103](https://github.com/qmk/qmk_firmware/pull/10103))
|
||||
|
||||
|
||||
## QMK Infrastructure and Internals :id=qmk-internals
|
||||
## QMK Infrastructure and Internals {#qmk-internals}
|
||||
|
||||
* Attempt to fix CI for non-master branches. ([#9308](https://github.com/qmk/qmk_firmware/pull/9308))
|
||||
* Actually fetch the branch we're attempting to compare against.
|
||||
|
@ -3,9 +3,9 @@
|
||||
Four times a year QMK runs a process for merging Breaking Changes. A Breaking Change is any change which modifies how QMK behaves in a way that is incompatible or potentially dangerous. We limit these changes to 4 times per year so that users can have confidence that updating their QMK tree will not break their keymaps.
|
||||
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Relocated Keyboards :id=relocated-keyboards
|
||||
### Relocated Keyboards {#relocated-keyboards}
|
||||
|
||||
#### Reduce Helix keyboard build variation ([#8669](https://github.com/qmk/qmk_firmware/pull/8669))
|
||||
|
||||
@ -88,21 +88,21 @@ The Valor and Dawn60 keyboards by Xelus22 both now require their revisions to be
|
||||
| xelus/valor | xelus/valor/rev1 |
|
||||
|
||||
|
||||
### Updated Keyboard Codebases :id=keyboard-updates
|
||||
### Updated Keyboard Codebases {#keyboard-updates}
|
||||
|
||||
#### AEboards EXT65 Refactor ([#10820](https://github.com/qmk/qmk_firmware/pull/10820))
|
||||
|
||||
The EXT65 codebase has been reworked so keymaps can be used with either revision.
|
||||
|
||||
|
||||
## Core Changes :id=core-changes
|
||||
## Core Changes {#core-changes}
|
||||
|
||||
### Fixes :id=core-fixes
|
||||
### Fixes {#core-fixes}
|
||||
|
||||
* Reconnect the USB if users wake up a computer from the keyboard to restore the USB state ([#10088](https://github.com/qmk/qmk_firmware/pull/10088))
|
||||
* Fix cursor position bug in oled_write_raw functions ([#10800](https://github.com/qmk/qmk_firmware/pull/10800))
|
||||
|
||||
### Additions and Enhancements :id=core-additions
|
||||
### Additions and Enhancements {#core-additions}
|
||||
|
||||
* Allow MATRIX_ROWS to be greater than 32 ([#10183](https://github.com/qmk/qmk_firmware/pull/10183))
|
||||
* Add support for soft serial to ATmega32U2 ([#10204](https://github.com/qmk/qmk_firmware/pull/10204))
|
||||
@ -119,7 +119,7 @@ The EXT65 codebase has been reworked so keymaps can be used with either revision
|
||||
* Add AT90USB support for serial.c ([#10706](https://github.com/qmk/qmk_firmware/pull/10706))
|
||||
* Auto shift: support repeats and early registration (#9826)
|
||||
|
||||
### Clean-ups and Optimizations :id=core-optimizations
|
||||
### Clean-ups and Optimizations {#core-optimizations}
|
||||
|
||||
* Haptic and solenoid cleanup ([#9700](https://github.com/qmk/qmk_firmware/pull/9700))
|
||||
* XD75 cleanup ([#10524](https://github.com/qmk/qmk_firmware/pull/10524))
|
||||
@ -129,7 +129,7 @@ The EXT65 codebase has been reworked so keymaps can be used with either revision
|
||||
* Remove references to HD44780 ([#10735](https://github.com/qmk/qmk_firmware/pull/10735))
|
||||
|
||||
|
||||
## QMK Infrastructure and Internals :id=qmk-internals
|
||||
## QMK Infrastructure and Internals {#qmk-internals}
|
||||
|
||||
* Add ability to build a subset of all keyboards based on platform. ([#10420](https://github.com/qmk/qmk_firmware/pull/10420))
|
||||
* Initialise EEPROM drivers at startup, instead of upon first execution ([#10438](https://github.com/qmk/qmk_firmware/pull/10438))
|
||||
|
@ -1,30 +1,30 @@
|
||||
# QMK Breaking Changes - 2021 May 29 Changelog
|
||||
|
||||
## Notable Changes :id=notable-changes
|
||||
## Notable Changes {#notable-changes}
|
||||
|
||||
### RGB Matrix support for split common ([#11055](https://github.com/qmk/qmk_firmware/pull/11055)) :id=rgb-matrix-split-common
|
||||
### RGB Matrix support for split common ([#11055](https://github.com/qmk/qmk_firmware/pull/11055)) {#rgb-matrix-split-common}
|
||||
|
||||
Split boards can now use RGB Matrix without defining a custom matrix.
|
||||
|
||||
### Teensy 3.6 support ([#12258](https://github.com/qmk/qmk_firmware/pull/12258)) :id=teensy-3-6-support
|
||||
### Teensy 3.6 support ([#12258](https://github.com/qmk/qmk_firmware/pull/12258)) {#teensy-3-6-support}
|
||||
|
||||
Added support for MK66F18 (Teensy 3.6) microcontroller.
|
||||
|
||||
### New command: qmk console ([#12828](https://github.com/qmk/qmk_firmware/pull/12828)) :id=new-command-qmk-console
|
||||
### New command: qmk console ([#12828](https://github.com/qmk/qmk_firmware/pull/12828)) {#new-command-qmk-console}
|
||||
|
||||
A new `qmk console` command has been added for attaching to your keyboard's console. It operates similiarly to QMK Toolbox by allowing you to connect to one or more keyboard consoles to display debugging messages.
|
||||
|
||||
### Improved command: qmk config :id=improve-command-qmk-config
|
||||
### Improved command: qmk config {#improve-command-qmk-config}
|
||||
|
||||
We've updated the `qmk config` command to show only the configuration items you have actually set. You can now display (almost) all of the available configuration options, along with their default values, using `qmk config -a`.
|
||||
|
||||
### LED Matrix Improvements ([#12509](https://github.com/qmk/qmk_firmware/pull/12509), [#12580](https://github.com/qmk/qmk_firmware/pull/12580), [#12588](https://github.com/qmk/qmk_firmware/pull/12588), [#12633](https://github.com/qmk/qmk_firmware/pull/12633), [#12651](https://github.com/qmk/qmk_firmware/pull/12651), [#12685](https://github.com/qmk/qmk_firmware/pull/12685)) :id=led-matrix-improvements
|
||||
### LED Matrix Improvements ([#12509](https://github.com/qmk/qmk_firmware/pull/12509), [#12580](https://github.com/qmk/qmk_firmware/pull/12580), [#12588](https://github.com/qmk/qmk_firmware/pull/12588), [#12633](https://github.com/qmk/qmk_firmware/pull/12633), [#12651](https://github.com/qmk/qmk_firmware/pull/12651), [#12685](https://github.com/qmk/qmk_firmware/pull/12685)) {#led-matrix-improvements}
|
||||
|
||||
LED Matrix has been improved with effects, CIE1931 curves, and a task system.
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
* Durgod keyboard refactor in preparation for adding additional durgod keyboards ([#11978](https://github.com/qmk/qmk_firmware/pull/11978))
|
||||
* Updated Function96 with V2 files and removed chconf.h and halconf.h ([#12613](https://github.com/qmk/qmk_firmware/pull/12613))
|
||||
@ -52,7 +52,7 @@ The codebase for the [Durgod K320](https://github.com/qmk/qmk_firmware/tree/0.13
|
||||
|
||||
Additionally, the `crkbd/rev1/legacy` keyboard has been removed.
|
||||
|
||||
### Bootmagic Deprecation and Refactor ([#12172](https://github.com/qmk/qmk_firmware/pull/12172)) :id=bootmagic-deprecation-and-refactor
|
||||
### Bootmagic Deprecation and Refactor ([#12172](https://github.com/qmk/qmk_firmware/pull/12172)) {#bootmagic-deprecation-and-refactor}
|
||||
|
||||
QMK has decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option.
|
||||
|
||||
@ -68,11 +68,11 @@ This is the current planned roadmap for the behavior of `BOOTMAGIC_ENABLE`:
|
||||
- From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no` – setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail.
|
||||
- From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no` – setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail.
|
||||
|
||||
### Removal of LAYOUT_kc ([#12160](https://github.com/qmk/qmk_firmware/pull/12160)) :id=removal-of-layout-kc
|
||||
### Removal of LAYOUT_kc ([#12160](https://github.com/qmk/qmk_firmware/pull/12160)) {#removal-of-layout-kc}
|
||||
|
||||
We've removed support for `LAYOUT_kc` macros, if your keymap uses one you will need to update it use a regular `LAYOUT` macro.
|
||||
|
||||
### Encoder callbacks are now boolean ([#12805](https://github.com/qmk/qmk_firmware/pull/12805), [#12985](https://github.com/qmk/qmk_firmware/pull/12985)) :id=encoder-callback-boolean
|
||||
### Encoder callbacks are now boolean ([#12805](https://github.com/qmk/qmk_firmware/pull/12805), [#12985](https://github.com/qmk/qmk_firmware/pull/12985)) {#encoder-callback-boolean}
|
||||
|
||||
To allow for keyboards to override (or not) keymap level code the `encoder_update_kb` function has been changed from `void` to `bool`. You will need to update your function definition to reflect this and ensure that you return a `true` or `false` value.
|
||||
|
||||
@ -127,9 +127,9 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
|
||||
}
|
||||
```
|
||||
|
||||
## Core Changes :id=core-changes
|
||||
## Core Changes {#core-changes}
|
||||
|
||||
### Fixes :id=core-fixes
|
||||
### Fixes {#core-fixes}
|
||||
|
||||
* Fix connection issue in split keyboards when slave and OLED display are connected via I2C (fixes #9335) ([#11487](https://github.com/qmk/qmk_firmware/pull/11487))
|
||||
* Terrazzo: Fix wrong LED Matrix function names ([#12561](https://github.com/qmk/qmk_firmware/pull/12561))
|
||||
@ -147,7 +147,7 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
|
||||
* [Keyboard] Fix Terrazzo build failure ([#12977](https://github.com/qmk/qmk_firmware/pull/12977))
|
||||
* Do not hard set config in CPTC files ([#11864](https://github.com/qmk/qmk_firmware/pull/11864))
|
||||
|
||||
### Additions and Enhancements :id=core-additions
|
||||
### Additions and Enhancements {#core-additions}
|
||||
|
||||
* ARM - Refactor SLEEP_LED to support more platforms ([#8403](https://github.com/qmk/qmk_firmware/pull/8403))
|
||||
* Add ability to toggle One Shot functionality ([#4198](https://github.com/qmk/qmk_firmware/pull/4198))
|
||||
@ -193,7 +193,7 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
|
||||
* Backlight: add defines for default level and breathing state ([#12560](https://github.com/qmk/qmk_firmware/pull/12560), [#13024](https://github.com/qmk/qmk_firmware/pull/13024))
|
||||
* Add dire message about LUFA mass storage bootloader ([#13014](https://github.com/qmk/qmk_firmware/pull/13014))
|
||||
|
||||
### Clean-ups and Optimizations :id=core-optimizations
|
||||
### Clean-ups and Optimizations {#core-optimizations}
|
||||
|
||||
* Overhaul bootmagic logic to have single entrypoint ([#8532](https://github.com/qmk/qmk_firmware/pull/8532))
|
||||
* Refactor of USB code within split_common ([#11890](https://github.com/qmk/qmk_firmware/pull/11890))
|
||||
@ -218,7 +218,7 @@ bool encoder_update_user(uint8_t index, bool clockwise) {
|
||||
* Deprecate `send_unicode_hex_string()` ([#12602](https://github.com/qmk/qmk_firmware/pull/12602))
|
||||
* [Keyboard] Remove redundant legacy and common headers for crkbd ([#13023](https://github.com/qmk/qmk_firmware/pull/13023))
|
||||
|
||||
### QMK Infrastructure and Internals :id=qmk-internals
|
||||
### QMK Infrastructure and Internals {#qmk-internals}
|
||||
|
||||
* trivial change to trigger api update ([`b15288fb87`](https://github.com/qmk/qmk_firmware/commit/b15288fb87))
|
||||
* fix some references to bin/qmk that slipped in ([#12832](https://github.com/qmk/qmk_firmware/pull/12832))
|
||||
|
@ -1,28 +1,28 @@
|
||||
# QMK Breaking Changes - 2021 August 28 Changelog
|
||||
|
||||
## Notable Features :id=notable-features
|
||||
## Notable Features {#notable-features}
|
||||
|
||||
### Combo processing improvements ([#8591](https://github.com/qmk/qmk_firmware/pull/8591)) :id=combo-processing-improvements
|
||||
### Combo processing improvements ([#8591](https://github.com/qmk/qmk_firmware/pull/8591)) {#combo-processing-improvements}
|
||||
|
||||
Combo processing has been reordered with respect to keypress handling, allowing for much better compatibility with mod taps.
|
||||
|
||||
It is also now possible to define combos that have keys overlapping with other combos, triggering only one. For example, a combo of `A`, `B` can coexist with a longer combo of `A`, `B`, `C` -- previous functionality would trigger both combos if all three keys were pressed.
|
||||
|
||||
### Key Overrides ([#11422](https://github.com/qmk/qmk_firmware/pull/11422)) :id=key-overrides
|
||||
### Key Overrides ([#11422](https://github.com/qmk/qmk_firmware/pull/11422)) {#key-overrides}
|
||||
|
||||
QMK now has a new feature: [key overrides](https://docs.qmk.fm/#/feature_key_overrides). This feature allows for overriding the output of key combinations involving modifiers. As an example, pressing <kbd>Shift+2</kbd> normally results in an <kbd>@</kbd> on US-ANSI keyboard layouts -- the new key overrides allow for adding similar functionality, but for any <kbd>modifier + key</kbd> press.
|
||||
QMK now has a new feature: [key overrides](../features/key_overrides). This feature allows for overriding the output of key combinations involving modifiers. As an example, pressing <kbd>Shift+2</kbd> normally results in an <kbd>@</kbd> on US-ANSI keyboard layouts -- the new key overrides allow for adding similar functionality, but for any <kbd>modifier + key</kbd> press.
|
||||
|
||||
To illustrate, it's now possible to use the key overrides feature to translate <kbd>Shift + Backspace</kbd> into <kbd>Delete</kbd> -- an often-requested example of where this functionality comes in handy.
|
||||
|
||||
There's far more to describe that what lives in this changelog, so head over to the [key overrides documentation](https://docs.qmk.fm/#/feature_key_overrides) for more examples and info.
|
||||
There's far more to describe that what lives in this changelog, so head over to the [key overrides documentation](../features/key_overrides) for more examples and info.
|
||||
|
||||
### Digitizer support ([#12851](https://github.com/qmk/qmk_firmware/pull/12851))
|
||||
|
||||
QMK gained the ability to pretend to be a digitizer device -- much like a tablet device. A mouse uses delta-coordinates -- move up, move right -- but a digitizer works with absolute coordinates -- top left, bottom right.
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
The following keyboards have had their source moved within QMK:
|
||||
|
||||
@ -69,7 +69,7 @@ xd84pro | xiudi/xd84pro
|
||||
xd87 | xiudi/xd87
|
||||
xd96 | xiudi/xd96
|
||||
|
||||
### Bootmagic Full Removal ([#13846](https://github.com/qmk/qmk_firmware/pull/13846)) :id=bootmagic-full-removal
|
||||
### Bootmagic Full Removal ([#13846](https://github.com/qmk/qmk_firmware/pull/13846)) {#bootmagic-full-removal}
|
||||
|
||||
As noted during last breaking changes cycle, QMK has decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option.
|
||||
|
||||
@ -85,7 +85,7 @@ This is the current roadmap for the behavior of `BOOTMAGIC_ENABLE`:
|
||||
- (now) From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no` – setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail.
|
||||
- (next) From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no` – setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail.
|
||||
|
||||
### DIP switch callbacks are now boolean ([#13399](https://github.com/qmk/qmk_firmware/pull/13399)) :id=dip-switch-boolean
|
||||
### DIP switch callbacks are now boolean ([#13399](https://github.com/qmk/qmk_firmware/pull/13399)) {#dip-switch-boolean}
|
||||
|
||||
To match the encoder change last breaking changes cycle, DIP switch callbacks now return `bool`, too.
|
||||
|
||||
@ -149,9 +149,9 @@ bool dip_switch_update_mask_user(uint32_t state) {
|
||||
}
|
||||
```
|
||||
|
||||
## Notable core changes :id=notable-core
|
||||
## Notable core changes {#notable-core}
|
||||
|
||||
### Split transport improvements :id=split-transport-improvements
|
||||
### Split transport improvements {#split-transport-improvements}
|
||||
|
||||
Split keyboards gained a significant amount of improvements during this breaking changes cycle, specifically:
|
||||
|
||||
@ -160,9 +160,11 @@ Split keyboards gained a significant amount of improvements during this breaking
|
||||
* Make solo half of split keyboards (more) usable. ([#13523](https://github.com/qmk/qmk_firmware/pull/13523)) -- allows the slave to be disconnected, enabling one-handed use.
|
||||
* Switch split_common to CRC subsystem ([#13418](https://github.com/qmk/qmk_firmware/pull/13418))
|
||||
|
||||
!> If you're updating your split keyboard, you will need to flash both sides of the split with the your firmware.
|
||||
::: warning
|
||||
If you're updating your split keyboard, you will need to flash both sides of the split with the your firmware.
|
||||
:::
|
||||
|
||||
### Teensy 4.x support ([#13056](https://github.com/qmk/qmk_firmware/pull/13056), [#13076](https://github.com/qmk/qmk_firmware/pull/13076), [#13077](https://github.com/qmk/qmk_firmware/pull/13077)) :id=teensy-4-x-support
|
||||
### Teensy 4.x support ([#13056](https://github.com/qmk/qmk_firmware/pull/13056), [#13076](https://github.com/qmk/qmk_firmware/pull/13076), [#13077](https://github.com/qmk/qmk_firmware/pull/13077)) {#teensy-4-x-support}
|
||||
|
||||
Updated ChibiOS and ChibiOS-Contrib, which brought in support for Teensy 4.x dev boards, running NXP i.MX1062.
|
||||
|
||||
@ -243,7 +245,7 @@ We've added dozens of new keys to `info.json` so that you can configure more tha
|
||||
* `usb.force_nkro`, `usb.max_power`, `usb.no_startup_check`, `usb.polling_interval`, `usb.shared_endpoint.keyboard`, `usb.shared_endpoint.mouse`, `usb.suspend_wakeup_delay`, `usb.wait_for`
|
||||
* `qmk.keys_per_scan`, `qmk.tap_keycode_delay`, `qmk.tap_capslock_delay`
|
||||
|
||||
### Codebase restructure and cleanup :id=codebase-restructure
|
||||
### Codebase restructure and cleanup {#codebase-restructure}
|
||||
|
||||
QMK was originally based on TMK, and has grown in size considerably since its first inception. To keep moving things forward, restructure of some of the core areas of the code is needed to support new concepts and new hardware, and progress is happening along those lines:
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# QMK Breaking Changes - 2021 November 27 Changelog
|
||||
|
||||
## 2000 keyboards! :id=qmk-2000th-keyboard
|
||||
## 2000 keyboards! {#qmk-2000th-keyboard}
|
||||
|
||||
QMK had it's 2000th keyboard submitted during this breaking changes cycle.... and it only _just_ made the cut-off!
|
||||
|
||||
@ -11,9 +11,9 @@ QMK had it's 2000th keyboard submitted during this breaking changes cycle.... an
|
||||
|
||||
From the whole QMK team, a major thankyou to the community for embracing QMK as your preferred keyboard firmware!
|
||||
|
||||
## Notable Features :id=notable-features
|
||||
## Notable Features {#notable-features}
|
||||
|
||||
### Expanded Pointing Device support ([#14343](https://github.com/qmk/qmk_firmware/pull/14343)) :id=expanded-pointing-device
|
||||
### Expanded Pointing Device support ([#14343](https://github.com/qmk/qmk_firmware/pull/14343)) {#expanded-pointing-device}
|
||||
|
||||
Pointing device support has been reworked and reimplemented to allow for easier integration of new peripherals.
|
||||
|
||||
@ -31,9 +31,9 @@ QMK now has core-supplied support for the following pointing device peripherals:
|
||||
| `POINTING_DEVICE_DRIVER = pimoroni_trackball` | Pimoroni Trackball |
|
||||
| `POINTING_DEVICE_DRIVER = pmw3360` | PMW 3360 |
|
||||
|
||||
See the new documentation for the [Pointing Device](../feature_pointing_device.md) feature for more information on specific configuration for each driver.
|
||||
See the new documentation for the [Pointing Device](../features/pointing_device) feature for more information on specific configuration for each driver.
|
||||
|
||||
### Dynamic Tapping Term ([#11036](https://github.com/qmk/qmk_firmware/pull/11036)) :id=dynamic-tapping-term
|
||||
### Dynamic Tapping Term ([#11036](https://github.com/qmk/qmk_firmware/pull/11036)) {#dynamic-tapping-term}
|
||||
|
||||
For people who are starting out with tapping keys, or for people who think tapping keys don't "feel right", it's sometimes quite difficult to determine what duration of tapping term to use to make things seem natural.
|
||||
|
||||
@ -47,9 +47,9 @@ If you're in this stage of discovery, you can now add `DYNAMIC_TAPPING_TERM_ENAB
|
||||
|
||||
Coupled with the use of `qmk console` or QMK Toolbox to show console output from your keyboard, you can tweak the tapping term dynamically in order to narrow down what "feels right" to you. Once you're happy, drop in the resulting number into your keymap's `config.h` and you're good to go!
|
||||
|
||||
### Macros in JSON keymaps ([#14374](https://github.com/qmk/qmk_firmware/pull/14374)) :id=macros-in-keymap-json
|
||||
### Macros in JSON keymaps ([#14374](https://github.com/qmk/qmk_firmware/pull/14374)) {#macros-in-keymap-json}
|
||||
|
||||
You can now define up to 32 macros in your `keymap.json` file, as used by [QMK Configurator](newbs_building_firmware_configurator.md), and `qmk compile`. You can define these macros in a list under the `macros` keyword, like this:
|
||||
You can now define up to 32 macros in your `keymap.json` file, as used by [QMK Configurator](../newbs_building_firmware_configurator), and `qmk compile`. You can define these macros in a list under the `macros` keyword, like this:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -83,9 +83,9 @@ You can now define up to 32 macros in your `keymap.json` file, as used by [QMK C
|
||||
|
||||
In due course, [QMK Configurator](https://config.qmk.fm/) will pick up support for defining these in its UI, but for now the json is the only way to define macros.
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
The following keyboards have had their source moved within QMK:
|
||||
|
||||
@ -104,21 +104,21 @@ The following keyboards have had their source moved within QMK:
|
||||
| signum/3_0/elitec | signum/3_0 |
|
||||
| tgr/jane | tgr/jane/v2 |
|
||||
|
||||
### Squeezing space out of AVR ([#15243](https://github.com/qmk/qmk_firmware/pull/15243)) :id=squeezing-space-from-avr
|
||||
### Squeezing space out of AVR ([#15243](https://github.com/qmk/qmk_firmware/pull/15243)) {#squeezing-space-from-avr}
|
||||
|
||||
The AVR platform has been problematic for some time, in the sense that it is severely resource-constrained -- this makes life difficult for anyone attempting to add new functionality such as display panels to their keymap code. The illustrious Drashna has contributed some newer documentation on how to attempt to free up some space on AVR-based keyboards that are in short supply.
|
||||
|
||||
Of course, there are much fewer constraints with ARM chips... ;)
|
||||
|
||||
### Require explicit enabling of RGB Matrix modes ([#15018](https://github.com/qmk/qmk_firmware/pull/15018)) :id=explicit-rgb-modes
|
||||
### Require explicit enabling of RGB Matrix modes ([#15018](https://github.com/qmk/qmk_firmware/pull/15018)) {#explicit-rgb-modes}
|
||||
|
||||
Related to the previous section -- RGB Matrix modes have now been made to be opt-in, rather than opt-out. As these animations are now opt-in, you may find that your keyboard no longer has all the RGB modes you're expecting -- you may need to configure and recompile your firmware and enable your animations of choice... with any luck they'll still fit in the space available.
|
||||
|
||||
Most keyboards keep their original functionality, but over time the QMK maintainers have found that removal of animations ends up being the quickest way to free up space... and some keyboards have had animations such as reactive effects disabled by default in order to still fit within the flash space available.
|
||||
|
||||
The full list of configurables to turn specific animations back on can be found at on the [RGB Matrix documentation](feature_rgb_matrix.md#rgb-matrix-effects) page.
|
||||
The full list of configurables to turn specific animations back on can be found at on the [RGB Matrix documentation](../features/rgb_matrix#rgb-matrix-effects) page.
|
||||
|
||||
### OLED task refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/14864)) :id=oled-task-refactor
|
||||
### OLED task refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/14864)) {#oled-task-refactor}
|
||||
|
||||
OLED display code was traditionally difficult to override in keymaps as they did not follow the standard pattern of `bool *_kb()` deferring to `bool *_user()` functions, allowing signalling to the higher level that processing had already been done.
|
||||
|
||||
@ -152,7 +152,7 @@ bool oled_task_kb(void) {
|
||||
}
|
||||
```
|
||||
|
||||
### Bootmagic Full Removal ([#15002](https://github.com/qmk/qmk_firmware/pull/15002)) :id=bootmagic-full-removal
|
||||
### Bootmagic Full Removal ([#15002](https://github.com/qmk/qmk_firmware/pull/15002)) {#bootmagic-full-removal}
|
||||
|
||||
As noted during previous breaking changes cycles, QMK decided to deprecate the full Bootmagic feature and leave Bootmagic Lite as the only remaining option.
|
||||
|
||||
@ -170,13 +170,13 @@ This is the historical timeline for the behavior of `BOOTMAGIC_ENABLE`:
|
||||
- (done) From 2021 Aug 28, `BOOTMAGIC_ENABLE` must be either `yes`, `lite`, or `no` – setting `BOOTMAGIC_ENABLE = full` will cause compilation to fail.
|
||||
- (now) From 2021 Nov 27, `BOOTMAGIC_ENABLE` must be either `yes` or `no` – setting `BOOTMAGIC_ENABLE = lite` will cause compilation to fail.
|
||||
|
||||
### Remove QWIIC_DRIVERS ([#14174](https://github.com/qmk/qmk_firmware/pull/14174)) :id=remove-qwiic
|
||||
### Remove QWIIC_DRIVERS ([#14174](https://github.com/qmk/qmk_firmware/pull/14174)) {#remove-qwiic}
|
||||
|
||||
Due to minimal QWIIC adoption and other options for similar functionality, the QWIIC drivers were removed from QMK. Existing OLED usages have been migrated across to the normal QMK OLED driver instead.
|
||||
|
||||
## Notable core changes :id=notable-core
|
||||
## Notable core changes {#notable-core}
|
||||
|
||||
### New MCU Support :id=new-mcu-support
|
||||
### New MCU Support {#new-mcu-support}
|
||||
|
||||
QMK firmware picked up support for a handful of new MCU families, potentially making it a bit easier to source components.
|
||||
|
||||
@ -187,7 +187,7 @@ QMK firmware is now no longer limited to AVR and ARM - it also picked up support
|
||||
* Westberrytech pr ([#14422](https://github.com/qmk/qmk_firmware/pull/14422))
|
||||
* Initial pass of F405 support ([#14584](https://github.com/qmk/qmk_firmware/pull/14584))
|
||||
|
||||
### EEPROM Changes :id=eeprom-changes
|
||||
### EEPROM Changes {#eeprom-changes}
|
||||
|
||||
There were a few EEPROM-related changes that landed during this breaking changes cycle, most prominently the long-awaited ability for the Drop boards to gain persistent storage. Any users of the Drop CTRL or Drop ALT should update QMK Toolbox as well -- coupled with a QMK firmware update settings should now be saved.
|
||||
|
||||
@ -197,7 +197,7 @@ There were a few EEPROM-related changes that landed during this breaking changes
|
||||
* Further tidy up of STM32 eeprom emulation ([#14591](https://github.com/qmk/qmk_firmware/pull/14591))
|
||||
* Enable eeprom with F401xE ld ([#14752](https://github.com/qmk/qmk_firmware/pull/14752))
|
||||
|
||||
### Compilation Database :id=compile-commands
|
||||
### Compilation Database {#compile-commands}
|
||||
|
||||
A clang-compatible compilation database generator has been added as an option in order to help development environments such as Visual Studio Code.
|
||||
|
||||
@ -208,7 +208,7 @@ Do note that switching keyboards will require re-generation of this file.
|
||||
* New CLI subcommand to create clang-compatible compilation database (`compile_commands.json`) ([#14370](https://github.com/qmk/qmk_firmware/pull/14370))
|
||||
* compiledb: query include paths from gcc directly. ([#14462](https://github.com/qmk/qmk_firmware/pull/14462))
|
||||
|
||||
### Codebase restructure and cleanup :id=codebase-restructure
|
||||
### Codebase restructure and cleanup {#codebase-restructure}
|
||||
|
||||
QMK continues on its restructuring journey, in order to make it easier to integrate newer features and add support for new hardware. This quarter's batch of changes include:
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# QMK Breaking Changes - 2022 February 26 Changelog
|
||||
|
||||
## Notable Features :id=notable-features
|
||||
## Notable Features {#notable-features}
|
||||
|
||||
### Default USB Polling rate now 1kHz ([#15352](https://github.com/qmk/qmk_firmware/pull/15352))
|
||||
|
||||
@ -12,13 +12,13 @@ Something something *Lets go gamers!*
|
||||
|
||||
Pointing devices can now be shared across a split keyboard with support for a single pointing device or a pointing device on each side.
|
||||
|
||||
See the [Pointing Device](feature_pointing_device.md) documentation for further configuration options.
|
||||
See the [Pointing Device](../features/pointing_device) documentation for further configuration options.
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Legacy macro and action_function system removed ([#16025](https://github.com/qmk/qmk_firmware/pull/16025))
|
||||
|
||||
The long time deprecated `MACRO()` and `action_get_macro` methods have been removed. Where possible, existing usages have been migrated over to core [Macros](feature_macros.md).
|
||||
The long time deprecated `MACRO()` and `action_get_macro` methods have been removed. Where possible, existing usages have been migrated over to core [Macros](../feature_macros).
|
||||
|
||||
### Create a build error if no bootloader is specified ([#16181](https://github.com/qmk/qmk_firmware/pull/16181))
|
||||
|
||||
@ -31,7 +31,7 @@ Bootloader configuration is no longer assumed. Keyboards must now set either:
|
||||
|
||||
In preparation of future bluetooth work, the `AdafruitBLE` integration has been renamed to allow potential for any other Adafruit BLE products.
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
The following keyboards have had their source moved within QMK:
|
||||
|
||||
@ -241,9 +241,9 @@ The following keyboards have had their source moved within QMK:
|
||||
| zinc/rev1 | 25keys/zinc/rev1 |
|
||||
| zinc/reva | 25keys/zinc/reva |
|
||||
|
||||
## Notable core changes :id=notable-core
|
||||
## Notable core changes {#notable-core}
|
||||
|
||||
### New MCU Support :id=new-mcu-support
|
||||
### New MCU Support {#new-mcu-support}
|
||||
|
||||
Building on previous cycles, QMK firmware picked up support for a couple extra MCU variants:
|
||||
|
||||
|
@ -1,16 +1,16 @@
|
||||
# QMK Breaking Changes - 2022 May 28 Changelog
|
||||
|
||||
## Notable Features :id=notable-features
|
||||
## Notable Features {#notable-features}
|
||||
|
||||
### Caps Word ([#16588](https://github.com/qmk/qmk_firmware/pull/16588)) :id=caps-word
|
||||
### Caps Word ([#16588](https://github.com/qmk/qmk_firmware/pull/16588)) {#caps-word}
|
||||
|
||||
This is a new feature that allows for capslock-like functionality that turns itself off at the end of the word.
|
||||
|
||||
For instance, if you wish to type "QMK" without holding shift the entire time, you can either tap both left and right shift, or double-tap shift, to turn on _Caps Word_ -- then type `qmk` (lowercase) without holding shift. Once you hit any key other than `a`--`z`, `0`--`9`, `-`, `_`, delete, or backspace, this will go back to normal typing!
|
||||
|
||||
There are other activation mechanisms as well as configurable options like timeout and the like -- see the [Caps Word documentation](feature_caps_word.md) for more information.
|
||||
There are other activation mechanisms as well as configurable options like timeout and the like -- see the [Caps Word documentation](../features/caps_word) for more information.
|
||||
|
||||
### Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174)) :id=quantum-painter
|
||||
### Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174)) {#quantum-painter}
|
||||
|
||||
QMK has had support for small OLED displays for some time now, but hasn't really gained too much ability to draw to panels other than the SSD1306 or SH1106 panels.
|
||||
|
||||
@ -18,27 +18,31 @@ Quantum Painter is a new drawing subsystem available to suitable ARM and RISC-V
|
||||
|
||||
The QMK CLI has new commands added to be able to generate images and fonts for Quantum Painter to digest -- it's even capable of converting animated gifs for display on screen.
|
||||
|
||||
See the [Quantum Painter documentation](quantum_painter.md) for more information on how to set up the displays as well as how to convert images and fonts.
|
||||
See the [Quantum Painter documentation](../quantum_painter) for more information on how to set up the displays as well as how to convert images and fonts.
|
||||
|
||||
!> Quantum Painter is not supported on AVR due to complexity and size constraints. Boards based on AVR such as ProMicro or Elite-C builds will not be able to leverage Quantum Painter.
|
||||
::: warning
|
||||
Quantum Painter is not supported on AVR due to complexity and size constraints. Boards based on AVR such as ProMicro or Elite-C builds will not be able to leverage Quantum Painter.
|
||||
:::
|
||||
|
||||
### Encoder Mapping ([#13286](https://github.com/qmk/qmk_firmware/pull/13286)) :id=encoder-mapping
|
||||
### Encoder Mapping ([#13286](https://github.com/qmk/qmk_firmware/pull/13286)) {#encoder-mapping}
|
||||
|
||||
One of the long-standing complaints with Encoders is that there has been no easy way to configure them in user keymaps. [#13286](https://github.com/qmk/qmk_firmware/pull/13286) added support for [Encoder Mapping](feature_encoders.md#encoder-map), which allows users to define encoder functionality in a similar way to their normal keymap.
|
||||
One of the long-standing complaints with Encoders is that there has been no easy way to configure them in user keymaps. [#13286](https://github.com/qmk/qmk_firmware/pull/13286) added support for [Encoder Mapping](../features/encoders#encoder-map), which allows users to define encoder functionality in a similar way to their normal keymap.
|
||||
|
||||
!> This is not yet supported by QMK Configurator. It is also unlikely to ever be supported by VIA.
|
||||
::: warning
|
||||
This is not yet supported by QMK Configurator. It is also unlikely to ever be supported by VIA.
|
||||
:::
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### `RESET` => `QK_BOOT` ([#17037](https://github.com/qmk/qmk_firmware/pull/17037)) :id=reset-2-qk_boot
|
||||
### `RESET` => `QK_BOOT` ([#17037](https://github.com/qmk/qmk_firmware/pull/17037)) {#reset-2-qk_boot}
|
||||
|
||||
QMK is always in the process of picking up support for new hardware platforms. One of the side-effects for future integrations has shown that QMK's usage of `RESET` as a keycode is causing naming collisions. As a result, [#17037](https://github.com/qmk/qmk_firmware/pull/17037) changed usages of `RESET` to the new keycode `QK_BOOT` in the majority of default-like keymaps. At this stage the old keycode is still usable but will likely be removed in the next breaking changes cycle. Users with keymaps containing `RESET` should also move to `QK_BOOT`.
|
||||
|
||||
### Sendstring keycode overhaul ([#16941](https://github.com/qmk/qmk_firmware/pull/16941)) :id=sendstring-keycodes
|
||||
### Sendstring keycode overhaul ([#16941](https://github.com/qmk/qmk_firmware/pull/16941)) {#sendstring-keycodes}
|
||||
|
||||
Some keycodes used with `SEND_STRING` and its relatives have been deprecated and may have their old keycode usages removed at a later date. The list of [deprecated keycodes](https://github.com/qmk/qmk_firmware/blob/ebd402788346aa6e88bde1486b2a835684d40d39/quantum/send_string_keycodes.h#L456-L505) should be consulted to determine if you're using one of the older names (the first identifier after `#define`) -- you should swap to the newer variant (the second identifier on the same line).
|
||||
|
||||
### Pillow Installation ([#17133](https://github.com/qmk/qmk_firmware/pull/17133)) :id=pillow-install
|
||||
### Pillow Installation ([#17133](https://github.com/qmk/qmk_firmware/pull/17133)) {#pillow-install}
|
||||
|
||||
The merge of Quantum Painter added some new dependencies in the QMK CLI, most notably _Pillow_, which requires some installation in order for the CLI to function. If you've got an existing installation, you'll need to run some commands in order to get things working:
|
||||
|
||||
@ -62,7 +66,7 @@ On Linux or WSL:
|
||||
python3 -m pip install --user --upgrade qmk
|
||||
```
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
The following keyboards have had their source moved within QMK:
|
||||
|
||||
@ -97,7 +101,7 @@ The following keyboards have had their source moved within QMK:
|
||||
|
||||
---
|
||||
|
||||
## Full changelist :id=full-changelist
|
||||
## Full changelist {#full-changelist}
|
||||
|
||||
Core:
|
||||
* Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174))
|
||||
|
@ -1,28 +1,28 @@
|
||||
# QMK Breaking Changes - 2022 August 27 Changelog
|
||||
|
||||
## Notable Features :id=notable-features
|
||||
## Notable Features {#notable-features}
|
||||
|
||||
### Add Raspberry Pi RP2040 support ([#14877](https://github.com/qmk/qmk_firmware/pull/14877), [#17514](https://github.com/qmk/qmk_firmware/pull/17514), [#17516](https://github.com/qmk/qmk_firmware/pull/17516), [#17519](https://github.com/qmk/qmk_firmware/pull/17519), [#17612](https://github.com/qmk/qmk_firmware/pull/17612), [#17512](https://github.com/qmk/qmk_firmware/pull/17512), [#17557](https://github.com/qmk/qmk_firmware/pull/17557), [#17817](https://github.com/qmk/qmk_firmware/pull/17817), [#17839](https://github.com/qmk/qmk_firmware/pull/17839), [#18100](https://github.com/qmk/qmk_firmware/pull/18100)) :id=rp2040-support
|
||||
### Add Raspberry Pi RP2040 support ([#14877](https://github.com/qmk/qmk_firmware/pull/14877), [#17514](https://github.com/qmk/qmk_firmware/pull/17514), [#17516](https://github.com/qmk/qmk_firmware/pull/17516), [#17519](https://github.com/qmk/qmk_firmware/pull/17519), [#17612](https://github.com/qmk/qmk_firmware/pull/17612), [#17512](https://github.com/qmk/qmk_firmware/pull/17512), [#17557](https://github.com/qmk/qmk_firmware/pull/17557), [#17817](https://github.com/qmk/qmk_firmware/pull/17817), [#17839](https://github.com/qmk/qmk_firmware/pull/17839), [#18100](https://github.com/qmk/qmk_firmware/pull/18100)) {#rp2040-support}
|
||||
|
||||
QMK _finally_ picked up support for RP2040-based boards, such as the Raspberry Pi Pico, the Sparkfun Pro Micro RP2040, and the Adafruit KB2040. One of QMK's newest collaborators, _@KarlK90_, effectively did `/micdrop` with RP2040, with a massive set of changes to both QMK and the repository QMK uses for the base platform support, ChibiOS[-Contrib]. There has been a flurry of development this breaking changes cycle related to RP2040 from a large number of contributors -- so much so that almost all standard QMK hardware subsystems are supported.
|
||||
|
||||
Check the [RP2040 platform development page](platformdev_rp2040.md) for all supported peripherals and other hardware implementation details.
|
||||
Check the [RP2040 platform development page](../platformdev_rp2040) for all supported peripherals and other hardware implementation details.
|
||||
|
||||
### Allow `qmk flash` to use prebuilt firmware binaries ([#16584](https://github.com/qmk/qmk_firmware/pull/16584)) :id=cli-flash-binaries
|
||||
### Allow `qmk flash` to use prebuilt firmware binaries ([#16584](https://github.com/qmk/qmk_firmware/pull/16584)) {#cli-flash-binaries}
|
||||
|
||||
A long-requested capability of the QMK CLI has been the ability to flash binaries directly, without needing to build a firmware. QMK provides prebuilt `develop`-based default firmwares on our [CI page](https://qmk.tzarc.io/) -- normally people would need [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases/latest) to flash them. This new functionality written by _@Erovia_ allows `qmk flash` to be provided the prebuilt file instead, simplifying the workflow for people who haven't got Toolbox available.
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Default layers dropped from 32 to 16 ([#15286](https://github.com/qmk/qmk_firmware/pull/15286))
|
||||
|
||||
QMK allows for controlling the maximum number of layers it supports through `LAYER_STATE_(8|16|32)BIT`. Each definition allows for the same number of maximum layers -- `LAYER_STATE_8BIT` => 8 layers. There is also a corresponding firmware size decrease that goes along with smaller numbers -- given the vast majority of users don't use more than 16 layers the default has been swapped to 16. AVR users who were not previously specifying their max layer count may see some space freed up as a result.
|
||||
|
||||
### `RESET` => `QK_BOOT` ([#17940](https://github.com/qmk/qmk_firmware/pull/17940)) :id=reset-2-qk_boot
|
||||
### `RESET` => `QK_BOOT` ([#17940](https://github.com/qmk/qmk_firmware/pull/17940)) {#reset-2-qk_boot}
|
||||
|
||||
Following the last breaking changes cycle, QMK has been migrating usages of `RESET` to `QK_BOOT` due to naming collisions with our upstream board support packages. [#17940](https://github.com/qmk/qmk_firmware/pull/17940) converts user keymaps across to use the new keycode name. `RESET` should also move to `QK_BOOT`.
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
The following keyboards have had their source moved within QMK:
|
||||
|
||||
@ -33,7 +33,7 @@ The following keyboards have had their source moved within QMK:
|
||||
| idobao/id80/v1/ansi | idobao/id80/v2/ansi |
|
||||
| idobao/id80/v1/iso | idobao/id80/v2/iso |
|
||||
|
||||
### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) :id=usb-ids-Refactoring
|
||||
### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) {#usb-ids-Refactoring}
|
||||
|
||||
QMK has decided to deprecate the specification of USB IDs inside `config.h` in favour of `info.json`, eventually leaving data-driven as the only method to specify USB information.
|
||||
|
||||
@ -67,25 +67,25 @@ Replaced by `info.json`:
|
||||
- From 2022 Aug 27, specifying USB information in `config.h` will produce warnings during build but will still function as previously.
|
||||
- From 2022 Nov 26, specifying USB information in `config.h` will cause compilation to fail.
|
||||
|
||||
## Notable core changes :id=notable-core
|
||||
## Notable core changes {#notable-core}
|
||||
|
||||
### Board converters ([#17514](https://github.com/qmk/qmk_firmware/pull/17514), [#17603](https://github.com/qmk/qmk_firmware/pull/17603), [#17711](https://github.com/qmk/qmk_firmware/pull/17711), [#17827](https://github.com/qmk/qmk_firmware/pull/17827), [#17593](https://github.com/qmk/qmk_firmware/pull/17593), [#17652](https://github.com/qmk/qmk_firmware/pull/17652), [#17595](https://github.com/qmk/qmk_firmware/pull/17595)) :id=board-converters
|
||||
### Board converters ([#17514](https://github.com/qmk/qmk_firmware/pull/17514), [#17603](https://github.com/qmk/qmk_firmware/pull/17603), [#17711](https://github.com/qmk/qmk_firmware/pull/17711), [#17827](https://github.com/qmk/qmk_firmware/pull/17827), [#17593](https://github.com/qmk/qmk_firmware/pull/17593), [#17652](https://github.com/qmk/qmk_firmware/pull/17652), [#17595](https://github.com/qmk/qmk_firmware/pull/17595)) {#board-converters}
|
||||
|
||||
Historically QMK had a `CONVERT_TO_PROTON_C` directive for `rules.mk` to allow people to replace an AVR-based Pro Micro with a QMK Proton C. Global parts shortages have prompted people to create their own pin-compatible boards -- QMK has made this conversion generic and now allows for drop-in replacements for a lot more boards. see the [Converters Feature](feature_converters.md) documentation for the full list of supported replacement boards -- in this breaking changes cycle we've gone from 1 to 7.
|
||||
Historically QMK had a `CONVERT_TO_PROTON_C` directive for `rules.mk` to allow people to replace an AVR-based Pro Micro with a QMK Proton C. Global parts shortages have prompted people to create their own pin-compatible boards -- QMK has made this conversion generic and now allows for drop-in replacements for a lot more boards. see the [Converters Feature](../feature_converters) documentation for the full list of supported replacement boards -- in this breaking changes cycle we've gone from 1 to 7.
|
||||
|
||||
### Add cli command to import keyboard|keymap|kbfirmware ([#16668](https://github.com/qmk/qmk_firmware/pull/16668)) :id=cli-import
|
||||
### Add cli command to import keyboard|keymap|kbfirmware ([#16668](https://github.com/qmk/qmk_firmware/pull/16668)) {#cli-import}
|
||||
|
||||
To help with importing keyboards and keymaps from other sources, _@zvecr_ added [#16668](https://github.com/qmk/qmk_firmware/pull/16668) which adds a new set of commands to the CLI to automatically import keyboards (`qmk import-keyboard -h`), keymaps (`qmk import-keymap -h`), and kbfirmware definitions (`qmk import-kbfirmware -h`) into QMK.
|
||||
|
||||
The now-EOL kbfirmware allowed people who aren't set up with QMK the ability to create keyboard firmwares without requiring a full installation of QMK. Unfortunately, it targets a 7-year-old version of QMK -- adding frustration for users who want the newest features, as well as for QMK maintainers who have to spend time explaining why QMK can't just accept a drive-by code drop from kbfirmware. With any luck, this new command helps both camps!
|
||||
|
||||
### Generic wear-leveling for EEPROM emulation ([#16996](https://github.com/qmk/qmk_firmware/pull/16996), [#17376](https://github.com/qmk/qmk_firmware/pull/17376), [#18102](https://github.com/qmk/qmk_firmware/pull/18102)) :id=wear-leveling
|
||||
### Generic wear-leveling for EEPROM emulation ([#16996](https://github.com/qmk/qmk_firmware/pull/16996), [#17376](https://github.com/qmk/qmk_firmware/pull/17376), [#18102](https://github.com/qmk/qmk_firmware/pull/18102)) {#wear-leveling}
|
||||
|
||||
QMK has had the ability to write to internal MCU flash in order to emulate EEPROM for some time now, but it was only limited to a small number of MCUs. The base HAL used by QMK for a large number of ARM devices provides a "proper" embedded MCU flash driver, so _@tzarc_ decoupled the wear-leveling algorithm from the old flash writing code, improved it, wrote some tests, and enabled its use for a much larger number of other devices... including RP2040's XIP flash, and external SPI NOR Flash.
|
||||
|
||||
See the [EEPROM Driver](eeprom_driver.md) documentation for more information.
|
||||
See the [EEPROM Driver](../drivers/eeprom) documentation for more information.
|
||||
|
||||
### Pointing Device Improvements ([#16371](https://github.com/qmk/qmk_firmware/pull/16371), [#17111](https://github.com/qmk/qmk_firmware/pull/17111), [#17176](https://github.com/qmk/qmk_firmware/pull/17176), [#17482](https://github.com/qmk/qmk_firmware/pull/17482), [#17776](https://github.com/qmk/qmk_firmware/pull/17776), [#17613](https://github.com/qmk/qmk_firmware/pull/17613)) :id=pointing-device-improvements
|
||||
### Pointing Device Improvements ([#16371](https://github.com/qmk/qmk_firmware/pull/16371), [#17111](https://github.com/qmk/qmk_firmware/pull/17111), [#17176](https://github.com/qmk/qmk_firmware/pull/17176), [#17482](https://github.com/qmk/qmk_firmware/pull/17482), [#17776](https://github.com/qmk/qmk_firmware/pull/17776), [#17613](https://github.com/qmk/qmk_firmware/pull/17613)) {#pointing-device-improvements}
|
||||
|
||||
Ever since Pointing Device Driver support and Split Pointing Device support were added by _@drashna_ and _@daskygit_, there has been increased interest in the development of the pointing device subsystem and its associated code.
|
||||
|
||||
@ -102,7 +102,7 @@ Other related changes:
|
||||
|
||||
---
|
||||
|
||||
## Full changelist :id=full-changelist
|
||||
## Full changelist {#full-changelist}
|
||||
|
||||
Core:
|
||||
* Tentative Teensy 3.5 support ([#14420](https://github.com/qmk/qmk_firmware/pull/14420))
|
||||
|
@ -1,14 +1,14 @@
|
||||
# QMK Breaking Changes - 2022 November 26 Changelog
|
||||
|
||||
## Notable Features :id=notable-features
|
||||
## Notable Features {#notable-features}
|
||||
|
||||
### Autocorrect ([#15699](https://github.com/qmk/qmk_firmware/pull/15699)) :id=autocorrect
|
||||
### Autocorrect ([#15699](https://github.com/qmk/qmk_firmware/pull/15699)) {#autocorrect}
|
||||
|
||||
_@getreuer_ in their infinite wisdom decided that autocorrect was a feature needed by QMK. As is customary, _@drashna_ adapted it to core and got it into a state that everyone else can use it. See [Feature: Autocorrect](feature_autocorrect.md) for more ifnormation (grin).
|
||||
_@getreuer_ in their infinite wisdom decided that autocorrect was a feature needed by QMK. As is customary, _@drashna_ adapted it to core and got it into a state that everyone else can use it. See [Feature: Autocorrect](../features/autocorrect) for more ifnormation (grin).
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
The following keyboards have had their source moved within QMK:
|
||||
|
||||
@ -23,17 +23,19 @@ The following keyboards have had their source moved within QMK:
|
||||
| handwired/hillside/52 | hillside/52 |
|
||||
| maple_computing/christmas_tree/V2017 | maple_computing/christmas_tree/v2017 |
|
||||
|
||||
### Keycodes refactoring :id=keycodes-overhaul-user-action
|
||||
### Keycodes refactoring {#keycodes-overhaul-user-action}
|
||||
|
||||
QMK's keycodes got a very significant overhaul this breaking changes cycle, with the bulk of the work done by _@zvecr_ and _@fauxpark_ -- renaming, reordering, removing has been their focus in this area. In an attempt to standardise interoperation with host applications, keycode values now have strong versioning so that any connected application has confidence that the keys it thinks exist on the board actually match up with what's compiled in. These strongly-versioned keycode definitions are now published online and will not change, so tools that remap keycodes have a reference to work with. In future versions of QMK, any new or changed keycodes will result in a new version specification. See [API docs](api_docs.md#qmk-constants) for more information on the published versions if you're writing a tool to manage keycodes.
|
||||
QMK's keycodes got a very significant overhaul this breaking changes cycle, with the bulk of the work done by _@zvecr_ and _@fauxpark_ -- renaming, reordering, removing has been their focus in this area. In an attempt to standardise interoperation with host applications, keycode values now have strong versioning so that any connected application has confidence that the keys it thinks exist on the board actually match up with what's compiled in. These strongly-versioned keycode definitions are now published online and will not change, so tools that remap keycodes have a reference to work with. In future versions of QMK, any new or changed keycodes will result in a new version specification. See [API docs](../api_docs#qmk-constants) for more information on the published versions if you're writing a tool to manage keycodes.
|
||||
|
||||
In most cases user keymaps in the repository have already been updated to reflect the new naming scheme. In some cases user keymaps outside the repository may strike a missing keycode with the old name -- it's highly likely that the name had already been deprecated for some time, and should have been updated previously.
|
||||
|
||||
See below for the full list of changesets.
|
||||
|
||||
!> Keycode aliases have been put in place in most cases to cater for "old names" being mapped to "new names" -- the documentation already reflects all the new naming of keys.
|
||||
::: warning
|
||||
Keycode aliases have been put in place in most cases to cater for "old names" being mapped to "new names" -- the documentation already reflects all the new naming of keys.
|
||||
:::
|
||||
|
||||
### Configuration Item Refactoring :id=config-refactoring
|
||||
### Configuration Item Refactoring {#config-refactoring}
|
||||
|
||||
A number of configuration items have been renamed for consistency.
|
||||
|
||||
@ -66,7 +68,7 @@ Joystick configuration:
|
||||
| JOYSTICK_AXES_COUNT | JOYSTICK_AXIS_COUNT |
|
||||
| JOYSTICK_AXES_RESOLUTION | JOYSTICK_AXIS_RESOLUTION |
|
||||
|
||||
### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) :id=usb-ids-Refactoring
|
||||
### Data-driven USB IDs Refactoring ([#18152](https://github.com/qmk/qmk_firmware/pull/18152)) {#usb-ids-Refactoring}
|
||||
|
||||
QMK has decided to deprecate the specification of USB IDs inside `config.h` in favour of `info.json`, leaving data-driven as the only method to specify USB information. As per the deprecation schedule put forward last breaking changes cycle, USB information must be specified in `info.json` instead.
|
||||
|
||||
@ -92,7 +94,7 @@ Replaced by `info.json`:
|
||||
}
|
||||
```
|
||||
|
||||
### LED Indicator callback refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/18450)) :id=led-callback-refactor
|
||||
### LED Indicator callback refactoring ([#14864](https://github.com/qmk/qmk_firmware/pull/18450)) {#led-callback-refactor}
|
||||
|
||||
_RGB Matrix_ and _LED Matrix_ Indicator display code was traditionally difficult to override in keymaps as they did not follow the standard pattern of `bool *_kb()` deferring to `bool *_user()` functions, allowing signalling to the higher level that processing had already been done.
|
||||
|
||||
@ -128,15 +130,15 @@ bool rgb_matrix_indicators_kb(void) {
|
||||
|
||||
The equivalent transformations should be done for LED Matrix boards.
|
||||
|
||||
### Unicode mode refactoring :id=unicode-mode-renaming
|
||||
### Unicode mode refactoring {#unicode-mode-renaming}
|
||||
|
||||
Unicode modes were renamed in order to prevent collision with equivalent keycodes. The available values for `UNICODE_SELECTED_MODES` changed -- see [Feature: Unicode](feature_unicode.md#setting-the-input-mode) for the new list of values and how to configure them.
|
||||
Unicode modes were renamed in order to prevent collision with equivalent keycodes. The available values for `UNICODE_SELECTED_MODES` changed -- see [Feature: Unicode](../features/unicode#setting-the-input-mode) for the new list of values and how to configure them.
|
||||
|
||||
## Notable core changes :id=notable-core
|
||||
## Notable core changes {#notable-core}
|
||||
|
||||
This breaking changes cycle, a lot of the core changes are related to cleanup and refactoring -- commonly called "tech debt".
|
||||
|
||||
### Keycodes refactoring :id=keycodes-overhaul-core-changes
|
||||
### Keycodes refactoring {#keycodes-overhaul-core-changes}
|
||||
|
||||
We aren't going to list each and every change -- they're far too numerous -- instead, we'll just list the related PRs in order to convey just how wide-reaching these changes were:
|
||||
|
||||
@ -181,7 +183,7 @@ We aren't going to list each and every change -- they're far too numerous -- ins
|
||||
* Remove legacy sendstring keycodes ([#18749](https://github.com/qmk/qmk_firmware/pull/18749))
|
||||
* Reworked backlight keycodes. ([#18961](https://github.com/qmk/qmk_firmware/pull/18961))
|
||||
|
||||
### Board Converters :id=board-converters
|
||||
### Board Converters {#board-converters}
|
||||
|
||||
There was additional work in the space of board converters -- historically QMK allowed for "converting" a Pro Micro build to a QMK Proton-C build. The last few versions of QMK have added support for replacement boards much like the Proton-C, and this quarter was no exception:
|
||||
|
||||
@ -191,9 +193,9 @@ There was additional work in the space of board converters -- historically QMK a
|
||||
* Add Elite-Pi converter ([#18236](https://github.com/qmk/qmk_firmware/pull/18236))
|
||||
* Allow QK_MAKE to work with converters ([#18637](https://github.com/qmk/qmk_firmware/pull/18637))
|
||||
|
||||
See [Feature: Converters](feature_converters.md) for the full list of board conversions available.
|
||||
See [Feature: Converters](../feature_converters) for the full list of board conversions available.
|
||||
|
||||
### Pointing and Digitizer device updates :id=pointing-and-digitizer
|
||||
### Pointing and Digitizer device updates {#pointing-and-digitizer}
|
||||
|
||||
Both pointing devices and digitizer got a host of updates this cycle. Inertia, automatic mouse layers, fixes for preventing sleep... you even get more buttons with digitizers!
|
||||
|
||||
@ -207,7 +209,7 @@ Both pointing devices and digitizer got a host of updates this cycle. Inertia, a
|
||||
* Invert pointing device motion pin for cirque touchpads ([#18404](https://github.com/qmk/qmk_firmware/pull/18404))
|
||||
* Refactor more host code (programmable button & digitizer) ([#18565](https://github.com/qmk/qmk_firmware/pull/18565))
|
||||
|
||||
## Full changelist :id=full-changelist
|
||||
## Full changelist {#full-changelist}
|
||||
|
||||
Core:
|
||||
* quantum: led: split out led_update_ports() for customization of led behaviour ([#14452](https://github.com/qmk/qmk_firmware/pull/14452))
|
||||
|
@ -1,8 +1,8 @@
|
||||
# QMK Breaking Changes - 2023 February 26 Changelog
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### `IGNORE_MOD_TAP_INTERRUPT` behaviour changes ([#15741](https://github.com/qmk/qmk_firmware/pull/15741)) :id=i-m-t-i
|
||||
### `IGNORE_MOD_TAP_INTERRUPT` behaviour changes ([#15741](https://github.com/qmk/qmk_firmware/pull/15741)) {#i-m-t-i}
|
||||
|
||||
`IGNORE_MOD_TAP_INTERRUPT_PER_KEY` has been removed and `IGNORE_MOD_TAP_INTERRUPT` deprecated as a stepping stone towards making `IGNORE_MOD_TAP_INTERRUPT` the new default behavior for mod-taps in the future.
|
||||
|
||||
@ -46,9 +46,9 @@ bool get_hold_on_other_key_press(uint16_t keycode, keyrecord_t *record) {
|
||||
}
|
||||
```
|
||||
|
||||
For more information, you are invited to read the sections on [IGNORE_MOD_TAP_INTERRUPT](tap_hold.md#ignore-mod-tap-interrupt) and [HOLD_ON_OTHER_KEY_PRESS](tap_hold.md#hold-on-other-key-press) in the page on [Tap-Hold configuration options](tap_hold.md).
|
||||
For more information, you are invited to read the sections on [IGNORE_MOD_TAP_INTERRUPT](../tap_hold#ignore-mod-tap-interrupt) and [HOLD_ON_OTHER_KEY_PRESS](../tap_hold#hold-on-other-key-press) in the page on [Tap-Hold configuration options](../tap_hold).
|
||||
|
||||
### `TAPPING_FORCE_HOLD` => `QUICK_TAP_TERM` ([#17007](https://github.com/qmk/qmk_firmware/pull/17007)) :id=quick-tap-term
|
||||
### `TAPPING_FORCE_HOLD` => `QUICK_TAP_TERM` ([#17007](https://github.com/qmk/qmk_firmware/pull/17007)) {#quick-tap-term}
|
||||
|
||||
`TAPPING_FORCE_HOLD` feature is now replaced by `QUICK_TAP_TERM`. Instead of turning off auto-repeat completely, user will have the option to configure a `QUICK_TAP_TERM` in milliseconds. When the user holds a tap-hold key after tapping it within `QUICK_TAP_TERM`, QMK will send the tap keycode to the host, enabling auto-repeat.
|
||||
|
||||
@ -80,9 +80,9 @@ uint16_t get_quick_tap_term(uint16_t keycode, keyrecord_t *record) {
|
||||
}
|
||||
```
|
||||
|
||||
For more details, please read the updated documentation section on [Quick Tap Term](tap_hold.md#quick-tap-term).
|
||||
For more details, please read the updated documentation section on [Quick Tap Term](../tap_hold#quick-tap-term).
|
||||
|
||||
### Leader Key Rework :id=leader-key-rework ([#19632](https://github.com/qmk/qmk_firmware/pull/19632))
|
||||
### Leader Key Rework {#leader-key-rework ([#19632](https://github.com/qmk/qmk_firmware/pull/19632))}
|
||||
|
||||
The Leader Key feature API has been significantly improved, along with some bugfixes and added tests.
|
||||
|
||||
@ -106,9 +106,9 @@ void leader_end_user(void) {
|
||||
}
|
||||
```
|
||||
|
||||
For more information please see the [Leader Key documentation](feature_leader_key.md).
|
||||
For more information please see the [Leader Key documentation](../features/leader_key).
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
The following keyboards have had their source moved within QMK:
|
||||
|
||||
@ -130,7 +130,7 @@ The following keyboards have had their source moved within QMK:
|
||||
| the_uni | stenothe_uni |
|
||||
| xelus/xs60 | xelus/xs60/soldered |
|
||||
|
||||
## Notable core changes :id=notable-core
|
||||
## Notable core changes {#notable-core}
|
||||
|
||||
As per last breaking changes cycle, there has been _a lot_ of emphasis on behind-the-scenes changes, mainly around consolidation of core subsystems and constant values, as well as addressing tech debt. Whilst not outwardly visible, this cleanup and refactoring should start paying dividends as it simplifies future development and maintenance.
|
||||
|
||||
@ -142,7 +142,7 @@ A handful of examples:
|
||||
* Many more configuration options have moved into `info.json`, such as backlight, encoders
|
||||
* Additional unit tests to ensure keycode behaviours don't accidentally change
|
||||
|
||||
## Full changelist :id=full-changelist
|
||||
## Full changelist {#full-changelist}
|
||||
|
||||
Core:
|
||||
* Remove IGNORE_MOD_TAP_INTERRUPT_PER_KEY in favour of HOLD_ON_OTHER_KEY_PRESS_PER_KEY ([#15741](https://github.com/qmk/qmk_firmware/pull/15741))
|
||||
|
@ -1,6 +1,6 @@
|
||||
# QMK Breaking Changes - 2023 May 28 Changelog
|
||||
|
||||
## Notable Changes :id=notable-changes
|
||||
## Notable Changes {#notable-changes}
|
||||
|
||||
As per last breaking changes cycle, there has been _a lot_ of emphasis on behind-the-scenes changes, mainly around migration of configurables into `info.json` files, cleanup of `info.json` files, additional layout definitions for keyboards, adding support for general community layouts to keyboards, as well as addressing technical debt.
|
||||
|
||||
@ -20,11 +20,11 @@ Of note for keyboard designers:
|
||||
* `encoder_map[][NUM_ENCODERS][2]` => `encoder_map[][NUM_ENCODERS][NUM_DIRECTIONS]`
|
||||
* Users assumed the `2` referred to the number of encoders, rather than the number of directions (which is always 2)
|
||||
|
||||
### Repeat last key ([#19700](https://github.com/qmk/qmk_firmware/pull/19700)) :id=repeat-last-key
|
||||
### Repeat last key ([#19700](https://github.com/qmk/qmk_firmware/pull/19700)) {#repeat-last-key}
|
||||
|
||||
A new pair of keys has been added to QMK -- namely `QK_REPEAT_KEY` and `QK_ALT_REPEAT_KEY` (shortened: `QK_REP`/`QK_AREP`). These allow you to repeat the last key pressed, or in the case of the alternate key, press the "opposite" of the last key. For example, if you press `KC_LEFT`, pressing `QK_REPEAT_KEY` afterwards repeats `KC_LEFT`, but pressing `QK_ALT_REPEAT_KEY` instead sends `KC_RIGHT`.
|
||||
|
||||
The full list of default alternate keys is available on the [Repeat Key](feature_repeat_key.md) documentation.
|
||||
The full list of default alternate keys is available on the [Repeat Key](../features/repeat_key) documentation.
|
||||
|
||||
To enable these keys, in your keymap's `rules.mk`, add:
|
||||
|
||||
@ -34,27 +34,27 @@ REPEAT_KEY_ENABLE = yes
|
||||
|
||||
...and add them to your keymap.
|
||||
|
||||
### User callback for pre process record ([#20584](https://github.com/qmk/qmk_firmware/pull/20584)) :id=user-callback-for-pre-process-record
|
||||
### User callback for pre process record ([#20584](https://github.com/qmk/qmk_firmware/pull/20584)) {#user-callback-for-pre-process-record}
|
||||
|
||||
Two new boolean callback functions, `pre_process_record_kb` and `pre_process_record_user`, have been added. They are called at the beginning of `process_record`, right before `process_combo`.
|
||||
|
||||
Similar to existing `*_kb` and `*_user` callback functions, returning `false` will halt further processing of key events. The `pre_process_record_user` function will allow user space opportunity to handle or capture an input before it undergoes quantum processing. For example, while action tapping is still resolving the tap or hold output of a mod-tap key, `pre_process_record_user` can capture the next key record of an input event that follows. That key record can be used to influence the [decision of the mod-tap](https://docs.qmk.fm/#/tap_hold) key that is currently undergoing quantum processing.
|
||||
Similar to existing `*_kb` and `*_user` callback functions, returning `false` will halt further processing of key events. The `pre_process_record_user` function will allow user space opportunity to handle or capture an input before it undergoes quantum processing. For example, while action tapping is still resolving the tap or hold output of a mod-tap key, `pre_process_record_user` can capture the next key record of an input event that follows. That key record can be used to influence the [decision of the mod-tap](../tap_hold) key that is currently undergoing quantum processing.
|
||||
|
||||
### Consolidate modelm ([#14996](https://github.com/qmk/qmk_firmware/pull/14996) :id=consolidate-modelm
|
||||
### Consolidate modelm ([#14996](https://github.com/qmk/qmk_firmware/pull/14996) {#consolidate-modelm}
|
||||
|
||||
Several build targets for the IBM Model M were cluttered in different folders. The maintainers of several Model M replacement controller projects agreed to consolidate them under one common folder.
|
||||
|
||||
The list of all moved keyboard locations is listed [below](20230528.md#updated-keyboard-codebases).
|
||||
The list of all moved keyboard locations is listed [below](20230528#updated-keyboard-codebases).
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### `IGNORE_MOD_TAP_INTERRUPT` behaviour changes ([#20211](https://github.com/qmk/qmk_firmware/pull/20211)) :id=i-m-t-i
|
||||
### `IGNORE_MOD_TAP_INTERRUPT` behaviour changes ([#20211](https://github.com/qmk/qmk_firmware/pull/20211)) {#i-m-t-i}
|
||||
|
||||
Following up from the last breaking changes cycle, `IGNORE_MOD_TAP_INTERRUPT` has been removed and if present in keymap code, will now fail to build. The previous functionality for `IGNORE_MOD_TAP_INTERRUPT` is now default, and should you wish to revert to the old behaviour, you can use `HOLD_ON_OTHER_KEY_PRESS` instead.
|
||||
|
||||
For more information, you are invited to read the section on [HOLD_ON_OTHER_KEY_PRESS](tap_hold.md#hold-on-other-key-press) in the page on [Tap-Hold configuration options](tap_hold.md).
|
||||
For more information, you are invited to read the section on [HOLD_ON_OTHER_KEY_PRESS](../tap_hold#hold-on-other-key-press) in the page on [Tap-Hold configuration options](../tap_hold).
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
| Old Keyboard Name | New Keyboard Name |
|
||||
|---------------------------------|-------------------------------------|
|
||||
@ -77,9 +77,9 @@ For more information, you are invited to read the section on [HOLD_ON_OTHER_KEY_
|
||||
| tronguylabs/m122_3270/teensy | ibm/model_m_122/m122_3270/teensy |
|
||||
| yugo_m/model_m_101 | ibm/model_m/yugo_m |
|
||||
|
||||
## Notable core changes :id=notable-core
|
||||
## Notable core changes {#notable-core}
|
||||
|
||||
### Encoder functionality fallback ([#20320](https://github.com/qmk/qmk_firmware/pull/20320)) :id=encoder-functionality-fallback
|
||||
### Encoder functionality fallback ([#20320](https://github.com/qmk/qmk_firmware/pull/20320)) {#encoder-functionality-fallback}
|
||||
|
||||
For keyboards who have not yet been migrated to encoder map, a default set of encoder functionality is now enabled, gracefully degrading functionality depending on which flags are enabled by the keyboard:
|
||||
|
||||
@ -89,13 +89,13 @@ For keyboards who have not yet been migrated to encoder map, a default set of en
|
||||
|
||||
Additionally, this ensures that builds on QMK Configurator produce some sort of usable encoder mapping.
|
||||
|
||||
### OLED Driver Improvements ([#20331](https://github.com/qmk/qmk_firmware/pull/20331)) :id=oled-driver-improvements
|
||||
### OLED Driver Improvements ([#20331](https://github.com/qmk/qmk_firmware/pull/20331)) {#oled-driver-improvements}
|
||||
|
||||
The "classic" OLED driver picked up support for additional sizes of OLED displays, support for the SH1107 controller, and SPI-based OLED support.
|
||||
|
||||
Other configurable items are available and can be found on the [OLED Driver page](https://docs.qmk.fm/#/feature_oled_driver).
|
||||
Other configurable items are available and can be found on the [OLED Driver page](../features/oled_driver).
|
||||
|
||||
## Full changelist :id=full-changelist
|
||||
## Full changelist {#full-changelist}
|
||||
|
||||
Core:
|
||||
* Refactor `keyevent_t` for 1ms timing resolution ([#15847](https://github.com/qmk/qmk_firmware/pull/15847))
|
||||
|
@ -1,14 +1,14 @@
|
||||
# QMK Breaking Changes - 2023 Aug 27 Changelog
|
||||
|
||||
## Notable Changes :id=notable-changes
|
||||
## Notable Changes {#notable-changes}
|
||||
|
||||
As per last few breaking changes cycles, there have been _a lot_ of behind-the-scenes changes, mainly around migration of configurables into `info.json` files, cleanup of `info.json` files, additional layout definitions for keyboards, adding support for general community layouts to keyboards, as well as addressing technical debt.
|
||||
|
||||
One thing to note for this release -- `qmk/qmk_firmware` is no longer accepting PRs for keymaps other than for manufacturer-supported keymaps. User keymap workflow has been documented [here](https://docs.qmk.fm/#/newbs) for several years. This change is to progressively reduce the maintenance burden on the project, and to allow us to focus on the core features of QMK.
|
||||
One thing to note for this release -- `qmk/qmk_firmware` is no longer accepting PRs for keymaps other than for manufacturer-supported keymaps. User keymap workflow has been documented [here](../newbs) for several years. This change is to progressively reduce the maintenance burden on the project, and to allow us to focus on the core features of QMK.
|
||||
|
||||
Existing user keymaps and userspace areas will likely be relocated/removed in the future -- non-building keymaps and userspace will be first targets, likely during the new breaking changes cycle. We will provide more information on Discord regarding this initiative as it becomes available.
|
||||
|
||||
### RGB Matrix optimizations ([#21134](https://github.com/qmk/qmk_firmware/pull/21134), [#21135](https://github.com/qmk/qmk_firmware/pull/21135)) :id=rgb-matrix-optimizations
|
||||
### RGB Matrix optimizations ([#21134](https://github.com/qmk/qmk_firmware/pull/21134), [#21135](https://github.com/qmk/qmk_firmware/pull/21135)) {#rgb-matrix-optimizations}
|
||||
|
||||
Most RGB Matrix implementations now check whether or not RGB LED data has changed and skip transmission if it hasn't. This was measured to improve scan frequency in cases of static or infrequently-changing colors.
|
||||
|
||||
@ -18,9 +18,9 @@ Some audio code relating to "notes" used `double` datatypes, which are implement
|
||||
|
||||
AVR sees minimal (if any) benefit -- `double` was interpreted as `float` on AVR anyway.
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
| Old Keyboard Name | New Keyboard Name |
|
||||
|---------------------------------------|-------------------------------------|
|
||||
@ -40,11 +40,11 @@ AVR sees minimal (if any) benefit -- `double` was interpreted as `float` on AVR
|
||||
| modelh | ibm/model_m/modelh |
|
||||
| vinta | coarse/vinta |
|
||||
|
||||
### Remove encoder in-matrix workaround code ([#20389](https://github.com/qmk/qmk_firmware/pull/20389)) :id=remove-encoder-in-matrix-workaround-code
|
||||
### Remove encoder in-matrix workaround code ([#20389](https://github.com/qmk/qmk_firmware/pull/20389)) {#remove-encoder-in-matrix-workaround-code}
|
||||
|
||||
Some keyboards "hacked" encoder support into spare slots in the key matrix in order to interoperate with VIA. This workaround is no longer necessary, and the code has been removed. If you have a keyboard that uses this workaround, you will need to update your keymap to use the new [Encoder Map](feature_encoders.md#encoder-map) API instead.
|
||||
Some keyboards "hacked" encoder support into spare slots in the key matrix in order to interoperate with VIA. This workaround is no longer necessary, and the code has been removed. If you have a keyboard that uses this workaround, you will need to update your keymap to use the new [Encoder Map](../features/encoders#encoder-map) API instead.
|
||||
|
||||
### Unicodemap keycodes rename ([#21092](https://github.com/qmk/qmk_firmware/pull/21092)) :id=unicodemap-keycodes-rename
|
||||
### Unicodemap keycodes rename ([#21092](https://github.com/qmk/qmk_firmware/pull/21092)) {#unicodemap-keycodes-rename}
|
||||
|
||||
The Unicodemap keycodes have been renamed:
|
||||
|
||||
@ -53,11 +53,11 @@ The Unicodemap keycodes have been renamed:
|
||||
| `X(i)` | `UM(i)` |
|
||||
| `XP(i,j)` | `UP(i,j)` |
|
||||
|
||||
### Remove old OLED API code ([#21651](https://github.com/qmk/qmk_firmware/pull/21651)) :id=remove-old-oled-api-code
|
||||
### Remove old OLED API code ([#21651](https://github.com/qmk/qmk_firmware/pull/21651)) {#remove-old-oled-api-code}
|
||||
|
||||
Old OLED code using `ssd1306.c` `ssd1306.h`, and `SSD1306OLED` and other similar files have been consolidated to use the standard OLED driver. External user keymaps will need to be updated to use the standard OLED driver accordingly.
|
||||
|
||||
### Driver naming consolidation ([#21551](https://github.com/qmk/qmk_firmware/pull/21551), [#21558](https://github.com/qmk/qmk_firmware/pull/21558), [#21580](https://github.com/qmk/qmk_firmware/pull/21580), [#21594](https://github.com/qmk/qmk_firmware/pull/21594), [#21624](https://github.com/qmk/qmk_firmware/pull/21624), [#21710](https://github.com/qmk/qmk_firmware/pull/21710)) :id=driver-naming-consolidation
|
||||
### Driver naming consolidation ([#21551](https://github.com/qmk/qmk_firmware/pull/21551), [#21558](https://github.com/qmk/qmk_firmware/pull/21558), [#21580](https://github.com/qmk/qmk_firmware/pull/21580), [#21594](https://github.com/qmk/qmk_firmware/pull/21594), [#21624](https://github.com/qmk/qmk_firmware/pull/21624), [#21710](https://github.com/qmk/qmk_firmware/pull/21710)) {#driver-naming-consolidation}
|
||||
|
||||
In most circumstances this won't affect users -- only keyboard designers with currently-unmerged boards. The only users affected are people who have modified existing keyboards in order to add/modify haptics, lighting, or bluetooth -- and only if the base keyboard did not configure them already. Driver naming has been modified to be lowercase.
|
||||
|
||||
@ -116,7 +116,7 @@ Bluetooth (`BLUETOOTH_DRIVER` / `bluetooth.driver`):
|
||||
| `BluefruitLE` | `bluefruit_le` |
|
||||
| `RN42` | `rn42` |
|
||||
|
||||
## Full changelist :id=full-changelist
|
||||
## Full changelist {#full-changelist}
|
||||
|
||||
Core:
|
||||
* On-each-release tap dance function ([#20255](https://github.com/qmk/qmk_firmware/pull/20255))
|
||||
|
@ -1,14 +1,14 @@
|
||||
# QMK Breaking Changes - 2023 November 26 Changelog
|
||||
|
||||
## Notable Features :id=notable-features
|
||||
## Notable Features {#notable-features}
|
||||
|
||||
As per last few breaking changes cycles, there have been _a lot_ of behind-the-scenes changes, mainly around consolidation of config into `info.json` files, cleanup of `info.json` files, cleaning up driver naming, as well as addressing technical debt.
|
||||
|
||||
As a followup to last cycle's [notable changes](20230827.md#notable-changes), as `qmk/qmk_firmware` is no longer accepting PRs for keymaps we're pleased to announce that storing and building keymaps externally from the normal QMK Firmware repository is now possible. This is done through the new [External Userspace](newbs_external_userspace.md) feature, more details below!
|
||||
As a followup to last cycle's [notable changes](20230827#notable-changes), as `qmk/qmk_firmware` is no longer accepting PRs for keymaps we're pleased to announce that storing and building keymaps externally from the normal QMK Firmware repository is now possible. This is done through the new [External Userspace](../newbs_external_userspace) feature, more details below!
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
| Old Keyboard Name | New Keyboard Name |
|
||||
|---------------------------------------|-------------------------------|
|
||||
@ -29,29 +29,31 @@ As a followup to last cycle's [notable changes](20230827.md#notable-changes), as
|
||||
| studiokestra/line_tkl | studiokestra/line_friends_tkl |
|
||||
| ymdk/melody96 | ymdk/melody96/soldered |
|
||||
|
||||
## Notable core changes :id=notable-core
|
||||
## Notable core changes {#notable-core}
|
||||
|
||||
### External Userspace ([#22222](https://github.com/qmk/qmk_firmware/pull/22222))
|
||||
|
||||
As mentioned above, the new External Userspace feature allows for keymaps to be stored and built externally from the main QMK Firmware repository. This allows for keymaps to be stored separately -- usually in their own repository -- and for users to be able to maintain and build their keymaps without needing to fork the main QMK Firmware repository.
|
||||
|
||||
See the [External Userspace documentation](newbs_external_userspace.md) for more details.
|
||||
See the [External Userspace documentation](../newbs_external_userspace) for more details.
|
||||
|
||||
A significant portion of user keymaps have already been removed from `qmk/qmk_firmware` and more will follow in coming weeks. You can still recover your keymap from the tag [user-keymaps-still-present](https://github.com/qmk/qmk_firmware/tree/user-keymaps-still-present) if required -- a perfect time to migrate to the new External Userspace!
|
||||
|
||||
!> This feature is still in beta, and we're looking for feedback on it. Please try it out and let us know what you think -- a new `#help-userspace` channel has been set up on Discord.
|
||||
::: warning
|
||||
This feature is still in beta, and we're looking for feedback on it. Please try it out and let us know what you think -- a new `#help-userspace` channel has been set up on Discord.
|
||||
:::
|
||||
|
||||
### Improve and Cleanup Shutdown callbacks ([#21060](https://github.com/qmk/qmk_firmware/pull/20160)) :id=improve-and-cleanup-shutdown-callbacks
|
||||
### Improve and Cleanup Shutdown callbacks ([#21060](https://github.com/qmk/qmk_firmware/pull/20160)) {#improve-and-cleanup-shutdown-callbacks}
|
||||
|
||||
Shutdown callbacks at the keyboard level were never present, preventing safe shutdown sequencing for peripherals such as OLEDs, RGB LEDs, and other devices. This PR adds a new `shutdown_kb` function, as well as amending `shutdown_user`, allowing for safe shutdown of peripherals at both keyboard and keymap level.
|
||||
|
||||
See the [Keyboard Shutdown/Reboot Code](custom_quantum_functions.md#keyboard-shutdown-reboot-code) documentation for more details.
|
||||
See the [Keyboard Shutdown/Reboot Code](../custom_quantum_functions#keyboard-shutdown-reboot-code) documentation for more details.
|
||||
|
||||
### OLED Force Flush ([#20953](https://github.com/qmk/qmk_firmware/pull/20953)) :id=oled-force-flush
|
||||
### OLED Force Flush ([#20953](https://github.com/qmk/qmk_firmware/pull/20953)) {#oled-force-flush}
|
||||
|
||||
Along with the new `shutdown_kb` function, a new API `oled_render_dirty(bool)` function has been added. This allows OLED contents to be written deterministically when supplied with `true` -- that is, the OLED will be updated immediately, rather than waiting for the next OLED update cycle. This allows for OLEDs to show things such as "BOOTLOADER MODE" and the like if resetting to bootloader from QMK.
|
||||
|
||||
### Switch statement helpers for keycode ranges ([#20059](https://github.com/qmk/qmk_firmware/pull/20059)) :id=switch-statement-helpers-for-keycode-ranges
|
||||
### Switch statement helpers for keycode ranges ([#20059](https://github.com/qmk/qmk_firmware/pull/20059)) {#switch-statement-helpers-for-keycode-ranges}
|
||||
|
||||
Predefined ranges usable within switch statements have been added for groups of similar keycodes, where people who wish to handle entire blocks at once can do so. This allows keymaps to be immune to changes in keycode values, and also allows for more efficient code generation.
|
||||
|
||||
@ -98,17 +100,17 @@ Becomes:
|
||||
/* do stuff with basic and modifier keycodes */
|
||||
```
|
||||
|
||||
### Quantum Painter OLED support ([#19997](https://github.com/qmk/qmk_firmware/pull/19997)) :id=quantum-painter-oled-support
|
||||
### Quantum Painter OLED support ([#19997](https://github.com/qmk/qmk_firmware/pull/19997)) {#quantum-painter-oled-support}
|
||||
|
||||
Quantum Painter has picked up support for SH1106 displays -- commonly seen as 128x64 OLEDs. Support for both I2C and SPI displays is available.
|
||||
|
||||
If you're already using OLED through `OLED_DRIVER_ENABLE = yes` or equivalent in `info.json` and wish to use Quantum Painter instead, you'll need to disable the old OLED system, instead enabling Quantum Painter as well as enabling the appropriate SH1106 driver. See the [Quantum Painter driver documentation](quantum_painter.md#quantum-painter-drivers) for more details. The old OLED driver is still available, and keymaps do not require migrating to Quantum Painter if you don't want to do so.
|
||||
If you're already using OLED through `OLED_DRIVER_ENABLE = yes` or equivalent in `info.json` and wish to use Quantum Painter instead, you'll need to disable the old OLED system, instead enabling Quantum Painter as well as enabling the appropriate SH1106 driver. See the [Quantum Painter driver documentation](../quantum_painter#quantum-painter-drivers) for more details. The old OLED driver is still available, and keymaps do not require migrating to Quantum Painter if you don't want to do so.
|
||||
|
||||
### RGB/LED lighting driver naming and cleanup ([#21890](https://github.com/qmk/qmk_firmware/pull/21890), [#21891](https://github.com/qmk/qmk_firmware/pull/21891), [#21892](https://github.com/qmk/qmk_firmware/pull/21892), [#21903](https://github.com/qmk/qmk_firmware/pull/21903), [#21904](https://github.com/qmk/qmk_firmware/pull/21904), [#21905](https://github.com/qmk/qmk_firmware/pull/21905), [#21918](https://github.com/qmk/qmk_firmware/pull/21918), [#21929](https://github.com/qmk/qmk_firmware/pull/21929), [#21938](https://github.com/qmk/qmk_firmware/pull/21938), [#22004](https://github.com/qmk/qmk_firmware/pull/22004), [#22008](https://github.com/qmk/qmk_firmware/pull/22008), [#22009](https://github.com/qmk/qmk_firmware/pull/22009), [#22071](https://github.com/qmk/qmk_firmware/pull/22071), [#22090](https://github.com/qmk/qmk_firmware/pull/22090), [#22099](https://github.com/qmk/qmk_firmware/pull/22099), [#22126](https://github.com/qmk/qmk_firmware/pull/22126), [#22133](https://github.com/qmk/qmk_firmware/pull/22133), [#22163](https://github.com/qmk/qmk_firmware/pull/22163), [#22200](https://github.com/qmk/qmk_firmware/pull/22200), [#22308](https://github.com/qmk/qmk_firmware/pull/22308), [#22309](https://github.com/qmk/qmk_firmware/pull/22309), [#22311](https://github.com/qmk/qmk_firmware/pull/22311), [#22325](https://github.com/qmk/qmk_firmware/pull/22325), [#22365](https://github.com/qmk/qmk_firmware/pull/22365), [#22379](https://github.com/qmk/qmk_firmware/pull/22379), [#22380](https://github.com/qmk/qmk_firmware/pull/22380), [#22381](https://github.com/qmk/qmk_firmware/pull/22381), [#22383](https://github.com/qmk/qmk_firmware/pull/22383), [#22436](https://github.com/qmk/qmk_firmware/pull/22436))
|
||||
|
||||
As you can probably tell by the list of PRs just above, there has been a lot of cleanup and consolidation this cycle when it comes to RGB/LED lighting drivers. The number of changes is too large to list here, but the general theme has been focusing on consistency of naming, both of drivers themselves and their respective implementation and configuration. Most changes only affect keyboard designers -- if you find that your in-development keyboard is no longer building due to naming of defines changing, your best bet is to refer to another board already in the repository which has had the changes applied.
|
||||
|
||||
### Peripheral subsystem enabling ([#22253](https://github.com/qmk/qmk_firmware/pull/22253), [#22448](https://github.com/qmk/qmk_firmware/pull/22448), [#22106](https://github.com/qmk/qmk_firmware/pull/22106)) :id=peripheral-subsystem-enabling
|
||||
### Peripheral subsystem enabling ([#22253](https://github.com/qmk/qmk_firmware/pull/22253), [#22448](https://github.com/qmk/qmk_firmware/pull/22448), [#22106](https://github.com/qmk/qmk_firmware/pull/22106)) {#peripheral-subsystem-enabling}
|
||||
|
||||
When enabling peripherals such as I2C, SPI, or Analog/ADC, some required manual inclusion of source files in order to provide driver support, and in some cases, when multiple drivers were using the same underlying peripheral, files were being added to the build multiple times.
|
||||
|
||||
@ -125,11 +127,11 @@ For a concrete example, users or keyboard designers who previously added `SRC +=
|
||||
| `UART_DRIVER_REQUIRED = yes` | `SRC += uart.c` |
|
||||
| `WS2812_DRIVER_REQUIRED = yes` | `SRC += ws2812.c` |
|
||||
|
||||
### NKRO on V-USB boards ([#22398](https://github.com/qmk/qmk_firmware/pull/22398)) :id=vusb-nkro
|
||||
### NKRO on V-USB boards ([#22398](https://github.com/qmk/qmk_firmware/pull/22398)) {#vusb-nkro}
|
||||
|
||||
NKRO is now available for ATmega32A and 328P-based keyboards (including PS2AVRGB/Bootmapper boards), thanks to some internal refactoring and cleanup. To enable it, the process is the same as always - add `NKRO_ENABLE = yes` to your `rules.mk`, then assign and press the `NK_TOGG` keycode to switch modes.
|
||||
|
||||
## Full changelist :id=full-changelist
|
||||
## Full changelist {#full-changelist}
|
||||
|
||||
Core:
|
||||
* Compilation warning if both `keymap.json` and `keymap.c` exist ([#19939](https://github.com/qmk/qmk_firmware/pull/19939))
|
||||
|
@ -1,6 +1,6 @@
|
||||
# QMK Breaking Changes - 2024 February 25 Changelog
|
||||
|
||||
## Notable Features :id=notable-features
|
||||
## Notable Features {#notable-features}
|
||||
|
||||
_0.24.0_ is mainly a maintenance release of QMK Firmware -- as per last few breaking changes cycles, there have been a lot of behind-the-scenes changes, mainly:
|
||||
|
||||
@ -10,17 +10,17 @@ _0.24.0_ is mainly a maintenance release of QMK Firmware -- as per last few brea
|
||||
* keyboard relocations
|
||||
* addressing technical debt
|
||||
|
||||
## Changes Requiring User Action :id=changes-requiring-user-action
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Windows Driver Changes ([QMK Toolbox 0.3.0 Release](https://github.com/qmk/qmk_toolbox/releases/tag/0.3.0))
|
||||
|
||||
Flashing keyboards that target `atmel-dfu` or `qmk-dfu` on Windows using `qmk flash` or QMK Toolbox have traditionally used _libusb_ for access to the DFU USB device. Since QMK Toolbox 0.3.0, this has changed to WinUSB.
|
||||
|
||||
If you update QMK Toolbox or update QMK MSYS, you may find that flashing Atmel DFU keyboards no longer functions as intended. If you strike such issues when flashing new firmware, you will need to replace the _libusb_ driver with _WinUSB_ using Zadig. You can follow the [Recovering from Installation to Wrong Device](driver_installation_zadig.md#recovering-from-installation-to-wrong-device) instructions to replace the driver associated with the Atmel DFU bootloader, skipping the section about removal as Zadig will safely replace the driver instead. Please ensure your keyboard is in bootloader mode and has _libusb_ as the existing driver before attempting to use Zadig to replace the driver. If instead you see _HidUsb_ you're not in bootloader mode and should not continue with driver replacement.
|
||||
If you update QMK Toolbox or update QMK MSYS, you may find that flashing Atmel DFU keyboards no longer functions as intended. If you strike such issues when flashing new firmware, you will need to replace the _libusb_ driver with _WinUSB_ using Zadig. You can follow the [Recovering from Installation to Wrong Device](../driver_installation_zadig#recovering-from-installation-to-wrong-device) instructions to replace the driver associated with the Atmel DFU bootloader, skipping the section about removal as Zadig will safely replace the driver instead. Please ensure your keyboard is in bootloader mode and has _libusb_ as the existing driver before attempting to use Zadig to replace the driver. If instead you see _HidUsb_ you're not in bootloader mode and should not continue with driver replacement.
|
||||
|
||||
### Updated Keyboard Codebases :id=updated-keyboard-codebases
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
One note with updated keyboard names -- historical keyboard names are still considered valid when using [External Userspace](newbs_external_userspace.md) for builds. If you're already using External Userspace, you do not need to move your keymap inside your repository.
|
||||
One note with updated keyboard names -- historical keyboard names are still considered valid when using [External Userspace](../newbs_external_userspace) for builds. If you're already using External Userspace, you do not need to move your keymap inside your repository.
|
||||
|
||||
| Old Keyboard Name | New Keyboard Name |
|
||||
|-------------------------|---------------------------------|
|
||||
@ -77,9 +77,9 @@ One note with updated keyboard names -- historical keyboard names are still cons
|
||||
| z12 | zigotica/z12 |
|
||||
| z34 | zigotica/z34 |
|
||||
|
||||
## Notable core changes :id=notable-core
|
||||
## Notable core changes {#notable-core}
|
||||
|
||||
### Renaming Arduino-style GPIO pin functions ([#23085](https://github.com/qmk/qmk_firmware/pull/23085), [#23093](https://github.com/qmk/qmk_firmware/pull/23093)) :id=gpio-rename
|
||||
### Renaming Arduino-style GPIO pin functions ([#23085](https://github.com/qmk/qmk_firmware/pull/23085), [#23093](https://github.com/qmk/qmk_firmware/pull/23093)) {#gpio-rename}
|
||||
|
||||
QMK has long used Arduino-style GPIO naming conventions. This has been confusing for users, as over time they've had new variations added, as well as users mistakenly thinking that QMK supports the rest of the Arduino ecosystem.
|
||||
|
||||
@ -110,17 +110,17 @@ Much like the GPIO refactoring, I2C APIs were also updated to conform to QMK nam
|
||||
| `i2c_writeReg()` | `i2c_write_register()` |
|
||||
| `i2c_writeReg16()` | `i2c_write_register16()` |
|
||||
|
||||
### Renaming _Bootmagic Lite_ => _Bootmagic_ ([#22970](https://github.com/qmk/qmk_firmware/pull/22970), [#22979](https://github.com/qmk/qmk_firmware/pull/22979)) :id=bootmagic-rename
|
||||
### Renaming _Bootmagic Lite_ => _Bootmagic_ ([#22970](https://github.com/qmk/qmk_firmware/pull/22970), [#22979](https://github.com/qmk/qmk_firmware/pull/22979)) {#bootmagic-rename}
|
||||
|
||||
Bootmagic "Lite" had no real meaning once the historical Bootmagic "Full" was deprecated and removed. Any references to _Bootmagic Lite_ should now just refer to _Bootmagic_. We hope we got the majority of the code and the documentation, so if you find any more, let us know!
|
||||
|
||||
### Threshold for automatic mouse layer activation ([#21398](https://github.com/qmk/qmk_firmware/pull/21398)) :id=auto-mouse-layer
|
||||
### Threshold for automatic mouse layer activation ([#21398](https://github.com/qmk/qmk_firmware/pull/21398)) {#auto-mouse-layer}
|
||||
|
||||
In some cases, accidental automatic activation of the mouse layer made it difficult to continue typing, such as when brushing across a trackball. `AUTO_MOUSE_THRESHOLD` is now a configurable option in `config.h` which allows for specifying what the movement threshold is before automatically activating the mouse layer.
|
||||
|
||||
### DIP Switch Mapping ([#22543](https://github.com/qmk/qmk_firmware/pull/22543)) :id=dip-switch-map
|
||||
### DIP Switch Mapping ([#22543](https://github.com/qmk/qmk_firmware/pull/22543)) {#dip-switch-map}
|
||||
|
||||
Much like Encoder Mapping, DIP Switch Mapping allows for specifying a table of actions to execute when a DIP switch state changes. See the [DIP Switch Documentation](feature_dip_switch.md#dip-switch-map) for more information.
|
||||
Much like Encoder Mapping, DIP Switch Mapping allows for specifying a table of actions to execute when a DIP switch state changes. See the [DIP Switch Documentation](../features/dip_switch#dip-switch-map) for more information.
|
||||
|
||||
```c
|
||||
#if defined(DIP_SWITCH_MAP_ENABLE)
|
||||
@ -131,7 +131,7 @@ const uint16_t PROGMEM dip_switch_map[NUM_DIP_SWITCHES][NUM_DIP_STATES] = {
|
||||
#endif
|
||||
```
|
||||
|
||||
### Quantum Painter updates ([#18521](https://github.com/qmk/qmk_firmware/pull/18521), [#20645](https://github.com/qmk/qmk_firmware/pull/20645), [#22358](https://github.com/qmk/qmk_firmware/pull/22358)) :id=qp-updates
|
||||
### Quantum Painter updates ([#18521](https://github.com/qmk/qmk_firmware/pull/18521), [#20645](https://github.com/qmk/qmk_firmware/pull/20645), [#22358](https://github.com/qmk/qmk_firmware/pull/22358)) {#qp-updates}
|
||||
|
||||
Quantum Painter picked up support for the following:
|
||||
|
||||
@ -141,7 +141,7 @@ Quantum Painter picked up support for the following:
|
||||
|
||||
Quantum Painter now supports the majority of common OLED panels supported by the basic OLED driver, so if you're using an ARM-based board you may find Quantum Painter a much more feature-rich API in comparison.
|
||||
|
||||
## Full changelist :id=full-changelist
|
||||
## Full changelist {#full-changelist}
|
||||
|
||||
Core:
|
||||
* [Driver] ILI9486 on Quantum Painter ([#18521](https://github.com/qmk/qmk_firmware/pull/18521))
|
||||
|
344
docs/ChangeLog/20240526.md
Normal file
344
docs/ChangeLog/20240526.md
Normal file
@ -0,0 +1,344 @@
|
||||
# QMK Breaking Changes - 2024 May 26 Changelog
|
||||
|
||||
## Notable Features {#notable-features}
|
||||
|
||||
May 2024 brings about another heavy maintenance release of QMK. Of the 209 PRs created this breaking changes cycle against the `develop` branch, 174 behind-the-scenes PRs (83%!) were aimed at converting, consolidating, and cleaning up keyboards and their configuration data. Not the most glamorous work, but it means QMK is in a much more manageable spot than what it was 3 months prior. The work steadily continues!
|
||||
|
||||
## Changes Requiring User Action {#changes-requiring-user-action}
|
||||
|
||||
### Updated Keyboard Codebases {#updated-keyboard-codebases}
|
||||
|
||||
One note with updated keyboard names -- historical keyboard names are still considered valid when using [External Userspace](../newbs_external_userspace) for builds. If you're already using External Userspace, you do not need to move your keymap inside your repository.
|
||||
|
||||
| Old Keyboard Name | New Keyboard Name |
|
||||
|------------------------------|-----------------------------------|
|
||||
| adkb96 | adkb96/rev1 |
|
||||
| canary/canary60rgb | canary/canary60rgb/v1 |
|
||||
| handwired/meck_tkl | handwired/meck_tkl/blackpill_f401 |
|
||||
| handwired/qc60 | handwired/qc60/proto |
|
||||
| handwired/stef9998/split_5x7 | handwired/stef9998/split_5x7/rev1 |
|
||||
| junco | junco/rev1 |
|
||||
| keaboard | keaboard/rev1 |
|
||||
| kprepublic/jj40 | kprepublic/jj40/rev1 |
|
||||
| kprepublic/jj50 | kprepublic/jj50/rev1 |
|
||||
| melgeek/mj65 | melgeek/mj65/rev3 |
|
||||
| melgeek/mojo68 | melgeek/mojo68/rev1 |
|
||||
| melgeek/mojo75 | melgeek/mojo75/rev1 |
|
||||
| melgeek/tegic | melgeek/tegic/rev1 |
|
||||
| melgeek/z70ultra | melgeek/z70ultra/rev1 |
|
||||
| miiiw/blackio83 | miiiw/blackio83/rev_0100 |
|
||||
| murcielago | murcielago/rev1 |
|
||||
| polilla | polilla/rev1 |
|
||||
| qwertyydox | qwertyydox/rev1 |
|
||||
| spaceholdings/nebula68b | spaceholdings/nebula68b/solder |
|
||||
| splitty | splitty/rev1 |
|
||||
| xiudi/xd004 | xiudi/xd004/v1 |
|
||||
|
||||
### Remove deprecated quantum keycodes ([#23407](https://github.com/qmk/qmk_firmware/pull/23407))
|
||||
|
||||
A bunch of legacy keycodes have been removed -- check [the affected keycodes](https://github.com/qmk/qmk_firmware/blob/70e34e491c297231a3f987fd69760d38e79dbfa4/quantum/quantum_keycodes_legacy.h) if you run into compilation problems, as it'll show you what the problematic keycodes should be replaced with.
|
||||
|
||||
The latest of these were officially deprecated within QMK in the August 2023 breaking changes -- the new keycodes are the way forward.
|
||||
|
||||
### P3D Spacey Layout Updates ([#23329](https://github.com/qmk/qmk_firmware/pull/23329)) {#spacey-layout-updates}
|
||||
|
||||
This PR removed the `LAYOUT` macro that was configured for the Spacey.
|
||||
If you have a keymap for this keyboard, you will need to update your
|
||||
keymap using the following steps:
|
||||
|
||||
1. Change your layout macro to `LAYOUT_all`.
|
||||
2. Remove the two `KC_NO` keycodes following the Space and Delete keys
|
||||
on the bottom row.
|
||||
3. Move the keycode for the encoder pushbutton (customarily Mute) to the
|
||||
end of the top row, after the customary Backspace key.
|
||||
4. Move the keycode for the Right Arrow to the end of the Shift row,
|
||||
after the Down Arrow key.
|
||||
|
||||
### MechKeys ACR60 Layout Updates ([#23309](https://github.com/qmk/qmk_firmware/pull/23309)) {#acr60-layout-updates}
|
||||
|
||||
This PR removed and changed some of the layouts that were configured for the ACR60. If you use one of the following layouts, you will need to update your keymap:
|
||||
|
||||
- [`LAYOUT_hhkb`](#layout-hhkb)
|
||||
- [`LAYOUT_true_hhkb`](#layout-true-hhkb)
|
||||
- [`LAYOUT_directional`](#layout-directional)
|
||||
- [`LAYOUT_mitchsplit`](#layout-mitchsplit)
|
||||
|
||||
#### `LAYOUT_hhkb` {#acr60-layout-hhkb}
|
||||
|
||||
1. Change your layout macro to `LAYOUT_60_hhkb`.
|
||||
1. Remove any keycodes for the key between Left Shift and QWERTY Z.
|
||||
|
||||
#### `LAYOUT_true_hhkb` {#acr60-layout-true-hhkb}
|
||||
|
||||
1. Change your layout macro to `LAYOUT_60_true_hhkb`.
|
||||
1. Remove any keycodes for the key between Left Shift and QWERTY Z.
|
||||
|
||||
#### `LAYOUT_directional` {#acr60-layout-directional}
|
||||
|
||||
1. Change your layout macro to `LAYOUT_60_ansi_arrow_split_bs`.
|
||||
1. Remove any keycodes for the key between Left Shift and QWERTY Z.
|
||||
1. Remove any keycodes for the keys immediately before *and* after the 1.25u key of Split Spacebar.
|
||||
|
||||
If you need split spacebars, you may implement `LAYOUT_60_ansi_arrow_split_space_split_bs` and change your layout to it, removing the keycode between Left Shift and QWERTY Z.
|
||||
|
||||
#### `LAYOUT_mitchsplit` {#acr60-layout-mitchsplit}
|
||||
|
||||
1. Use `LAYOUT_60_ansi_split_space_split_rshift`.
|
||||
|
||||
## Notable core changes {#notable-core}
|
||||
|
||||
### Introduction of `keyboard.json` ([22891](https://github.com/qmk/qmk_firmware/pull/22891)) {#keyboard-json}
|
||||
|
||||
One longer term goal of QMK is increased maintainability.
|
||||
As part of the continued push towards [Data Driven Configuration](../data_driven_config), the build system has been updated to simplify the existing codebase, and power future workflows.
|
||||
|
||||
The `keyboard.json` configuration file allows the support of a single data file for keyboard level config.
|
||||
|
||||
Additionally,
|
||||
* `info.json` now represents potential fragments of config that can be shared across keyboard revisions.
|
||||
* `rules.mk` is now optional - Completely blank files are no longer required.
|
||||
* Currently supported keyboards have been migrated to reflect this change.
|
||||
|
||||
Backwards compatibility of the old system has been maintained, but will be removed in a future breaking changes cycle.
|
||||
|
||||
### Refactor ChibiOS USB endpoints to be fully async ([#21656](https://github.com/qmk/qmk_firmware/pull/21656))
|
||||
|
||||
For most users, this change will mean suspend and resume on ARM-based boards works correctly. Others will notice that their keyboard now works correctly in BIOS/UEFI.
|
||||
|
||||
Essentially, changes were made in the internals of how QMK interacts with USB for ARM-based devices. Before this change, whenever a packet was attempted to be sent from the keyboard to the host machine, QMK would wait for the transmission to complete. After this change, those packets are queued and sent when opportune; this results in much better "correctness" as far as the USB protocol is concerned, and means far less likelihood of failure scenarios such as "stuck keys" or "random lockups" and the like.
|
||||
|
||||
Compliance checks were run against QMK firmwares for the most popular ARM microcontrollers, as well as suspend/resume tests. As far as we can tell, a whole host of hard-to-reproduce issues are mitigated by this change.
|
||||
|
||||
## Deprecation Notices
|
||||
|
||||
In line with the [notice period](../support_deprecation_policy#how-much-advance-notice-will-be-given), deprecation notices for larger items are listed here.
|
||||
|
||||
### Migration of VIA keymaps to VIA team control
|
||||
|
||||
The QMK team has been in discussion with the VIA maintainers and all VIA-related keymaps in the `qmk_firmware` repository will transition to a `qmk_userspace`-style repository under the VIA team's control at the end of the next breaking changes period. This allows the VIA team to support many more custom keyboard configurations, as well as reduces the turnaround time for any changes to the VIA protocol they wish to make.
|
||||
|
||||
At the end of the breaking changes cycle ending 2024-08-25, VIA-enabled keymaps will no longer be accepted into the QMK repository. At the time of migration, any open PRs against `qmk_firmware` which include new VIA-related keymaps will be subsequently be asked to remove those keymaps and instead raise a PR against the userspace repository containing all VIA keymaps.
|
||||
|
||||
## Full changelist {#full-changelist}
|
||||
|
||||
Core:
|
||||
* Refactor vusb to protocol use pre/post task ([#14944](https://github.com/qmk/qmk_firmware/pull/14944))
|
||||
* Refactor ChibiOS USB endpoints to be fully async ([#21656](https://github.com/qmk/qmk_firmware/pull/21656))
|
||||
* Infer eeconfig identifiers ([#22135](https://github.com/qmk/qmk_firmware/pull/22135))
|
||||
* [Audio] Add support for audio shutdown pin ([#22731](https://github.com/qmk/qmk_firmware/pull/22731))
|
||||
* Enable 'keyboard.json' as a build target ([#22891](https://github.com/qmk/qmk_firmware/pull/22891))
|
||||
* Remove unuseful layer_on() call ([#23055](https://github.com/qmk/qmk_firmware/pull/23055))
|
||||
* Add init function to RGBLight driver struct ([#23076](https://github.com/qmk/qmk_firmware/pull/23076))
|
||||
* Add utility functions for Pointing Device Auto Mouse feature ([#23144](https://github.com/qmk/qmk_firmware/pull/23144))
|
||||
* Remove midi_ep_task from ChibiOS ([#23162](https://github.com/qmk/qmk_firmware/pull/23162))
|
||||
* LED drivers: add support for IS31FL3236 ([#23264](https://github.com/qmk/qmk_firmware/pull/23264))
|
||||
* Un-`extern` RGBLight `led[]` array ([#23322](https://github.com/qmk/qmk_firmware/pull/23322))
|
||||
* Update I2C API usage in keyboard code ([#23360](https://github.com/qmk/qmk_firmware/pull/23360))
|
||||
* Update GPIO expander API naming ([#23375](https://github.com/qmk/qmk_firmware/pull/23375))
|
||||
* Remove deprecated quantum keycodes ([#23407](https://github.com/qmk/qmk_firmware/pull/23407))
|
||||
* Add MacOS Czech ISO and ANSI keymaps #23346 ([#23412](https://github.com/qmk/qmk_firmware/pull/23412))
|
||||
* Rename `process_{led,rgb}_matrix()` ([#23422](https://github.com/qmk/qmk_firmware/pull/23422))
|
||||
* Separate keycode handling for LED Matrix and Backlight ([#23426](https://github.com/qmk/qmk_firmware/pull/23426))
|
||||
* Add new set of keycodes for LED Matrix ([#23432](https://github.com/qmk/qmk_firmware/pull/23432))
|
||||
* Oneshot locked mods split transaction ([#23434](https://github.com/qmk/qmk_firmware/pull/23434))
|
||||
* Bodge consolidation. ([#23448](https://github.com/qmk/qmk_firmware/pull/23448))
|
||||
* LED Matrix: replace backlight keycodes with newly added ones ([#23455](https://github.com/qmk/qmk_firmware/pull/23455))
|
||||
* Add new set of keycodes for RGB Matrix ([#23463](https://github.com/qmk/qmk_firmware/pull/23463))
|
||||
* Refactoring successive press() release() calls into tap_key() calls ([#23573](https://github.com/qmk/qmk_firmware/pull/23573))
|
||||
* Rename `RGBW` define to `WS2812_RGBW` ([#23585](https://github.com/qmk/qmk_firmware/pull/23585))
|
||||
* Normalise RGBLight (underglow) keycodes ([#23656](https://github.com/qmk/qmk_firmware/pull/23656))
|
||||
* split_util: rename `usbIsActive` to `usb_bus_detected` ([#23657](https://github.com/qmk/qmk_firmware/pull/23657))
|
||||
* Insert delay between shifted chars in send_string_with_delay for AVR ([#23673](https://github.com/qmk/qmk_firmware/pull/23673))
|
||||
* Remove useless `LED/RGB_MATRIX_ENABLE` ifdefs ([#23726](https://github.com/qmk/qmk_firmware/pull/23726))
|
||||
|
||||
CLI:
|
||||
* Some metadata on QGF/QFF files ([#20101](https://github.com/qmk/qmk_firmware/pull/20101))
|
||||
* `qmk new-keyboard` - detach community layout when selecting "none of the above" ([#20405](https://github.com/qmk/qmk_firmware/pull/20405))
|
||||
* Initial `qmk test-c` functionality ([#23038](https://github.com/qmk/qmk_firmware/pull/23038))
|
||||
* Reject duplicate matrix locations in LAYOUT macros ([#23273](https://github.com/qmk/qmk_firmware/pull/23273))
|
||||
* Align 'qmk lint' argument handling ([#23297](https://github.com/qmk/qmk_firmware/pull/23297))
|
||||
* Produce warning if keyboard is not configured via `keyboard.json` ([#23321](https://github.com/qmk/qmk_firmware/pull/23321))
|
||||
|
||||
Submodule updates:
|
||||
* Update ChibiOS submodules. ([#23405](https://github.com/qmk/qmk_firmware/pull/23405))
|
||||
|
||||
Keyboards:
|
||||
* Move `SPLIT_KEYBOARD` to data driven ([#21410](https://github.com/qmk/qmk_firmware/pull/21410))
|
||||
* Change to `development_board` ([#21695](https://github.com/qmk/qmk_firmware/pull/21695))
|
||||
* Add solid_reactive effects for MIIIW BlackIO83 ([#22251](https://github.com/qmk/qmk_firmware/pull/22251))
|
||||
* Migrate content where only parent info.json exists ([#22895](https://github.com/qmk/qmk_firmware/pull/22895))
|
||||
* Remove redundant disabling of features ([#22926](https://github.com/qmk/qmk_firmware/pull/22926))
|
||||
* Update ScottoAlp handwired keyboard to 12 column layout ([#22962](https://github.com/qmk/qmk_firmware/pull/22962))
|
||||
* Overhaul ploopyco devices ([#22967](https://github.com/qmk/qmk_firmware/pull/22967))
|
||||
* Add rp2040_ce option to lotus58 ([#23185](https://github.com/qmk/qmk_firmware/pull/23185))
|
||||
* Migrate features from rules.mk to data driven - 0-9 ([#23202](https://github.com/qmk/qmk_firmware/pull/23202))
|
||||
* Change default RGB effect for momokai keypads to solid white ([#23217](https://github.com/qmk/qmk_firmware/pull/23217))
|
||||
* Migrate annepro2 away from custom matrix ([#23221](https://github.com/qmk/qmk_firmware/pull/23221))
|
||||
* Update BAMFK-1 ([#23236](https://github.com/qmk/qmk_firmware/pull/23236))
|
||||
* Migrate features from rules.mk to data driven - ABCD ([#23247](https://github.com/qmk/qmk_firmware/pull/23247))
|
||||
* Migrate features from rules.mk to data driven - EFGH ([#23248](https://github.com/qmk/qmk_firmware/pull/23248))
|
||||
* Remove 60_ansi_arrow_split_bs_7u_spc Community Layout ([#23259](https://github.com/qmk/qmk_firmware/pull/23259))
|
||||
* Migrate features from rules.mk to data driven - IJK ([#23276](https://github.com/qmk/qmk_firmware/pull/23276))
|
||||
* Migrate features from rules.mk to data driven - LMN ([#23277](https://github.com/qmk/qmk_firmware/pull/23277))
|
||||
* Migrate features from rules.mk to data driven - OPQR ([#23285](https://github.com/qmk/qmk_firmware/pull/23285))
|
||||
* Migrate features from rules.mk to data driven - ST ([#23286](https://github.com/qmk/qmk_firmware/pull/23286))
|
||||
* Migrate features from rules.mk to data driven - UVWXYZ ([#23287](https://github.com/qmk/qmk_firmware/pull/23287))
|
||||
* Swift65 Hotswap Layout Name Standardization ([#23288](https://github.com/qmk/qmk_firmware/pull/23288))
|
||||
* Swift65 Solder Layout Name Standardization ([#23289](https://github.com/qmk/qmk_firmware/pull/23289))
|
||||
* Migrate build target markers to keyboard.json ([#23293](https://github.com/qmk/qmk_firmware/pull/23293))
|
||||
* KPRepublic JJ50 rev1 Refactor ([#23294](https://github.com/qmk/qmk_firmware/pull/23294))
|
||||
* KPRepublic JJ40 rev1 Refactor ([#23299](https://github.com/qmk/qmk_firmware/pull/23299))
|
||||
* Migrate features and LTO from rules.mk to data driven ([#23302](https://github.com/qmk/qmk_firmware/pull/23302))
|
||||
* Add RGB lighting for the PetruziaMini ([#23305](https://github.com/qmk/qmk_firmware/pull/23305))
|
||||
* Migrate features and LTO from rules.mk to data driven ([#23307](https://github.com/qmk/qmk_firmware/pull/23307))
|
||||
* MechKeys ACR60 Layout Updates ([#23309](https://github.com/qmk/qmk_firmware/pull/23309))
|
||||
* Remove RGBLight `led[]` references ([#23311](https://github.com/qmk/qmk_firmware/pull/23311))
|
||||
* Reduce firmware size of helix/rev3 ([#23324](https://github.com/qmk/qmk_firmware/pull/23324))
|
||||
* P3D Spacey Layout Updates ([#23329](https://github.com/qmk/qmk_firmware/pull/23329))
|
||||
* Data-Driven Keyboard Conversions: 0-9 ([#23357](https://github.com/qmk/qmk_firmware/pull/23357))
|
||||
* Update GPIO API usage in keyboard code ([#23361](https://github.com/qmk/qmk_firmware/pull/23361))
|
||||
* Remove "w": 1 from keyboards/ ([#23367](https://github.com/qmk/qmk_firmware/pull/23367))
|
||||
* Remove `quantum.h` includes from keyboard custom `matrix.c`s ([#23371](https://github.com/qmk/qmk_firmware/pull/23371))
|
||||
* refactor: mechwild/bbs ([#23373](https://github.com/qmk/qmk_firmware/pull/23373))
|
||||
* Remove 'NO_USB_STARTUP_CHECK = no' from keyboards ([#23376](https://github.com/qmk/qmk_firmware/pull/23376))
|
||||
* Remove completely redundant DEFAULT_FOLDER from keyboards ([#23377](https://github.com/qmk/qmk_firmware/pull/23377))
|
||||
* Miscellaneous keyboard.json migrations ([#23378](https://github.com/qmk/qmk_firmware/pull/23378))
|
||||
* Data-Driven Keyboard Conversions: A ([#23379](https://github.com/qmk/qmk_firmware/pull/23379))
|
||||
* refactor: flehrad/bigswitch ([#23384](https://github.com/qmk/qmk_firmware/pull/23384))
|
||||
* add second encoder to matrix info of arrowmechanics/wings ([#23390](https://github.com/qmk/qmk_firmware/pull/23390))
|
||||
* Change the VID and PID of the file kb38 info.json ([#23393](https://github.com/qmk/qmk_firmware/pull/23393))
|
||||
* Remove `quantum.h` includes from keyboard code ([#23394](https://github.com/qmk/qmk_firmware/pull/23394))
|
||||
* [ UPDATE 15PAD & 6PAD ] ([#23397](https://github.com/qmk/qmk_firmware/pull/23397))
|
||||
* Remove more unnecessary `quantum.h` includes ([#23402](https://github.com/qmk/qmk_firmware/pull/23402))
|
||||
* KB name change to Part.1-75-HS ([#23403](https://github.com/qmk/qmk_firmware/pull/23403))
|
||||
* Tidy up keyboards/zvecr ([#23418](https://github.com/qmk/qmk_firmware/pull/23418))
|
||||
* "features.split" is not a valid key ([#23419](https://github.com/qmk/qmk_firmware/pull/23419))
|
||||
* Migrate build target markers to keyboard.json - YZ ([#23421](https://github.com/qmk/qmk_firmware/pull/23421))
|
||||
* refactor: mechwild/waka60 ([#23423](https://github.com/qmk/qmk_firmware/pull/23423))
|
||||
* Convert some AVR GPIO operations to macros ([#23424](https://github.com/qmk/qmk_firmware/pull/23424))
|
||||
* Data-Driven Keyboard Conversions: B ([#23425](https://github.com/qmk/qmk_firmware/pull/23425))
|
||||
* Tidy up default layer handling in keymaps ([#23436](https://github.com/qmk/qmk_firmware/pull/23436))
|
||||
* Added Chapter1 ([#23452](https://github.com/qmk/qmk_firmware/pull/23452))
|
||||
* Data-driven Keyboard Conversions: C ([#23453](https://github.com/qmk/qmk_firmware/pull/23453))
|
||||
* Migrate build target markers to keyboard.json - X ([#23460](https://github.com/qmk/qmk_firmware/pull/23460))
|
||||
* Data-Driven Keyboard Conversions: D ([#23461](https://github.com/qmk/qmk_firmware/pull/23461))
|
||||
* Miscellaneous keyboard.json migrations ([#23486](https://github.com/qmk/qmk_firmware/pull/23486))
|
||||
* Migrate build target markers to keyboard.json - 0AB ([#23488](https://github.com/qmk/qmk_firmware/pull/23488))
|
||||
* Migrate build target markers to keyboard.json - W ([#23511](https://github.com/qmk/qmk_firmware/pull/23511))
|
||||
* Data-Driven Keyboard Conversions: E ([#23512](https://github.com/qmk/qmk_firmware/pull/23512))
|
||||
* Migrate build target markers to keyboard.json - TUV ([#23514](https://github.com/qmk/qmk_firmware/pull/23514))
|
||||
* Migrate build target markers to keyboard.json - DE ([#23515](https://github.com/qmk/qmk_firmware/pull/23515))
|
||||
* Data-Driven Keyboard Conversions: F ([#23516](https://github.com/qmk/qmk_firmware/pull/23516))
|
||||
* Data-Driven Keyboard Conversions: G ([#23522](https://github.com/qmk/qmk_firmware/pull/23522))
|
||||
* Data-Driven Keyboard Conversions: H, Part 1 ([#23524](https://github.com/qmk/qmk_firmware/pull/23524))
|
||||
* Data-Driven Keyboard Conversions: H, Part 2 ([#23525](https://github.com/qmk/qmk_firmware/pull/23525))
|
||||
* Migrate build target markers to keyboard.json - C ([#23529](https://github.com/qmk/qmk_firmware/pull/23529))
|
||||
* Data-Driven Keyboard Conversions: H, Part 3 ([#23530](https://github.com/qmk/qmk_firmware/pull/23530))
|
||||
* Migrate build target markers to keyboard.json - S ([#23532](https://github.com/qmk/qmk_firmware/pull/23532))
|
||||
* Data-Driven Keyboard Conversions: I ([#23533](https://github.com/qmk/qmk_firmware/pull/23533))
|
||||
* Migrate build target markers to keyboard.json - FG ([#23534](https://github.com/qmk/qmk_firmware/pull/23534))
|
||||
* Migrate build target markers to keyboard.json - HI ([#23540](https://github.com/qmk/qmk_firmware/pull/23540))
|
||||
* Remove *_SUPPORTED = yes ([#23541](https://github.com/qmk/qmk_firmware/pull/23541))
|
||||
* Migrate build target markers to keyboard.json - R ([#23542](https://github.com/qmk/qmk_firmware/pull/23542))
|
||||
* Data-Driven Keyboard Conversions: J ([#23547](https://github.com/qmk/qmk_firmware/pull/23547))
|
||||
* Data-Driven Keyboard Conversions: K, Part 1 ([#23556](https://github.com/qmk/qmk_firmware/pull/23556))
|
||||
* Tidy use of raw hid within keyboards ([#23557](https://github.com/qmk/qmk_firmware/pull/23557))
|
||||
* Data-Driven Keyboard Conversions: K, Part 2 ([#23562](https://github.com/qmk/qmk_firmware/pull/23562))
|
||||
* Migrate build target markers to keyboard.json - OQ ([#23564](https://github.com/qmk/qmk_firmware/pull/23564))
|
||||
* Migrate build target markers to keyboard.json - P ([#23565](https://github.com/qmk/qmk_firmware/pull/23565))
|
||||
* Data-Driven Keyboard Conversions: K, Part 3 ([#23566](https://github.com/qmk/qmk_firmware/pull/23566))
|
||||
* Data-Driven Keyboard Conversions: K, Part 4 ([#23567](https://github.com/qmk/qmk_firmware/pull/23567))
|
||||
* Data-Driven Keyboard Conversions: K, Part 5 ([#23569](https://github.com/qmk/qmk_firmware/pull/23569))
|
||||
* Data-Driven Keyboard Conversions: L ([#23576](https://github.com/qmk/qmk_firmware/pull/23576))
|
||||
* Migrate build target markers to keyboard.json - JK ([#23588](https://github.com/qmk/qmk_firmware/pull/23588))
|
||||
* Migrate build target markers to keyboard.json - N ([#23589](https://github.com/qmk/qmk_firmware/pull/23589))
|
||||
* Data-Driven Keyboard Conversions: M, Part 1 ([#23590](https://github.com/qmk/qmk_firmware/pull/23590))
|
||||
* Add haptic driver to keyboard.json schema ([#23591](https://github.com/qmk/qmk_firmware/pull/23591))
|
||||
* Migrate build target markers to keyboard.json - Keychron ([#23593](https://github.com/qmk/qmk_firmware/pull/23593))
|
||||
* Remove RGBLIGHT_SPLIT in rules.mk ([#23599](https://github.com/qmk/qmk_firmware/pull/23599))
|
||||
* Data-Driven Keyboard Conversions: M, Part 2 ([#23601](https://github.com/qmk/qmk_firmware/pull/23601))
|
||||
* Align NO_SUSPEND_POWER_DOWN keyboard config ([#23606](https://github.com/qmk/qmk_firmware/pull/23606))
|
||||
* Migrate build target markers to keyboard.json - L ([#23607](https://github.com/qmk/qmk_firmware/pull/23607))
|
||||
* Migrate build target markers to keyboard.json - Misc ([#23609](https://github.com/qmk/qmk_firmware/pull/23609))
|
||||
* Migrate build target markers to keyboard.json - Misc ([#23612](https://github.com/qmk/qmk_firmware/pull/23612))
|
||||
* Data-Driven Keyboard Conversions: M, Part 3 ([#23614](https://github.com/qmk/qmk_firmware/pull/23614))
|
||||
* Add audio driver to keyboard.json schema ([#23616](https://github.com/qmk/qmk_firmware/pull/23616))
|
||||
* Data-Driven Keyboard Conversions: BastardKB ([#23622](https://github.com/qmk/qmk_firmware/pull/23622))
|
||||
* Data-Driven Keyboard Conversions: Mechlovin ([#23624](https://github.com/qmk/qmk_firmware/pull/23624))
|
||||
* Migrate build target markers to keyboard.json - BM ([#23627](https://github.com/qmk/qmk_firmware/pull/23627))
|
||||
* gh80_3000 - Enable indicator LED functionality ([#23633](https://github.com/qmk/qmk_firmware/pull/23633))
|
||||
* Iris keymap update ([#23635](https://github.com/qmk/qmk_firmware/pull/23635))
|
||||
* Migrate build target markers to keyboard.json - Misc ([#23653](https://github.com/qmk/qmk_firmware/pull/23653))
|
||||
* Add via support for craftwalk ([#23658](https://github.com/qmk/qmk_firmware/pull/23658))
|
||||
* Align RGBKB keyboards to current standards ([#23663](https://github.com/qmk/qmk_firmware/pull/23663))
|
||||
* Remove 'split.transport.protocol=serial_usart' ([#23668](https://github.com/qmk/qmk_firmware/pull/23668))
|
||||
* Remove redundant keymap templates ([#23685](https://github.com/qmk/qmk_firmware/pull/23685))
|
||||
* Change all RGB mode keycodes to short aliases ([#23691](https://github.com/qmk/qmk_firmware/pull/23691))
|
||||
* Adjust keycode alignment around `QK_BOOT` ([#23697](https://github.com/qmk/qmk_firmware/pull/23697))
|
||||
* Remove RGB keycodes from boards with no RGB config ([#23709](https://github.com/qmk/qmk_firmware/pull/23709))
|
||||
* Miscellaneous Data-Driven Keyboard Conversions ([#23712](https://github.com/qmk/qmk_firmware/pull/23712))
|
||||
* Delete trivial keymap readmes ([#23714](https://github.com/qmk/qmk_firmware/pull/23714))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: 0-9 ([#23716](https://github.com/qmk/qmk_firmware/pull/23716))
|
||||
* Add media key support to Riot Pad ([#23719](https://github.com/qmk/qmk_firmware/pull/23719))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: A-C, Part 1 ([#23745](https://github.com/qmk/qmk_firmware/pull/23745))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: A-C, Part 2 ([#23746](https://github.com/qmk/qmk_firmware/pull/23746))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: A-C, Part 3 ([#23747](https://github.com/qmk/qmk_firmware/pull/23747))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: D, Part 1 ([#23749](https://github.com/qmk/qmk_firmware/pull/23749))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: D, Part 2 ([#23750](https://github.com/qmk/qmk_firmware/pull/23750))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: E ([#23751](https://github.com/qmk/qmk_firmware/pull/23751))
|
||||
* Move VIA config to keymap level ([#23754](https://github.com/qmk/qmk_firmware/pull/23754))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: F ([#23757](https://github.com/qmk/qmk_firmware/pull/23757))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: G ([#23758](https://github.com/qmk/qmk_firmware/pull/23758))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: H, Part 1 ([#23759](https://github.com/qmk/qmk_firmware/pull/23759))
|
||||
* Remove includes of config.h ([#23760](https://github.com/qmk/qmk_firmware/pull/23760))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: H, Part 2 ([#23762](https://github.com/qmk/qmk_firmware/pull/23762))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: H, Part 3 ([#23763](https://github.com/qmk/qmk_firmware/pull/23763))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: H, Part 4 ([#23764](https://github.com/qmk/qmk_firmware/pull/23764))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: I-J ([#23767](https://github.com/qmk/qmk_firmware/pull/23767))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: K, Part 1 ([#23768](https://github.com/qmk/qmk_firmware/pull/23768))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: K, Part 2 ([#23769](https://github.com/qmk/qmk_firmware/pull/23769))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: K, Part 3 ([#23770](https://github.com/qmk/qmk_firmware/pull/23770))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: L ([#23771](https://github.com/qmk/qmk_firmware/pull/23771))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: M, Part 1 ([#23772](https://github.com/qmk/qmk_firmware/pull/23772))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: M, Part 2 ([#23773](https://github.com/qmk/qmk_firmware/pull/23773))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: N ([#23774](https://github.com/qmk/qmk_firmware/pull/23774))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: O ([#23778](https://github.com/qmk/qmk_firmware/pull/23778))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: P, Part 1 ([#23779](https://github.com/qmk/qmk_firmware/pull/23779))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: P, Part 2 ([#23780](https://github.com/qmk/qmk_firmware/pull/23780))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: Q-R ([#23781](https://github.com/qmk/qmk_firmware/pull/23781))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: S, Part 1 ([#23783](https://github.com/qmk/qmk_firmware/pull/23783))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: S, Part 2 ([#23784](https://github.com/qmk/qmk_firmware/pull/23784))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: T ([#23785](https://github.com/qmk/qmk_firmware/pull/23785))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: U-V ([#23786](https://github.com/qmk/qmk_firmware/pull/23786))
|
||||
* Remove some useless code from keymaps ([#23787](https://github.com/qmk/qmk_firmware/pull/23787))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: W, Part 1 ([#23788](https://github.com/qmk/qmk_firmware/pull/23788))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: W, Part 2 ([#23789](https://github.com/qmk/qmk_firmware/pull/23789))
|
||||
* Migrate `LOCKING_*_ENABLE` to Data-Driven: X-Z ([#23790](https://github.com/qmk/qmk_firmware/pull/23790))
|
||||
* Update GPIO macros in keymaps ([#23792](https://github.com/qmk/qmk_firmware/pull/23792))
|
||||
* noroadsleft's 0.25.0 Changelogs and Touch-Ups ([#23793](https://github.com/qmk/qmk_firmware/pull/23793))
|
||||
|
||||
Keyboard fixes:
|
||||
* Fix mapping of GUI/ALT for Win/Mac layers ([#22662](https://github.com/qmk/qmk_firmware/pull/22662))
|
||||
* Adding standard keymap for wave keyboard to fix #22695 ([#22741](https://github.com/qmk/qmk_firmware/pull/22741))
|
||||
* Fixup qk100 (firmware size) ([#23169](https://github.com/qmk/qmk_firmware/pull/23169))
|
||||
* Fixup mechlovin/octagon ([#23179](https://github.com/qmk/qmk_firmware/pull/23179))
|
||||
* Fix up scanning for Djinn, post-asyncUSB. ([#23188](https://github.com/qmk/qmk_firmware/pull/23188))
|
||||
* Fixup annepro2 ([#23206](https://github.com/qmk/qmk_firmware/pull/23206))
|
||||
* Fixed keychron q1v1 led config for iso layout ([#23222](https://github.com/qmk/qmk_firmware/pull/23222))
|
||||
* Fixes for idobao vendor keymaps ([#23246](https://github.com/qmk/qmk_firmware/pull/23246))
|
||||
* Fixup work_board ([#23266](https://github.com/qmk/qmk_firmware/pull/23266))
|
||||
* Linworks FAve 87H Keymap Refactor/Bugfix ([#23292](https://github.com/qmk/qmk_firmware/pull/23292))
|
||||
* Align encoder layout validation with encoder.h logic ([#23330](https://github.com/qmk/qmk_firmware/pull/23330))
|
||||
* 0xcb/splaytoraid: remove `CONVERT_TO` at keyboard level ([#23395](https://github.com/qmk/qmk_firmware/pull/23395))
|
||||
* 40percentclub/gherkin: remove `CONVERT_TO` at keyboard level ([#23396](https://github.com/qmk/qmk_firmware/pull/23396))
|
||||
* Fix spaceholdings/nebula68b ([#23399](https://github.com/qmk/qmk_firmware/pull/23399))
|
||||
* Fix failing keyboards on develop ([#23406](https://github.com/qmk/qmk_firmware/pull/23406))
|
||||
* Corrections to split keyboard migrations ([#23462](https://github.com/qmk/qmk_firmware/pull/23462))
|
||||
* Fix iris via keymap ([#23652](https://github.com/qmk/qmk_firmware/pull/23652))
|
||||
* xiudi/xd75 - Fix backlight compilation issues ([#23655](https://github.com/qmk/qmk_firmware/pull/23655))
|
||||
|
||||
Bugs:
|
||||
* WS2812 PWM: prefix for DMA defines ([#23111](https://github.com/qmk/qmk_firmware/pull/23111))
|
||||
* Fix rgblight init ([#23335](https://github.com/qmk/qmk_firmware/pull/23335))
|
||||
* Fix WAIT_FOR_USB handling ([#23598](https://github.com/qmk/qmk_firmware/pull/23598))
|
||||
* Fix PS/2 Trackpoint mouse clicks (#22265) ([#23694](https://github.com/qmk/qmk_firmware/pull/23694))
|
@ -1,37 +0,0 @@
|
||||
# Quantum Mechanical Keyboard Firmware
|
||||
|
||||
## What is QMK Firmware?
|
||||
|
||||
QMK (*Quantum Mechanical Keyboard*) is an open source community centered around developing computer input devices. The community encompasses all sorts of input devices, such as keyboards, mice, and MIDI devices. A core group of collaborators maintains [QMK Firmware](https://github.com/qmk/qmk_firmware), [QMK Configurator](https://config.qmk.fm), [QMK Toolbox](https://github.com/qmk/qmk_toolbox), [qmk.fm](https://qmk.fm), and this documentation with the help of community members like you.
|
||||
|
||||
## Get Started
|
||||
|
||||
<div class="flex-container">
|
||||
|
||||
?> **Basic** [QMK Configurator](newbs_building_firmware_configurator.md) <br>
|
||||
User friendly graphical interfaces, no programming knowledge required.
|
||||
|
||||
?> **Advanced** [Use The Source](newbs.md) <br>
|
||||
More powerful, but harder to use.
|
||||
|
||||
</div>
|
||||
|
||||
## Make It Yours
|
||||
|
||||
QMK has lots of features to explore, and a good deal of reference documentation to dig through. Most features are taken advantage of by modifying your [keymap](keymap.md), and changing the [keycodes](keycodes.md).
|
||||
|
||||
## Need help?
|
||||
|
||||
Check out the [support page](support.md) to see how you can get help using QMK.
|
||||
|
||||
## Give Back
|
||||
|
||||
There are a lot of ways you can contribute to the QMK Community. The easiest way to get started is to use it and spread the word to your friends.
|
||||
|
||||
* Help people out on our forums and chat rooms:
|
||||
* [/r/olkb](https://www.reddit.com/r/olkb/)
|
||||
* [Discord Server](https://discord.gg/Uq7gcHh)
|
||||
* Contribute to our documentation by clicking "Edit This Page" at the bottom
|
||||
* [Translate our documentation into your language](translating.md)
|
||||
* [Report a bug](https://github.com/qmk/qmk_firmware/issues/new/choose)
|
||||
* [Open a Pull Request](contributing.md)
|
298
docs/__capabilities.md
Normal file
298
docs/__capabilities.md
Normal file
@ -0,0 +1,298 @@
|
||||
# Documentation Capabilities
|
||||
|
||||
This page lays out the capabilities used by the QMK Firmware documentation, in order to aid future transitions to other page generators. Focuses mainly on things other than normal Markdown, as it's assumed that markdown generators should still function accordingly.
|
||||
|
||||
## Overall capabilities
|
||||
|
||||
Unrelated to styling, high-level tech.
|
||||
|
||||
* Title anchors -- `:id=some-anchor-name`, used for direct linking to sections
|
||||
* Links to anchors:
|
||||
* Style 1: [early initialization](platformdev_chibios_earlyinit.md?id=board-init)
|
||||
* Style 2: [early initialization](platformdev_chibios_earlyinit.md#board-init)
|
||||
* Links to anchors on the same page, i.e. [Emoji](#emoji)
|
||||
* Specifying CNAME for root domain -- `docs.qmk.fm`
|
||||
* Moved pages, see `index.html`
|
||||
* Text search
|
||||
* Footnotes [like this][1]
|
||||
|
||||
<!-- Comments should not show up -->
|
||||
|
||||
<!-- Nor should
|
||||
multiline
|
||||
|
||||
comments with
|
||||
|
||||
newlines show up -->
|
||||
|
||||
|
||||
### Dividing lines
|
||||
|
||||
---
|
||||
|
||||
<hr>
|
||||
|
||||
<hr/>
|
||||
|
||||
### Images
|
||||
|
||||
![QMK Color Wheel with HSV Values](https://i.imgur.com/vkYVo66.jpg)
|
||||
|
||||
![QMK Light](./public/badge-community-light.svg)
|
||||
![QMK Dark](./public/badge-community-dark.svg)
|
||||
|
||||
<img src="./public/color-wheel.svg" alt="HSV Color Wheel" width="250"/>
|
||||
|
||||
### Lists
|
||||
|
||||
Newlines with `<br>`:
|
||||
|
||||
Line one<br>
|
||||
Line two<br/>
|
||||
Line three
|
||||
|
||||
Nested dotted:
|
||||
|
||||
* The PR is complete and ready to merge
|
||||
* GitHub checks for the PR are green whenever possible
|
||||
* A "red" check may be disregarded by maintainers if the items flagged are unrelated to the change proposed in the PR
|
||||
* Modifications to existing files should not need to add license headers to pass lint, for instance.
|
||||
* If it's not directly related to your PR's functionality, prefer avoiding making a change.
|
||||
|
||||
Nested dashed:
|
||||
|
||||
- The PR is complete and ready to merge
|
||||
- GitHub checks for the PR are green whenever possible
|
||||
- A "red" check may be disregarded by maintainers if the items flagged are unrelated to the change proposed in the PR
|
||||
- Modifications to existing files should not need to add license headers to pass lint, for instance.
|
||||
- If it's not directly related to your PR's functionality, prefer avoiding making a change.
|
||||
|
||||
Nested numbered:
|
||||
|
||||
1. The PR is complete and ready to merge
|
||||
1. GitHub checks for the PR are green whenever possible
|
||||
1. A "red" check may be disregarded by maintainers if the items flagged are unrelated to the change proposed in the PR
|
||||
1. Modifications to existing files should not need to add license headers to pass lint, for instance.
|
||||
1. If it's not directly related to your PR's functionality, prefer avoiding making a change.
|
||||
|
||||
Nested mixed:
|
||||
|
||||
1. Add it to the schema in `data/schemas/keyboards.jsonschema`
|
||||
1. Add a mapping in `data/maps`
|
||||
1. (optional and discouraged) Add code to extract/generate it to:
|
||||
* `lib/python/qmk/info.py`
|
||||
* `lib/python/qmk/cli/generate/config_h.py`
|
||||
* `lib/python/qmk/cli/generate/rules_mk.py`
|
||||
|
||||
### Emoji {#emoji}
|
||||
|
||||
#### Direct:
|
||||
|
||||
👍🎉 First off, thanks for taking the time to read this and contribute! 🎉👍
|
||||
|
||||
#### As colon-name-colon:
|
||||
|
||||
:heavy_check_mark: : works and was tested
|
||||
|
||||
:o: : does not apply
|
||||
|
||||
:x: : not supported by MCU
|
||||
|
||||
### XML Entities
|
||||
|
||||
[`clueboard`](https://github.com/qmk/qmk_firmware/tree/master/keyboards/clueboard) ← This is the organization folder, there's no `rules.mk` file
|
||||
|
||||
1–4
|
||||
|
||||
Command+<code>`</code>
|
||||
|
||||
## Styling
|
||||
|
||||
### CSS-ish
|
||||
|
||||
<b style="font-size:150%">This is 150% of normal sizing, and bold!</b>
|
||||
|
||||
|
||||
### Tables
|
||||
|
||||
| Column A | Column B |
|
||||
|----------|----------|
|
||||
| Left | Right |
|
||||
|
||||
### Indented sections
|
||||
|
||||
> Indent without any sort of marker
|
||||
|
||||
?> Query, this?
|
||||
|
||||
!> Notification, damnit!
|
||||
|
||||
::: info
|
||||
This is an info box.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
This is a tip.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
This is a warning.
|
||||
:::
|
||||
|
||||
::: danger
|
||||
This is a dangerous warning.
|
||||
:::
|
||||
|
||||
::: details
|
||||
This is a details block.
|
||||
:::
|
||||
|
||||
### Keyboard keys
|
||||
|
||||
<kbd>,</kbd>
|
||||
|
||||
<kbd>Right Alt</kbd>+<kbd>Right Shift</kbd>
|
||||
|
||||
1. Click <kbd>File</kbd> > <kbd>New</kbd> > <kbd>Makefile Project with Existing Code</kbd>
|
||||
|
||||
1. Click <kbd><kbd>File</kbd> > <kbd>Preferences ></kbd> > <kbd>Settings</kbd> </kbd>
|
||||
|
||||
1. Hit Ctrl-<code>`</code> (Grave) to bring up the terminal or go to <kbd><kbd>View</kbd> > <kbd>Terminal</kbd></kbd> (command `workbench.action.terminal.toggleTerminal`). A new terminal will be opened if there isn‘t one already.
|
||||
|
||||
This should start the terminal in the workspace's folder (so the `qmk_firmware` folder), and then you can compile your keyboard.
|
||||
|
||||
|
||||
### Code Blocks
|
||||
|
||||
Inline code with tag: <code>test</code>
|
||||
|
||||
Inline code with backticks: `test`
|
||||
|
||||
This is preformatted
|
||||
Indented by 4 spaces
|
||||
The letters lined up
|
||||
|
||||
```c
|
||||
int c_code(void) {
|
||||
return -1;
|
||||
}
|
||||
```
|
||||
|
||||
```makefile
|
||||
ifeq ($(BUILD),)
|
||||
CHUNDER_REQUIRED = yes
|
||||
endif
|
||||
```
|
||||
|
||||
```python
|
||||
from pathlib import Path
|
||||
|
||||
p = Path('/path/to/qmk_firmware')
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"a": "b",
|
||||
"c": 4,
|
||||
"d": {
|
||||
"e": [
|
||||
0, 1, 2, 3
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```diff
|
||||
#undef RGBLIGHT_LED_COUNT
|
||||
+#undef RGBLIGHT_EFFECT_STATIC_GRADIENT
|
||||
+#undef RGBLIGHT_EFFECT_RAINBOW_SWIRL
|
||||
#define RGBLIGHT_LED_COUNT 12
|
||||
#define RGBLIGHT_HUE_STEP 8
|
||||
#define RGBLIGHT_SAT_STEP 8
|
||||
```
|
||||
|
||||
Indented code as part of a list:
|
||||
|
||||
* [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) (recommended GUI)
|
||||
* [Teensy Loader](https://www.pjrc.com/teensy/loader.html)
|
||||
* [Teensy Loader Command Line](https://www.pjrc.com/teensy/loader_cli.html) / `:teensy` target in QMK (recommended command line)
|
||||
```
|
||||
teensy_loader_cli -v -mmcu=<mcu> <filename>
|
||||
```
|
||||
|
||||
|
||||
### Sub/Superscript
|
||||
|
||||
<sub>This is subscripted, apparently.</sub>
|
||||
|
||||
<sup>This is superscripted, apparently.</sup>
|
||||
|
||||
I<sup>2</sup>C
|
||||
|
||||
T<sub>0H</sub>, T<sub>0L</sub>
|
||||
|
||||
### Tabs
|
||||
|
||||
Tabs are based on section headers, with `**` enclosing the tab title.
|
||||
|
||||
<!-- tabs:start -->
|
||||
|
||||
#### ** Tab one **
|
||||
|
||||
Content one
|
||||
|
||||
<!-- tabs:start -->
|
||||
|
||||
##### ** Nested one **
|
||||
|
||||
Nested content one
|
||||
|
||||
##### ** Nested two **
|
||||
|
||||
Nested content two
|
||||
|
||||
<!-- tabs:end -->
|
||||
|
||||
#### ** Tab two **
|
||||
|
||||
Content two
|
||||
|
||||
#### ** Tab three **
|
||||
|
||||
Content three
|
||||
|
||||
<!-- tabs:end -->
|
||||
|
||||
::::tabs
|
||||
=== tab a
|
||||
a content 2
|
||||
=== tab b
|
||||
b content 2
|
||||
=== tab c
|
||||
:::tabs
|
||||
== nested tab a
|
||||
nested a content 2
|
||||
== nested tab b
|
||||
nested b content 2
|
||||
:::
|
||||
::::
|
||||
|
||||
## Details sections
|
||||
|
||||
Expandable:
|
||||
|
||||
<details>
|
||||
<summary>Some summary text that shows up before expanding</summary>
|
||||
|
||||
!> Embedded notification!
|
||||
|
||||
This is some inner content.
|
||||
</details>
|
||||
|
||||
## Embed
|
||||
|
||||
[example embed](__capabilities_inc.md ':include')
|
||||
|
||||
<!--@include: ./__capabilities_inc.md-->
|
||||
|
||||
[1]: https://en.wikipedia.org/wiki/Eclipse_(software)
|
1
docs/__capabilities_inc.md
Normal file
1
docs/__capabilities_inc.md
Normal file
@ -0,0 +1 @@
|
||||
Lorem ipsum dolor sit amet.
|
75
docs/_aliases.json
Normal file
75
docs/_aliases.json
Normal file
@ -0,0 +1,75 @@
|
||||
{
|
||||
"/adding_a_keyboard_to_qmk": "/hardware_keyboard_guidelines",
|
||||
"/build_environment_setup": "/newbs_getting_started",
|
||||
"/cli_dev_configuration": "/cli_configuration",
|
||||
"/dynamic_macros": "/feature_dynamic_macros",
|
||||
"/feature_common_shortcuts": "/feature_advanced_keycodes",
|
||||
"/flashing_bootloadhid": "/flashing",
|
||||
"/getting_started_build_tools": "/newbs_getting_started",
|
||||
"/getting_started_getting_help": "/support",
|
||||
"/glossary": "/reference_glossary",
|
||||
"/key_lock": "/feature_key_lock",
|
||||
"/make_instructions": "/getting_started_make_guide",
|
||||
"/python_development": "/cli_development",
|
||||
"/space_cadet_shift": "/feature_space_cadet_shift",
|
||||
"/tap_dance": "/feature_tap_dance",
|
||||
"/tutorial": "/newbs",
|
||||
"/unicode": "/feature_unicode",
|
||||
|
||||
"/adc_driver": "/drivers/adc",
|
||||
"/apa102_driver": "/drivers/apa102",
|
||||
"/audio_driver": "/drivers/audio",
|
||||
"/eeprom_driver": "/drivers/eeprom",
|
||||
"/feature_audio": "/features/audio",
|
||||
"/feature_auto_shift": "/features/auto_shift",
|
||||
"/feature_autocorrect": "/features/autocorrect",
|
||||
"/feature_backlight": "/features/backlight",
|
||||
"/feature_bluetooth": "/features/bluetooth",
|
||||
"/feature_bootmagic": "/features/bootmagic",
|
||||
"/feature_caps_word": "/features/caps_word",
|
||||
"/feature_combo": "/features/combo",
|
||||
"/feature_command": "/features/command",
|
||||
"/feature_digitizer": "/features/digitizer",
|
||||
"/feature_dip_switch": "/features/dip_switch",
|
||||
"/feature_dynamic_macros": "/features/dynamic_macros",
|
||||
"/feature_encoders": "/features/encoders",
|
||||
"/feature_grave_esc": "/features/grave_esc",
|
||||
"/feature_haptic_feedback": "/features/haptic_feedback",
|
||||
"/feature_hd44780": "/features/hd44780",
|
||||
"/feature_joystick": "/features/joystick",
|
||||
"/feature_key_lock": "/features/key_lock",
|
||||
"/feature_key_overrides": "/features/key_overrides",
|
||||
"/feature_leader_key": "/features/leader_key",
|
||||
"/feature_led_indicators": "/features/led_indicators",
|
||||
"/feature_led_matrix": "/features/led_matrix",
|
||||
"/feature_midi": "/features/midi",
|
||||
"/feature_mouse_keys": "/features/mouse_keys",
|
||||
"/feature_oled_driver": "/features/oled_driver",
|
||||
"/feature_os_detection": "/features/os_detection",
|
||||
"/feature_pointing_device": "/features/pointing_device",
|
||||
"/feature_programmable_button": "/features/programmable_button",
|
||||
"/feature_ps2_mouse": "/features/ps2_mouse",
|
||||
"/feature_rawhid": "/features/rawhid",
|
||||
"/feature_repeat_key": "/features/repeat_key",
|
||||
"/feature_rgb_matrix": "/features/rgb_matrix",
|
||||
"/feature_rgblight": "/features/rgblight",
|
||||
"/feature_secure": "/features/secure",
|
||||
"/feature_send_string": "/features/send_string",
|
||||
"/feature_sequencer": "/features/sequencer",
|
||||
"/feature_space_cadet": "/features/space_cadet",
|
||||
"/feature_split_keyboard": "/features/split_keyboard",
|
||||
"/feature_st7565": "/features/st7565",
|
||||
"/feature_stenography": "/features/stenography",
|
||||
"/feature_swap_hands": "/features/swap_hands",
|
||||
"/feature_tap_dance": "/features/tap_dance",
|
||||
"/feature_tri_layer": "/features/tri_layer",
|
||||
"/feature_unicode": "/features/unicode",
|
||||
"/feature_wpm": "/features/wpm",
|
||||
"/flash_driver": "/drivers/flash",
|
||||
"/gpio_control": "/drivers/gpio",
|
||||
"/i2c_driver": "/drivers/i2c",
|
||||
"/serial_driver": "/drivers/serial",
|
||||
"/spi_driver": "/drivers/spi",
|
||||
"/uart_driver": "/drivers/uart",
|
||||
"/ws2812_driver": "/drivers/ws2812"
|
||||
}
|
@ -1,4 +0,0 @@
|
||||
- Translations
|
||||
- [:uk: English](/)
|
||||
- [:cn: 简体中文](/zh-cn/)
|
||||
- [:jp: 日本語](/ja/)
|
304
docs/_sidebar.json
Normal file
304
docs/_sidebar.json
Normal file
@ -0,0 +1,304 @@
|
||||
[
|
||||
{
|
||||
"text": "Tutorial",
|
||||
"items": [
|
||||
{ "text": "Introduction", "link": "/newbs" },
|
||||
{ "text": "Setup", "link": "/newbs_getting_started" },
|
||||
{ "text": "Building Your First Firmware", "link": "/newbs_building_firmware" },
|
||||
{ "text": "Flashing Firmware", "link": "/newbs_flashing" },
|
||||
{ "text": "Getting Help/Support", "link": "/support" },
|
||||
{ "text": "External Userspace", "link": "/newbs_external_userspace" },
|
||||
{ "text": "Other Resources", "link": "/newbs_learn_more_resources" },
|
||||
{ "text": "Syllabus", "link": "/syllabus" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "FAQs",
|
||||
"items": [
|
||||
{ "text": "General FAQ", "link": "/faq_general" },
|
||||
{ "text": "Build/Compile QMK", "link": "/faq_build" },
|
||||
{ "text": "Troubleshooting QMK", "link": "/faq_misc" },
|
||||
{ "text": "Debugging QMK", "link": "/faq_debug" },
|
||||
{ "text": "Keymap FAQ", "link": "/faq_keymap" },
|
||||
{ "text": "Squeezing Space from AVR", "link": "/squeezing_avr" },
|
||||
{ "text": "Glossary", "link": "/reference_glossary" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Configurator",
|
||||
"items": [
|
||||
{ "text": "Overview", "link": "/newbs_building_firmware_configurator" },
|
||||
{ "text": "Step by Step", "link": "/configurator_step_by_step" },
|
||||
{ "text": "Troubleshooting", "link": "/configurator_troubleshooting" },
|
||||
{ "text": "Architecture", "link": "/configurator_architecture" },
|
||||
{
|
||||
"text": "QMK API",
|
||||
"items": [
|
||||
{ "text": "Overview", "link": "/api_overview" },
|
||||
{ "text": "API Documentation", "link": "/api_docs" },
|
||||
{ "text": "Keyboard Support", "link": "/reference_configurator_support" },
|
||||
{ "text": "Adding Default Keymaps", "link": "/configurator_default_keymaps" }
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "CLI",
|
||||
"items": [
|
||||
{ "text": "Overview", "link": "/cli" },
|
||||
{ "text": "Configuration", "link": "/cli_configuration" },
|
||||
{ "text": "Commands", "link": "/cli_commands" },
|
||||
{ "text": "Tab Completion", "link": "/cli_tab_complete" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Using QMK",
|
||||
"items": [
|
||||
{
|
||||
"text": "Guides",
|
||||
"items": [
|
||||
{ "text": "Customizing Functionality", "link": "/custom_quantum_functions" },
|
||||
{ "text": "Driver Installation with Zadig", "link": "/driver_installation_zadig" },
|
||||
{ "text": "Keymap Overview", "link": "/keymap" },
|
||||
{
|
||||
"text": "Development Environments",
|
||||
"items": [{ "text": "Docker Guide", "link": "/getting_started_docker" }]
|
||||
},
|
||||
{ "text": "Flashing", "link": "/flashing" },
|
||||
{
|
||||
"text": "IDEs",
|
||||
"items": [
|
||||
{ "text": "Using Eclipse with QMK", "link": "/other_eclipse" },
|
||||
{ "text": "Using VSCode with QMK", "link": "/other_vscode" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Git Best Practices",
|
||||
"items": [
|
||||
{ "text": "Introduction", "link": "/newbs_git_best_practices" },
|
||||
{ "text": "Your Fork", "link": "/newbs_git_using_your_master_branch" },
|
||||
{ "text": "Merge Conflicts", "link": "/newbs_git_resolving_merge_conflicts" },
|
||||
{ "text": "Fixing Your Branch", "link": "/newbs_git_resynchronize_a_branch" }
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Simple Keycodes",
|
||||
"items": [
|
||||
{ "text": "Full List", "link": "/keycodes" },
|
||||
{ "text": "Basic Keycodes", "link": "/keycodes_basic" },
|
||||
{ "text": "Language-Specific Keycodes", "link": "/reference_keymap_extras" },
|
||||
{ "text": "Modifier Keys", "link": "/feature_advanced_keycodes" },
|
||||
{ "text": "Quantum Keycodes", "link": "/quantum_keycodes" },
|
||||
{ "text": "Magic Keycodes", "link": "/keycodes_magic" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Advanced Keycodes",
|
||||
"items": [
|
||||
{ "text": "Command", "link": "/features/command" },
|
||||
{ "text": "Dynamic Macros", "link": "/features/dynamic_macros" },
|
||||
{ "text": "Grave Escape", "link": "/features/grave_esc" },
|
||||
{ "text": "Leader Key", "link": "/features/leader_key" },
|
||||
{ "text": "Mod-Tap", "link": "/mod_tap" },
|
||||
{ "text": "Macros", "link": "/feature_macros" },
|
||||
{ "text": "Mouse Keys", "link": "/features/mouse_keys" },
|
||||
{ "text": "Programmable Button", "link": "/features/programmable_button" },
|
||||
{ "text": "Repeat Key", "link": "/features/repeat_key" },
|
||||
{ "text": "Space Cadet Shift", "link": "/features/space_cadet" },
|
||||
{ "text": "US ANSI Shifted Keys", "link": "/keycodes_us_ansi_shifted" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Software Features",
|
||||
"items": [
|
||||
{ "text": "Auto Shift", "link": "/features/auto_shift" },
|
||||
{ "text": "Autocorrect", "link": "/features/autocorrect" },
|
||||
{ "text": "Caps Word", "link": "/features/caps_word" },
|
||||
{ "text": "Combos", "link": "/features/combo" },
|
||||
{ "text": "Debounce API", "link": "/feature_debounce_type" },
|
||||
{ "text": "Digitizer", "link": "/features/digitizer" },
|
||||
{ "text": "EEPROM", "link": "/feature_eeprom" },
|
||||
{ "text": "Key Lock", "link": "/features/key_lock" },
|
||||
{ "text": "Key Overrides", "link": "/features/key_overrides" },
|
||||
{ "text": "Layers", "link": "/feature_layers" },
|
||||
{ "text": "One Shot Keys", "link": "/one_shot_keys" },
|
||||
{ "text": "OS Detection", "link": "/features/os_detection" },
|
||||
{ "text": "Raw HID", "link": "/features/rawhid" },
|
||||
{ "text": "Secure", "link": "/features/secure" },
|
||||
{ "text": "Send String", "link": "/features/send_string" },
|
||||
{ "text": "Sequencer", "link": "/features/sequencer" },
|
||||
{ "text": "Swap Hands", "link": "/features/swap_hands" },
|
||||
{ "text": "Tap Dance", "link": "/features/tap_dance" },
|
||||
{ "text": "Tap-Hold Configuration", "link": "/tap_hold" },
|
||||
{ "text": "Tri Layer", "link": "/features/tri_layer" },
|
||||
{ "text": "Unicode", "link": "/features/unicode" },
|
||||
{ "text": "Userspace", "link": "/feature_userspace" },
|
||||
{ "text": "WPM Calculation", "link": "/features/wpm" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Hardware Features",
|
||||
"items": [
|
||||
{
|
||||
"text": "Displays",
|
||||
"items": [
|
||||
{
|
||||
"text": "Quantum Painter",
|
||||
"link": "quantum_painter",
|
||||
"items": [
|
||||
{ "text": "Quantum Painter LVGL Integration", "link": "/quantum_painter_lvgl" }
|
||||
]
|
||||
},
|
||||
{ "text": "HD44780 LCD Driver", "link": "/features/hd44780" },
|
||||
{ "text": "ST7565 LCD Driver", "link": "/features/st7565" },
|
||||
{ "text": "OLED Driver", "link": "/features/oled_driver" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Lighting",
|
||||
"items": [
|
||||
{ "text": "Backlight", "link": "/features/backlight" },
|
||||
{ "text": "LED Matrix", "link": "/features/led_matrix" },
|
||||
{ "text": "RGB Lighting", "link": "/features/rgblight" },
|
||||
{ "text": "RGB Matrix", "link": "/features/rgb_matrix" }
|
||||
]
|
||||
},
|
||||
{ "text": "Audio", "link": "/features/audio" },
|
||||
{ "text": "Bluetooth", "link": "/features/bluetooth" },
|
||||
{ "text": "Bootmagic Lite", "link": "/features/bootmagic" },
|
||||
{ "text": "Converters", "link": "/feature_converters" },
|
||||
{ "text": "Custom Matrix", "link": "/custom_matrix" },
|
||||
{ "text": "DIP Switch", "link": "/features/dip_switch" },
|
||||
{ "text": "Encoders", "link": "/features/encoders" },
|
||||
{ "text": "Haptic Feedback", "link": "/features/haptic_feedback" },
|
||||
{ "text": "Joystick", "link": "/features/joystick" },
|
||||
{ "text": "LED Indicators", "link": "/features/led_indicators" },
|
||||
{ "text": "MIDI", "link": "/features/midi" },
|
||||
{ "text": "Pointing Device", "link": "/features/pointing_device" },
|
||||
{ "text": "PS/2 Mouse", "link": "/features/ps2_mouse" },
|
||||
{ "text": "Split Keyboard", "link": "/features/split_keyboard" },
|
||||
{ "text": "Stenography", "link": "/features/stenography" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Keyboard Building",
|
||||
"items": [
|
||||
{ "text": "Easy Maker for One Offs", "link": "/easy_maker" },
|
||||
{ "text": "Porting Keyboards", "link": "/porting_your_keyboard_to_qmk" },
|
||||
{ "text": "Hand Wiring Guide", "link": "/hand_wire" },
|
||||
{ "text": "ISP Flashing Guide", "link": "/isp_flashing_guide" }
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Developing QMK",
|
||||
"items": [
|
||||
{ "text": "PR Checklist", "link": "/pr_checklist" },
|
||||
{
|
||||
"text": "Breaking Changes",
|
||||
"items": [
|
||||
{ "text": "Overview", "link": "/breaking_changes" },
|
||||
{ "text": "My Pull Request Was Flagged", "link": "/breaking_changes_instructions" },
|
||||
{
|
||||
"text": "Most Recent ChangeLog",
|
||||
"link": "/ChangeLog/20240526"
|
||||
},
|
||||
{ "text": "Past Breaking Changes", "link": "/breaking_changes_history" },
|
||||
{ "text": "Deprecation Policy", "link": "/support_deprecation_policy" }
|
||||
]
|
||||
},
|
||||
|
||||
{
|
||||
"text": "C Development",
|
||||
"items": [
|
||||
{ "text": "ARM Debugging Guide", "link": "/arm_debugging" },
|
||||
{ "text": "Coding Conventions", "link": "/coding_conventions_c" },
|
||||
{ "text": "Compatible Microcontrollers", "link": "/compatible_microcontrollers" },
|
||||
{
|
||||
"text": "Drivers",
|
||||
"link": "hardware_drivers",
|
||||
"items": [
|
||||
{ "text": "ADC Driver", "link": "/drivers/adc" },
|
||||
{ "text": "APA102 Driver", "link": "/drivers/apa102" },
|
||||
{ "text": "Audio Driver", "link": "/drivers/audio" },
|
||||
{ "text": "EEPROM Driver", "link": "/drivers/eeprom" },
|
||||
{ "text": "Flash Driver", "link": "/drivers/flash" },
|
||||
{ "text": "I2C Driver", "link": "/drivers/i2c" },
|
||||
{ "text": "'serial' Driver", "link": "/drivers/serial" },
|
||||
{ "text": "SPI Driver", "link": "/drivers/spi" },
|
||||
{ "text": "UART Driver", "link": "/drivers/uart" },
|
||||
{ "text": "WS2812 Driver", "link": "/drivers/ws2812" }
|
||||
]
|
||||
},
|
||||
{ "text": "GPIO Controls", "link": "/drivers/gpio" },
|
||||
{ "text": "Keyboard Guidelines", "link": "/hardware_keyboard_guidelines" }
|
||||
]
|
||||
},
|
||||
|
||||
{
|
||||
"text": "Python Development",
|
||||
"items": [
|
||||
{ "text": "Coding Conventions", "link": "/coding_conventions_python" },
|
||||
{ "text": "QMK CLI Development", "link": "/cli_development" }
|
||||
]
|
||||
},
|
||||
|
||||
{
|
||||
"text": "Configurator Development",
|
||||
"items": [
|
||||
{
|
||||
"text": "QMK API",
|
||||
"items": [
|
||||
{ "text": "Development Environment", "link": "/api_development_environment" },
|
||||
{ "text": "Architecture Overview", "link": "/api_development_overview" }
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
{
|
||||
"text": "Hardware Platform Development",
|
||||
"items": [
|
||||
{
|
||||
"text": "Arm/ChibiOS",
|
||||
"items": [
|
||||
{ "text": "Selecting an MCU", "link": "/platformdev_selecting_arm_mcu" },
|
||||
{ "text": "Early initialization", "link": "/platformdev_chibios_earlyinit" },
|
||||
{ "text": "Raspberry Pi RP2040", "link": "/platformdev_rp2040" },
|
||||
{ "text": "Proton C", "link": "/platformdev_proton_c" },
|
||||
{ "text": "WeAct Blackpill F4x1", "link": "/platformdev_blackpill_f4x1" }
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
{
|
||||
"text": "QMK Reference",
|
||||
"items": [
|
||||
{ "text": "Contributing to QMK", "link": "/contributing" },
|
||||
{ "text": "Config Options", "link": "/config_options" },
|
||||
{ "text": "Data Driven Configuration", "link": "/data_driven_config" },
|
||||
{ "text": "Make Documentation", "link": "/getting_started_make_guide" },
|
||||
{ "text": "Documentation Best Practices", "link": "/documentation_best_practices" },
|
||||
{ "text": "Documentation Templates", "link": "/documentation_templates" },
|
||||
{ "text": "Community Layouts", "link": "/feature_layouts" },
|
||||
{ "text": "Unit Testing", "link": "/unit_testing" },
|
||||
{ "text": "Useful Functions", "link": "/ref_functions" },
|
||||
{ "text": "info.json Format", "link": "/reference_info_json" }
|
||||
]
|
||||
},
|
||||
|
||||
{
|
||||
"text": "For a Deeper Understanding",
|
||||
"items": [
|
||||
{ "text": "How Keyboards Work", "link": "/how_keyboards_work" },
|
||||
{ "text": "How a Matrix Works", "link": "/how_a_matrix_works" },
|
||||
{ "text": "Understanding QMK", "link": "/understanding_qmk" }
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
204
docs/_summary.md
204
docs/_summary.md
@ -1,204 +0,0 @@
|
||||
* Tutorial
|
||||
* [Introduction](newbs.md)
|
||||
* [Setup](newbs_getting_started.md)
|
||||
* [Building Your First Firmware](newbs_building_firmware.md)
|
||||
* [Flashing Firmware](newbs_flashing.md)
|
||||
* [Getting Help/Support](support.md)
|
||||
* [External Userspace](newbs_external_userspace.md)
|
||||
* [Other Resources](newbs_learn_more_resources.md)
|
||||
* [Syllabus](syllabus.md)
|
||||
|
||||
* FAQs
|
||||
* [General FAQ](faq_general.md)
|
||||
* [Build/Compile QMK](faq_build.md)
|
||||
* [Troubleshooting QMK](faq_misc.md)
|
||||
* [Debugging QMK](faq_debug.md)
|
||||
* [Keymap FAQ](faq_keymap.md)
|
||||
* [Squeezing Space from AVR](squeezing_avr.md)
|
||||
* [Glossary](reference_glossary.md)
|
||||
|
||||
* Configurator
|
||||
* [Overview](newbs_building_firmware_configurator.md)
|
||||
* [Step by Step](configurator_step_by_step.md)
|
||||
* [Troubleshooting](configurator_troubleshooting.md)
|
||||
* [Architecture](configurator_architecture.md)
|
||||
* QMK API
|
||||
* [Overview](api_overview.md)
|
||||
* [API Documentation](api_docs.md)
|
||||
* [Keyboard Support](reference_configurator_support.md)
|
||||
* [Adding Default Keymaps](configurator_default_keymaps.md)
|
||||
|
||||
* CLI
|
||||
* [Overview](cli.md)
|
||||
* [Configuration](cli_configuration.md)
|
||||
* [Commands](cli_commands.md)
|
||||
* [Tab Completion](cli_tab_complete.md)
|
||||
|
||||
* Using QMK
|
||||
* Guides
|
||||
* [Customizing Functionality](custom_quantum_functions.md)
|
||||
* [Driver Installation with Zadig](driver_installation_zadig.md)
|
||||
* [Keymap Overview](keymap.md)
|
||||
* Development Environments
|
||||
* [Docker Guide](getting_started_docker.md)
|
||||
* Flashing
|
||||
* [Flashing](flashing.md)
|
||||
* [Flashing ATmega32A (ps2avrgb)](flashing_bootloadhid.md)
|
||||
* IDEs
|
||||
* [Using Eclipse with QMK](other_eclipse.md)
|
||||
* [Using VSCode with QMK](other_vscode.md)
|
||||
* Git Best Practices
|
||||
* [Introduction](newbs_git_best_practices.md)
|
||||
* [Your Fork](newbs_git_using_your_master_branch.md)
|
||||
* [Merge Conflicts](newbs_git_resolving_merge_conflicts.md)
|
||||
* [Fixing Your Branch](newbs_git_resynchronize_a_branch.md)
|
||||
|
||||
* Simple Keycodes
|
||||
* [Full List](keycodes.md)
|
||||
* [Basic Keycodes](keycodes_basic.md)
|
||||
* [Language-Specific Keycodes](reference_keymap_extras.md)
|
||||
* [Modifier Keys](feature_advanced_keycodes.md)
|
||||
* [Quantum Keycodes](quantum_keycodes.md)
|
||||
* [Magic Keycodes](keycodes_magic.md)
|
||||
|
||||
* Advanced Keycodes
|
||||
* [Command](feature_command.md)
|
||||
* [Dynamic Macros](feature_dynamic_macros.md)
|
||||
* [Grave Escape](feature_grave_esc.md)
|
||||
* [Leader Key](feature_leader_key.md)
|
||||
* [Mod-Tap](mod_tap.md)
|
||||
* [Macros](feature_macros.md)
|
||||
* [Mouse Keys](feature_mouse_keys.md)
|
||||
* [Programmable Button](feature_programmable_button.md)
|
||||
* [Repeat Key](feature_repeat_key.md)
|
||||
* [Space Cadet Shift](feature_space_cadet.md)
|
||||
* [US ANSI Shifted Keys](keycodes_us_ansi_shifted.md)
|
||||
|
||||
* Software Features
|
||||
* [Auto Shift](feature_auto_shift.md)
|
||||
* [Autocorrect](feature_autocorrect.md)
|
||||
* [Caps Word](feature_caps_word.md)
|
||||
* [Combos](feature_combo.md)
|
||||
* [Debounce API](feature_debounce_type.md)
|
||||
* [Digitizer](feature_digitizer.md)
|
||||
* [EEPROM](feature_eeprom.md)
|
||||
* [Key Lock](feature_key_lock.md)
|
||||
* [Key Overrides](feature_key_overrides.md)
|
||||
* [Layers](feature_layers.md)
|
||||
* [One Shot Keys](one_shot_keys.md)
|
||||
* [OS Detection](feature_os_detection.md)
|
||||
* [Raw HID](feature_rawhid.md)
|
||||
* [Secure](feature_secure.md)
|
||||
* [Send String](feature_send_string.md)
|
||||
* [Sequencer](feature_sequencer.md)
|
||||
* [Swap Hands](feature_swap_hands.md)
|
||||
* [Tap Dance](feature_tap_dance.md)
|
||||
* [Tap-Hold Configuration](tap_hold.md)
|
||||
* [Tri Layer](feature_tri_layer.md)
|
||||
* [Unicode](feature_unicode.md)
|
||||
* [Userspace](feature_userspace.md)
|
||||
* [WPM Calculation](feature_wpm.md)
|
||||
|
||||
* Hardware Features
|
||||
* Displays
|
||||
* [Quantum Painter](quantum_painter.md)
|
||||
* [Quantum Painter LVGL Integration](quantum_painter_lvgl.md)
|
||||
* [HD44780 LCD Driver](feature_hd44780.md)
|
||||
* [ST7565 LCD Driver](feature_st7565.md)
|
||||
* [OLED Driver](feature_oled_driver.md)
|
||||
* Lighting
|
||||
* [Backlight](feature_backlight.md)
|
||||
* [LED Matrix](feature_led_matrix.md)
|
||||
* [RGB Lighting](feature_rgblight.md)
|
||||
* [RGB Matrix](feature_rgb_matrix.md)
|
||||
* [Audio](feature_audio.md)
|
||||
* [Bluetooth](feature_bluetooth.md)
|
||||
* [Bootmagic Lite](feature_bootmagic.md)
|
||||
* [Converters](feature_converters.md)
|
||||
* [Custom Matrix](custom_matrix.md)
|
||||
* [DIP Switch](feature_dip_switch.md)
|
||||
* [Encoders](feature_encoders.md)
|
||||
* [Haptic Feedback](feature_haptic_feedback.md)
|
||||
* [Joystick](feature_joystick.md)
|
||||
* [LED Indicators](feature_led_indicators.md)
|
||||
* [MIDI](feature_midi.md)
|
||||
* [Pointing Device](feature_pointing_device.md)
|
||||
* [PS/2 Mouse](feature_ps2_mouse.md)
|
||||
* [Split Keyboard](feature_split_keyboard.md)
|
||||
* [Stenography](feature_stenography.md)
|
||||
|
||||
* Keyboard Building
|
||||
* [Easy Maker for One Offs](easy_maker.md)
|
||||
* [Porting Keyboards](porting_your_keyboard_to_qmk.md)
|
||||
* [Hand Wiring Guide](hand_wire.md)
|
||||
* [ISP Flashing Guide](isp_flashing_guide.md)
|
||||
|
||||
* Developing QMK
|
||||
* [PR Checklist](pr_checklist.md)
|
||||
* Breaking Changes
|
||||
* [Overview](breaking_changes.md)
|
||||
* [My Pull Request Was Flagged](breaking_changes_instructions.md)
|
||||
* [Most Recent ChangeLog](ChangeLog/20240225.md "QMK v0.24.0 - 2024 Feb 25")
|
||||
* [Past Breaking Changes](breaking_changes_history.md)
|
||||
|
||||
* C Development
|
||||
* [ARM Debugging Guide](arm_debugging.md)
|
||||
* [Coding Conventions](coding_conventions_c.md)
|
||||
* [Compatible Microcontrollers](compatible_microcontrollers.md)
|
||||
* [Drivers](hardware_drivers.md)
|
||||
* [ADC Driver](adc_driver.md)
|
||||
* [APA102 Driver](apa102_driver.md)
|
||||
* [Audio Driver](audio_driver.md)
|
||||
* [I2C Driver](i2c_driver.md)
|
||||
* [SPI Driver](spi_driver.md)
|
||||
* [WS2812 Driver](ws2812_driver.md)
|
||||
* [EEPROM Driver](eeprom_driver.md)
|
||||
* [Flash Driver](flash_driver.md)
|
||||
* ['serial' Driver](serial_driver.md)
|
||||
* [UART Driver](uart_driver.md)
|
||||
* [GPIO Controls](gpio_control.md)
|
||||
* [Keyboard Guidelines](hardware_keyboard_guidelines.md)
|
||||
|
||||
* Python Development
|
||||
* [Coding Conventions](coding_conventions_python.md)
|
||||
* [QMK CLI Development](cli_development.md)
|
||||
|
||||
* Configurator Development
|
||||
* QMK API
|
||||
* [Development Environment](api_development_environment.md)
|
||||
* [Architecture Overview](api_development_overview.md)
|
||||
|
||||
* Hardware Platform Development
|
||||
* Arm/ChibiOS
|
||||
* [Selecting an MCU](platformdev_selecting_arm_mcu.md)
|
||||
* [Early initialization](platformdev_chibios_earlyinit.md)
|
||||
* [Raspberry Pi RP2040](platformdev_rp2040.md)
|
||||
* [Proton C](platformdev_proton_c.md)
|
||||
* [WeAct Blackpill F4x1](platformdev_blackpill_f4x1.md)
|
||||
|
||||
* QMK Reference
|
||||
* [Contributing to QMK](contributing.md)
|
||||
* [Translating the QMK Docs](translating.md)
|
||||
* [Config Options](config_options.md)
|
||||
* [Data Driven Configuration](data_driven_config.md)
|
||||
* [Make Documentation](getting_started_make_guide.md)
|
||||
* [Documentation Best Practices](documentation_best_practices.md)
|
||||
* [Documentation Templates](documentation_templates.md)
|
||||
* [Community Layouts](feature_layouts.md)
|
||||
* [Unit Testing](unit_testing.md)
|
||||
* [Useful Functions](ref_functions.md)
|
||||
* [info.json Format](reference_info_json.md)
|
||||
|
||||
* For a Deeper Understanding
|
||||
* [How Keyboards Work](how_keyboards_work.md)
|
||||
* [How a Matrix Works](how_a_matrix_works.md)
|
||||
* [Understanding QMK](understanding_qmk.md)
|
||||
|
||||
* QMK Internals (In Progress)
|
||||
* [Defines](internals/defines.md)
|
||||
* [Input Callback Reg](internals/input_callback_reg.md)
|
||||
* [Midi Device](internals/midi_device.md)
|
||||
* [Midi Device Setup Process](internals/midi_device_setup_process.md)
|
||||
* [Midi Util](internals/midi_util.md)
|
||||
* [Send Functions](internals/send_functions.md)
|
||||
* [Sysex Tools](internals/sysex_tools.md)
|
@ -1,173 +0,0 @@
|
||||
# ADC Driver
|
||||
|
||||
QMK can leverage the Analog-to-Digital Converter (ADC) on supported MCUs to measure voltages on certain pins. This can be useful for implementing things such as battery level indicators for Bluetooth keyboards, or volume controls using a potentiometer, as opposed to a [rotary encoder](feature_encoders.md).
|
||||
|
||||
This driver currently supports both AVR and a limited selection of ARM devices. The values returned are 10-bit integers (0-1023) mapped between 0V and VCC (usually 5V or 3.3V for AVR, 3.3V only for ARM), however on ARM there is more flexibility in control of operation through `#define`s if you need more precision.
|
||||
|
||||
## Usage
|
||||
|
||||
To use this driver, add the following to your `rules.mk`:
|
||||
|
||||
```make
|
||||
ANALOG_DRIVER_REQUIRED = yes
|
||||
```
|
||||
|
||||
Then place this include at the top of your code:
|
||||
|
||||
```c
|
||||
#include "analog.h"
|
||||
```
|
||||
|
||||
## Channels
|
||||
|
||||
### AVR
|
||||
|
||||
|Channel|AT90USB64/128|ATmega16/32U4|ATmega32A|ATmega328/P|
|
||||
|-------|-------------|-------------|---------|----------|
|
||||
|0 |`F0` |`F0` |`A0` |`C0` |
|
||||
|1 |`F1` |`F1` |`A1` |`C1` |
|
||||
|2 |`F2` | |`A2` |`C2` |
|
||||
|3 |`F3` | |`A3` |`C3` |
|
||||
|4 |`F4` |`F4` |`A4` |`C4` |
|
||||
|5 |`F5` |`F5` |`A5` |`C5` |
|
||||
|6 |`F6` |`F6` |`A6` |* |
|
||||
|7 |`F7` |`F7` |`A7` |* |
|
||||
|8 | |`D4` | | |
|
||||
|9 | |`D6` | | |
|
||||
|10 | |`D7` | | |
|
||||
|11 | |`B4` | | |
|
||||
|12 | |`B5` | | |
|
||||
|13 | |`B6` | | |
|
||||
|
||||
<sup>\* The ATmega328/P possesses two extra ADC channels; however, they are not present on the DIP pinout, and are not shared with GPIO pins. You can use `adc_read()` directly to gain access to these.</sup>
|
||||
|
||||
### ARM
|
||||
|
||||
#### STM32
|
||||
|
||||
Note that some of these pins are doubled-up on ADCs with the same channel. This is because the pins can be used for either ADC.
|
||||
|
||||
Also note that the F0 and F3 use different numbering schemes. The F0 has a single ADC and the channels are 0-indexed, whereas the F3 has 4 ADCs and the channels are 1-indexed. This is because the F0 uses the `ADCv1` implementation of the ADC, whereas the F3 uses the `ADCv3` implementation.
|
||||
|
||||
|ADC|Channel|STM32F0xx|STM32F1xx|STM32F3xx|STM32F4xx|
|
||||
|---|-------|---------|---------|---------|---------|
|
||||
|1 |0 |`A0` |`A0` | |`A0` |
|
||||
|1 |1 |`A1` |`A1` |`A0` |`A1` |
|
||||
|1 |2 |`A2` |`A2` |`A1` |`A2` |
|
||||
|1 |3 |`A3` |`A3` |`A2` |`A3` |
|
||||
|1 |4 |`A4` |`A4` |`A3` |`A4` |
|
||||
|1 |5 |`A5` |`A5` |`F4` |`A5` |
|
||||
|1 |6 |`A6` |`A6` |`C0` |`A6` |
|
||||
|1 |7 |`A7` |`A7` |`C1` |`A7` |
|
||||
|1 |8 |`B0` |`B0` |`C2` |`B0` |
|
||||
|1 |9 |`B1` |`B1` |`C3` |`B1` |
|
||||
|1 |10 |`C0` |`C0` |`F2` |`C0` |
|
||||
|1 |11 |`C1` |`C1` | |`C1` |
|
||||
|1 |12 |`C2` |`C2` | |`C2` |
|
||||
|1 |13 |`C3` |`C3` | |`C3` |
|
||||
|1 |14 |`C4` |`C4` | |`C4` |
|
||||
|1 |15 |`C5` |`C5` | |`C5` |
|
||||
|1 |16 | | | | |
|
||||
|2 |0 | |`A0`¹ | |`A0`² |
|
||||
|2 |1 | |`A1`¹ |`A4` |`A1`² |
|
||||
|2 |2 | |`A2`¹ |`A5` |`A2`² |
|
||||
|2 |3 | |`A3`¹ |`A6` |`A3`² |
|
||||
|2 |4 | |`A4`¹ |`A7` |`A4`² |
|
||||
|2 |5 | |`A5`¹ |`C4` |`A5`² |
|
||||
|2 |6 | |`A6`¹ |`C0` |`A6`² |
|
||||
|2 |7 | |`A7`¹ |`C1` |`A7`² |
|
||||
|2 |8 | |`B0`¹ |`C2` |`B0`² |
|
||||
|2 |9 | |`B1`¹ |`C3` |`B1`² |
|
||||
|2 |10 | |`C0`¹ |`F2` |`C0`² |
|
||||
|2 |11 | |`C1`¹ |`C5` |`C1`² |
|
||||
|2 |12 | |`C2`¹ |`B2` |`C2`² |
|
||||
|2 |13 | |`C3`¹ | |`C3`² |
|
||||
|2 |14 | |`C4`¹ | |`C4`² |
|
||||
|2 |15 | |`C5`¹ | |`C5`² |
|
||||
|2 |16 | | | | |
|
||||
|3 |0 | |`A0`¹ | |`A0`² |
|
||||
|3 |1 | |`A1`¹ |`B1` |`A1`² |
|
||||
|3 |2 | |`A2`¹ |`E9` |`A2`² |
|
||||
|3 |3 | |`A3`¹ |`E13` |`A3`² |
|
||||
|3 |4 | |`F6`¹ | |`F6`² |
|
||||
|3 |5 | |`F7`¹ |`B13` |`F7`² |
|
||||
|3 |6 | |`F8`¹ |`E8` |`F8`² |
|
||||
|3 |7 | |`F9`¹ |`D10` |`F9`² |
|
||||
|3 |8 | |`F10`¹ |`D11` |`F10`² |
|
||||
|3 |9 | | |`D12` |`F3`² |
|
||||
|3 |10 | |`C0`¹ |`D13` |`C0`² |
|
||||
|3 |11 | |`C1`¹ |`D14` |`C1`² |
|
||||
|3 |12 | |`C2`¹ |`B0` |`C2`² |
|
||||
|3 |13 | |`C3`¹ |`E7` |`C3`² |
|
||||
|3 |14 | | |`E10` |`F4`² |
|
||||
|3 |15 | | |`E11` |`F5`² |
|
||||
|3 |16 | | |`E12` | |
|
||||
|4 |1 | | |`E14` | |
|
||||
|4 |2 | | |`E15` | |
|
||||
|4 |3 | | |`B12` | |
|
||||
|4 |4 | | |`B14` | |
|
||||
|4 |5 | | |`B15` | |
|
||||
|4 |6 | | |`E8` | |
|
||||
|4 |7 | | |`D10` | |
|
||||
|4 |8 | | |`D11` | |
|
||||
|4 |9 | | |`D12` | |
|
||||
|4 |10 | | |`D13` | |
|
||||
|4 |11 | | |`D14` | |
|
||||
|4 |12 | | |`D8` | |
|
||||
|4 |13 | | |`D9` | |
|
||||
|4 |14 | | | | |
|
||||
|4 |15 | | | | |
|
||||
|4 |16 | | | | |
|
||||
|
||||
<sup>¹ As of ChibiOS 20.3.4, the ADC driver for STM32F1xx devices supports only ADC1, therefore any configurations involving ADC2 or ADC3 cannot actually be used. In particular, pins `F6`…`F10`, which are present at least on some STM32F103x[C-G] devices, cannot be used as ADC inputs because of this driver limitation.</sup>
|
||||
|
||||
<sup>² Not all STM32F4xx devices have ADC2 and/or ADC3, therefore some configurations shown in this table may be unavailable; in particular, pins `F4`…`F10` cannot be used as ADC inputs on devices which do not have ADC3. Check the device datasheet to confirm which pin functions are supported.</sup>
|
||||
|
||||
#### RP2040
|
||||
|
||||
RP2040 has only a single ADC (`ADCD1` in ChibiOS); in the QMK API the index for that ADC is 0.
|
||||
|
||||
|Channel|Pin |
|
||||
|-------|-------------------|
|
||||
|0 |`GP26` |
|
||||
|1 |`GP27` |
|
||||
|2 |`GP28` |
|
||||
|3 |`GP29` |
|
||||
|4 |Temperature sensor*|
|
||||
|
||||
|
||||
<sup>* The temperature sensor is disabled by default and needs to be enabled by the RP2040-specific function: `adcRPEnableTS(&ADCD1)`. The ADC must be initialized before calling that function; an easy way to ensure that is to perform a dummy conversion.</sup>
|
||||
|
||||
## Functions
|
||||
|
||||
### AVR
|
||||
|
||||
|Function |Description |
|
||||
|----------------------------|-------------------------------------------------------------------------------------------------------------------|
|
||||
|`analogReference(mode)` |Sets the analog voltage reference source. Must be one of `ADC_REF_EXTERNAL`, `ADC_REF_POWER` or `ADC_REF_INTERNAL`.|
|
||||
|`analogReadPin(pin)` |Reads the value from the specified pin, eg. `F6` for ADC6 on the ATmega32U4. |
|
||||
|`pinToMux(pin)` |Translates a given pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)". |
|
||||
|`adc_read(mux)` |Reads the value from the ADC according to the specified mux. See your MCU's datasheet for more information. |
|
||||
|
||||
### ARM
|
||||
|
||||
|Function |Description |
|
||||
|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|`analogReadPin(pin)` |Reads the value from the specified pin, eg. `A0` for channel 0 on the STM32F0 and ADC1 channel 1 on the STM32F3. Note that if a pin can be used for multiple ADCs, it will pick the lower numbered ADC for this function. eg. `C0` will be channel 6 of ADC 1 when it could be used for ADC 2 as well.|
|
||||
|`analogReadPinAdc(pin, adc)`|Reads the value from the specified pin and ADC, eg. `C0, 1` will read from channel 6, ADC 2 instead of ADC 1. Note that the ADCs are 0-indexed for this function. |
|
||||
|`pinToMux(pin)` |Translates a given pin to a channel and ADC combination. If an unsupported pin is given, returns the mux value for "0V (GND)". |
|
||||
|`adc_read(mux)` |Reads the value from the ADC according to the specified pin and ADC combination. See your MCU's datasheet for more information. |
|
||||
|
||||
## Configuration
|
||||
|
||||
## ARM
|
||||
|
||||
The ARM implementation of the ADC has a few additional options that you can override in your own keyboards and keymaps to change how it operates. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.
|
||||
|
||||
|`#define` |Type |Default |Description |
|
||||
|---------------------|------|----------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|`ADC_CIRCULAR_BUFFER`|`bool`|`false` |If `true`, then the implementation will use a circular buffer. |
|
||||
|`ADC_NUM_CHANNELS` |`int` |`1` |Sets the number of channels that will be scanned as part of an ADC operation. The current implementation only supports `1`. |
|
||||
|`ADC_BUFFER_DEPTH` |`int` |`2` |Sets the depth of each result. Since we are only getting a 10-bit result by default, we set this to 2 bytes so we can contain our one value. This could be set to 1 if you opt for an 8-bit or lower result.|
|
||||
|`ADC_SAMPLING_RATE` |`int` |`ADC_SMPR_SMP_1P5` |Sets the sampling rate of the ADC. By default, it is set to the fastest setting. |
|
||||
|`ADC_RESOLUTION` |`int` |`ADC_CFGR1_RES_10BIT` or `ADC_CFGR_RES_10BITS`|The resolution of your result. We choose 10 bit by default, but you can opt for 12, 10, 8, or 6 bit. Different MCUs use slightly different names for the resolution constants. |
|
@ -1,49 +0,0 @@
|
||||
# APA102 Driver :id=apa102-driver
|
||||
|
||||
This driver provides support for APA102 addressable RGB LEDs. They are similar to the [WS2812](ws2812_driver.md) LEDs, but have increased data and refresh rates.
|
||||
|
||||
## Usage :id=usage
|
||||
|
||||
In most cases, the APA102 driver code is automatically included if you are using either the [RGBLight](feature_rgblight.md) or [RGB Matrix](feature_rgb_matrix.md) feature with the `apa102` driver set, and you would use those APIs instead.
|
||||
|
||||
However, if you need to use the driver standalone, add the following to your `rules.mk`:
|
||||
|
||||
```make
|
||||
APA102_DRIVER_REQUIRED = yes
|
||||
```
|
||||
|
||||
You can then call the APA102 API by including `apa102.h` in your code.
|
||||
|
||||
## Basic Configuration :id=basic-configuration
|
||||
|
||||
Add the following to your `config.h`:
|
||||
|
||||
|Define |Default |Description |
|
||||
|---------------------------|-------------|------------------------------------------------------------------|
|
||||
|`APA102_DI_PIN` |*Not defined*|The GPIO pin connected to the DI pin of the first LED in the chain|
|
||||
|`APA102_CI_PIN` |*Not defined*|The GPIO pin connected to the CI pin of the first LED in the chain|
|
||||
|`APA102_DEFAULT_BRIGHTNESS`|`31` |The default global brightness level of the LEDs, from 0 to 31 |
|
||||
|
||||
## API :id=api
|
||||
|
||||
### `void apa102_setleds(rgb_led_t *start_led, uint16_t num_leds)`
|
||||
|
||||
Send RGB data to the APA102 LED chain.
|
||||
|
||||
#### Arguments :id=api-apa102-setleds-arguments
|
||||
|
||||
- `rgb_led_t *start_led`
|
||||
A pointer to the LED array.
|
||||
- `uint16_t num_leds`
|
||||
The length of the LED array.
|
||||
|
||||
---
|
||||
|
||||
### `void apa102_set_brightness(uint8_t brightness)`
|
||||
|
||||
Set the global brightness.
|
||||
|
||||
#### Arguments :id=api-apa102-set-brightness-arguments
|
||||
|
||||
- `uint8_t brightness`
|
||||
The brightness level to set, from 0 to 31.
|
@ -67,7 +67,7 @@ Once your compile job has finished you'll check the `result` key. The value of t
|
||||
* `firmware_source_url`: A list of URLs for the full firmware source code
|
||||
* `output`: The stdout and stderr for this compile job. Errors will be found here.
|
||||
|
||||
## Constants :id=qmk-constants
|
||||
## Constants {#qmk-constants}
|
||||
|
||||
If you're writing a tool that leverages constants used within QMK, the API is used to publish "locked-in" versions of those constants in order to ensure that any third-party tooling has a canonical set of information to work with.
|
||||
|
||||
@ -81,9 +81,13 @@ $ curl https://keyboards.develop.qmk.fm/v1/constants_metadata.json # For `develo
|
||||
{"last_updated": "2022-11-26 12:00:00 GMT", "constants": {"keycodes": ["0.0.1", "0.0.2"]}}
|
||||
```
|
||||
|
||||
!> Versions exported by the `master` endpoint are locked-in. Any extra versions that exist on the `develop` endpoint which don't exist in `master` are subject to change.
|
||||
::: warning
|
||||
Versions exported by the `master` endpoint are locked-in. Any extra versions that exist on the `develop` endpoint which don't exist in `master` are subject to change.
|
||||
:::
|
||||
|
||||
?> Only keycodes are currently published, but over time all other "externally visible" IDs are expected to appear on these endpoints.
|
||||
::: tip
|
||||
Only keycodes are currently published, but over time all other "externally visible" IDs are expected to appear on these endpoints.
|
||||
:::
|
||||
|
||||
To retrieve the constants associated with a subsystem, the endpoint format is as follows:
|
||||
```
|
||||
|
@ -4,12 +4,12 @@ The QMK API provides an asynchronous API that Web and GUI tools can use to compi
|
||||
|
||||
## App Developers
|
||||
|
||||
If you are an app developer interested in using this API in your application you should head over to [Using The API](api_docs.md).
|
||||
If you are an app developer interested in using this API in your application you should head over to [Using The API](api_docs).
|
||||
|
||||
## Keyboard Maintainers
|
||||
|
||||
If you would like to enhance your keyboard's support in the QMK Compiler API head over to the [Keyboard Support](reference_configurator_support.md) section.
|
||||
If you would like to enhance your keyboard's support in the QMK Compiler API head over to the [Keyboard Support](reference_configurator_support) section.
|
||||
|
||||
## Backend Developers
|
||||
|
||||
If you are interested in working on the API itself you should start by setting up a [Development Environment](api_development_environment.md), then check out [Hacking On The API](api_development_overview.md).
|
||||
If you are interested in working on the API itself you should start by setting up a [Development Environment](api_development_environment), then check out [Hacking On The API](api_development_overview).
|
||||
|
@ -1,237 +0,0 @@
|
||||
# Audio Driver :id=audio-driver
|
||||
|
||||
The [Audio feature](feature_audio.md) breaks the hardware specifics out into separate, exchangeable driver units, with a common interface to the audio-"core" - which itself handles playing songs and notes while tracking their progress in an internal state, initializing/starting/stopping the driver as needed.
|
||||
|
||||
Not all MCUs support every available driver, either the platform-support is not there (yet?) or the MCU simply does not have the required hardware peripheral.
|
||||
|
||||
|
||||
## AVR :id=avr
|
||||
|
||||
Boards built around an Atmega32U4 can use two sets of PWM capable pins, each driving a separate speaker.
|
||||
The possible configurations are:
|
||||
|
||||
| | Timer3 | Timer1 |
|
||||
|--------------|-------------|--------------|
|
||||
| one speaker | C4,C5 or C6 | |
|
||||
| one speaker | | B4, B5 or B7 |
|
||||
| two speakers | C4,C5 or C6 | B4, B5 or B7 |
|
||||
|
||||
Currently there is only one/default driver for AVR based boards, which is automatically configured to:
|
||||
|
||||
```make
|
||||
AUDIO_DRIVER = pwm_hardware
|
||||
```
|
||||
|
||||
|
||||
## ARM :id=arm
|
||||
|
||||
For Arm based boards, QMK depends on ChibiOS - hence any MCU supported by the later is likely usable, as long as certain hardware peripherals are available.
|
||||
|
||||
Supported wiring configurations, with their ChibiOS/MCU peripheral requirement are listed below;
|
||||
piezo speakers are marked with :one: for the first/primary and :two: for the secondary.
|
||||
|
||||
| driver | GPTD6<br>Tim6 | GPTD7<br>Tim7 | GPTD8<br>Tim8 | PWMD1<sup>1</sup><br>Tim1_Ch1 |
|
||||
|--------------|------------------------------------------|------------------------|---------------|-------------------------------|
|
||||
| dac_basic | A4+DACD1 = :one: | A5+DACD2 = :one: | state | |
|
||||
| | A4+DACD1 = :one: + Gnd | A5+DACD2 = :two: + Gnd | state | |
|
||||
| | A4+DACD1 = :two: + Gnd | A5+DACD2 = :one: + Gnd | state | |
|
||||
| | A4+DACD1 = :one: + Gnd | | state | |
|
||||
| | | A5+DACD2 = :one: + Gnd | state | |
|
||||
| dac_additive | A4+DACD1 = :one: + Gnd | | | |
|
||||
| | A5+DACD2 = :one: + Gnd | | | |
|
||||
| | A4+DACD1 + A5+DACD2 = :one: <sup>2</sup> | | | |
|
||||
| pwm_software | state-update | | | any = :one: |
|
||||
| pwm hardware | state-update | | | A8 = :one: <sup>3</sup> |
|
||||
|
||||
|
||||
<sup>1</sup>: the routing and alternate functions for PWM differ sometimes between STM32 MCUs, if in doubt consult the data-sheet
|
||||
<sup>2</sup>: one piezo connected to A4 and A5, with AUDIO_PIN_ALT_AS_NEGATIVE set
|
||||
<sup>3</sup>: TIM1_CH1 = A8 on STM32F103C8, other combinations are possible, see Data-sheet. configured with: AUDIO_PWM_DRIVER and AUDIO_PWM_CHANNEL
|
||||
|
||||
|
||||
|
||||
### DAC basic :id=dac-basic
|
||||
|
||||
The default driver for ARM boards, in absence of an overriding configuration.
|
||||
This driver needs one Timer per enabled/used DAC channel, to trigger conversion; and a third timer to trigger state updates with the audio-core.
|
||||
|
||||
Additionally, in the board config, you'll want to make changes to enable the DACs, GPT for Timers 6, 7 and 8:
|
||||
|
||||
```c
|
||||
//halconf.h:
|
||||
#define HAL_USE_DAC TRUE
|
||||
#define HAL_USE_GPT TRUE
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
|
||||
```c
|
||||
// mcuconf.h:
|
||||
#include_next <mcuconf.h>
|
||||
#undef STM32_DAC_USE_DAC1_CH1
|
||||
#define STM32_DAC_USE_DAC1_CH1 TRUE
|
||||
#undef STM32_DAC_USE_DAC1_CH2
|
||||
#define STM32_DAC_USE_DAC1_CH2 TRUE
|
||||
#undef STM32_GPT_USE_TIM6
|
||||
#define STM32_GPT_USE_TIM6 TRUE
|
||||
#undef STM32_GPT_USE_TIM7
|
||||
#define STM32_GPT_USE_TIM7 TRUE
|
||||
#undef STM32_GPT_USE_TIM8
|
||||
#define STM32_GPT_USE_TIM8 TRUE
|
||||
```
|
||||
|
||||
?> Note: DAC1 (A4) uses TIM6, DAC2 (A5) uses TIM7, and the audio state timer uses TIM8 (configurable).
|
||||
|
||||
You can also change the timer used for the overall audio state by defining the driver. For instance:
|
||||
|
||||
```c
|
||||
#define AUDIO_STATE_TIMER GPTD9
|
||||
```
|
||||
|
||||
### DAC additive :id=dac-additive
|
||||
|
||||
only needs one timer (GPTD6, Tim6) to trigger the DAC unit to do a conversion; the audio state updates are in turn triggered during the DAC callback.
|
||||
|
||||
Additionally, in the board config, you'll want to make changes to enable the DACs, GPT for Timer 6:
|
||||
|
||||
```c
|
||||
//halconf.h:
|
||||
#define HAL_USE_DAC TRUE
|
||||
#define HAL_USE_GPT TRUE
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
|
||||
```c
|
||||
// mcuconf.h:
|
||||
#include_next <mcuconf.h>
|
||||
#undef STM32_DAC_USE_DAC1_CH1
|
||||
#define STM32_DAC_USE_DAC1_CH1 TRUE
|
||||
#undef STM32_DAC_USE_DAC1_CH2
|
||||
#define STM32_DAC_USE_DAC1_CH2 TRUE
|
||||
#undef STM32_GPT_USE_TIM6
|
||||
#define STM32_GPT_USE_TIM6 TRUE
|
||||
```
|
||||
|
||||
### DAC Config
|
||||
|
||||
| Define | Defaults | Description |
|
||||
| -------------------------------- | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `AUDIO_DAC_SAMPLE_MAX` | `4095U` | Highest value allowed. Lower value means lower volume. And 4095U is the upper limit, since this is limited to a 12 bit value. Only effects non-pregenerated samples. |
|
||||
| `AUDIO_DAC_OFF_VALUE` | `AUDIO_DAC_SAMPLE_MAX / 2` | The value of the DAC when not playing anything. Some setups may require a high (`AUDIO_DAC_SAMPLE_MAX`) or low (`0`) value here. |
|
||||
| `AUDIO_MAX_SIMULTANEOUS_TONES` | __see next table__ | The number of tones that can be played simultaneously. A value that is too high may freeze the controller or glitch out when too many tones are being played. |
|
||||
| `AUDIO_DAC_SAMPLE_RATE` | __see next table__ | Effective bit rate of the DAC (in hertz), higher limits simultaneous tones, and lower sacrifices quality. |
|
||||
| `AUDIO_DAC_BUFFER_SIZE` | __see next table__ | Number of samples generated every refill. Too few may cause excessive CPU load; too many may cause freezes, RAM or flash exhaustion or lags during matrix scanning. |
|
||||
|
||||
There are a number of predefined quality settings that you can use, with "sane minimum" being the default. You can use custom values by simply defining the sample rate, number of simultaneous tones and buffer size, instead of using one of the listed presets.
|
||||
|
||||
| Define | Sample Rate | Simultaneous tones | Buffer size |
|
||||
| --------------------------------- | ----------- | ------------------- | ----------- |
|
||||
| `AUDIO_DAC_QUALITY_VERY_LOW` | `11025U` | `8` | `64U` |
|
||||
| `AUDIO_DAC_QUALITY_LOW` | `22050U` | `4` | `128U` |
|
||||
| `AUDIO_DAC_QUALITY_HIGH` | `44100U` | `2` | `256U` |
|
||||
| `AUDIO_DAC_QUALITY_VERY_HIGH` | `88200U` | `1` | `256U` |
|
||||
| `AUDIO_DAC_QUALITY_SANE_MINIMUM` | `16384U` | `8` | `64U` |
|
||||
|
||||
#### Notes on buffer size :id=buffer-size
|
||||
|
||||
By default, the buffer size attempts to keep to these constraints:
|
||||
|
||||
* The interval between buffer refills can't be too short, since the microcontroller would then only be servicing buffer refills and would freeze up.
|
||||
* On the additive driver, the interval between buffer refills can't be too long, since matrix scanning would suffer lengthy pauses every so often, which would delay key presses or releases or lose some short taps altogether.
|
||||
* The interval between buffer refills is kept to a minimum, which allows notes to stop as soon as possible after they should.
|
||||
* For greater compatibility, the buffer size should be a power of 2.
|
||||
* The buffer size being too large causes resource exhaustion leading to build failures or freezing at runtime: RAM usage (on the additive driver) or flash usage (on the basic driver).
|
||||
|
||||
You can lower the buffer size if you need a bit more space in your firmware, or raise it if your keyboard freezes up.
|
||||
|
||||
|
||||
```c
|
||||
/* zero crossing (or approach, whereas zero == DAC_OFF_VALUE, which can be configured to anything from 0 to DAC_SAMPLE_MAX)
|
||||
* ============================*=*========================== AUDIO_DAC_SAMPLE_MAX
|
||||
* * *
|
||||
* * *
|
||||
* ---------------------------------------------------------
|
||||
* * * } AUDIO_DAC_SAMPLE_MAX/100
|
||||
* --------------------------------------------------------- AUDIO_DAC_OFF_VALUE
|
||||
* * * } AUDIO_DAC_SAMPLE_MAX/100
|
||||
* ---------------------------------------------------------
|
||||
* *
|
||||
* * *
|
||||
* * *
|
||||
* =====*=*================================================= 0x0
|
||||
*/
|
||||
```
|
||||
|
||||
|
||||
### PWM hardware :id=pwm-hardware
|
||||
|
||||
This driver uses the ChibiOS-PWM system to produce a square-wave on specific output pins that are connected to the PWM hardware.
|
||||
The hardware directly toggles the pin via its alternate function. See your MCU's data-sheet for which pin can be driven by what timer - looking for TIMx_CHy and the corresponding alternate function.
|
||||
|
||||
A configuration example for the STM32F103C8 would be:
|
||||
```c
|
||||
//halconf.h:
|
||||
#define HAL_USE_PWM TRUE
|
||||
#define HAL_USE_PAL TRUE
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
|
||||
```c
|
||||
// mcuconf.h:
|
||||
#include_next <mcuconf.h>
|
||||
#undef STM32_PWM_USE_TIM1
|
||||
#define STM32_PWM_USE_TIM1 TRUE
|
||||
```
|
||||
|
||||
If we now target pin A8, looking through the data-sheet of the STM32F103C8, for the timers and alternate functions
|
||||
- TIM1_CH1 = PA8 <- alternate0
|
||||
- TIM1_CH2 = PA9
|
||||
- TIM1_CH3 = PA10
|
||||
- TIM1_CH4 = PA11
|
||||
|
||||
with all this information, the configuration would contain these lines:
|
||||
```c
|
||||
//config.h:
|
||||
#define AUDIO_PIN A8
|
||||
#define AUDIO_PWM_DRIVER PWMD1
|
||||
#define AUDIO_PWM_CHANNEL 1
|
||||
```
|
||||
|
||||
ChibiOS uses GPIOv1 for the F103, which only knows of one alternate function.
|
||||
On 'larger' STM32s, GPIOv2 or GPIOv3 are used; with them it is also necessary to configure `AUDIO_PWM_PAL_MODE` to the correct alternate function for the selected pin, timer and timer-channel.
|
||||
|
||||
You can also use the Complementary output (`TIMx_CHyN`) for PWM on supported controllers. To enable this functionality, you will need to make the following changes:
|
||||
```c
|
||||
// config.h:
|
||||
#define AUDIO_PWM_COMPLEMENTARY_OUTPUT
|
||||
```
|
||||
|
||||
### PWM software :id=pwm-software
|
||||
|
||||
This driver uses the PWM callbacks from PWMD1 with TIM1_CH1 to toggle the selected AUDIO_PIN in software.
|
||||
During the same callback, with AUDIO_PIN_ALT_AS_NEGATIVE set, the AUDIO_PIN_ALT is toggled inversely to AUDIO_PIN. This is useful for setups that drive a piezo from two pins (instead of one and Gnd).
|
||||
|
||||
You can also change the timer used for software PWM by defining the driver. For instance:
|
||||
|
||||
```c
|
||||
#define AUDIO_STATE_TIMER GPTD8
|
||||
```
|
||||
|
||||
|
||||
### Testing Notes :id=testing-notes
|
||||
|
||||
While not an exhaustive list, the following table provides the scenarios that have been partially validated:
|
||||
|
||||
| | DAC basic | DAC additive | PWM hardware | PWM software |
|
||||
| ------------------------ | ------------------ | ------------------ | ------------------ | ------------------ |
|
||||
| Atmega32U4 | :o: | :o: | :heavy_check_mark: | :o: |
|
||||
| RP2040 | :x: | :x: | :heavy_check_mark: | ? |
|
||||
| STM32F103C8 (bluepill) | :x: | :x: | :heavy_check_mark: | :heavy_check_mark: |
|
||||
| STM32F303CCT6 (proton-c) | :heavy_check_mark: | :heavy_check_mark: | ? | :heavy_check_mark: |
|
||||
| STM32F405VG | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
|
||||
| L0xx | :x: (no Tim8) | ? | ? | ? |
|
||||
|
||||
:heavy_check_mark: : works and was tested
|
||||
:o: : does not apply
|
||||
:x: : not supported by MCU
|
||||
|
||||
*Other supported ChibiOS boards and/or pins may function, it will be highly chip and configuration dependent.*
|
@ -10,25 +10,25 @@ Practically, this means QMK merges the `develop` branch into the `master` branch
|
||||
|
||||
## What has been included in past Breaking Changes?
|
||||
|
||||
* [2024 Feb 25](ChangeLog/20240225.md)
|
||||
* [2023 Nov 26](ChangeLog/20231126.md)
|
||||
* [2023 Aug 27](ChangeLog/20230827.md)
|
||||
* [Older Breaking Changes](breaking_changes_history.md)
|
||||
* [2024 May 26](ChangeLog/20240526)
|
||||
* [2024 Feb 25](ChangeLog/20240225)
|
||||
* [2023 Nov 26](ChangeLog/20231126)
|
||||
* [Older Breaking Changes](breaking_changes_history)
|
||||
|
||||
## When is the next Breaking Change?
|
||||
|
||||
The next Breaking Change is scheduled for May 26, 2024.
|
||||
The next Breaking Change is scheduled for August 25, 2024.
|
||||
|
||||
### Important Dates
|
||||
|
||||
* 2024 Feb 25 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
|
||||
* 2024 Apr 28 - `develop` closed to new PRs.
|
||||
* 2024 Apr 28 - Call for testers.
|
||||
* 2024 May 5 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
|
||||
* 2024 May 19 - `develop` is locked, only critical bugfix PRs merged.
|
||||
* 2024 May 23 - `master` is locked, no PRs merged.
|
||||
* 2024 May 26 - Merge `develop` to `master`.
|
||||
* 2024 May 26 - `master` is unlocked. PRs can be merged again.
|
||||
* 2024 May 26 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
|
||||
* 2024 Jul 28 - `develop` closed to new PRs.
|
||||
* 2024 Jul 28 - Call for testers.
|
||||
* 2024 Aug 4 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
|
||||
* 2024 Aug 18 - `develop` is locked, only critical bugfix PRs merged.
|
||||
* 2024 Aug 22 - `master` is locked, no PRs merged.
|
||||
* 2024 Aug 25 - Merge `develop` to `master`.
|
||||
* 2024 Aug 25 - `master` is unlocked. PRs can be merged again.
|
||||
|
||||
## What changes will be included?
|
||||
|
||||
@ -71,7 +71,7 @@ This section documents various processes we use when running the Breaking Change
|
||||
### 1 Week Before Merge
|
||||
|
||||
* `develop` is now closed to PR merges, only critical bugfixes may be included
|
||||
* Announce that master will be closed from <2 Days Before> to <Day of Merge> -- message `@Breaking Changes Updates` on `#qmk_firmware` in Discord:
|
||||
* Announce that master will be closed from `<2 Days Before>` to `<Day of Merge>` -- message `@Breaking Changes Updates` on `#qmk_firmware` in Discord:
|
||||
* `@Breaking Changes Updates -- Hey folks, last day for functional PRs to be merged into qmk_firmware for this breaking changes cycle is today. After that, we're handling bugfixes only.`
|
||||
|
||||
### 2 Days Before Merge
|
||||
@ -136,7 +136,7 @@ This happens immediately after the previous `develop` branch is merged to `maste
|
||||
* Announce that both `master` and `develop` are now unlocked -- message `@Breaking Changes Updates` on `#qmk_firmware` in Discord:
|
||||
* `@Breaking Changes Updates -- Hey folks, develop has now been merged into master -- newest batch of changes are now available for everyone to use!`
|
||||
|
||||
* (Optional) [update ChibiOS + ChibiOS-Contrib on `develop`](chibios_upgrade_instructions.md)
|
||||
* (Optional) [update ChibiOS + ChibiOS-Contrib on `develop`](chibios_upgrade_instructions)
|
||||
|
||||
|
||||
### Set up Discord events for the next cycle
|
||||
|
@ -2,21 +2,22 @@
|
||||
|
||||
This page links to all previous changelogs from the QMK Breaking Changes process.
|
||||
|
||||
* [2024 Feb 25](ChangeLog/20240225.md) - version 0.24.0
|
||||
* [2023 Nov 26](ChangeLog/20231126.md) - version 0.23.0
|
||||
* [2023 Aug 27](ChangeLog/20230827.md) - version 0.22.0
|
||||
* [2023 May 28](ChangeLog/20230528.md) - version 0.21.0
|
||||
* [2023 Feb 26](ChangeLog/20230226.md) - version 0.20.0
|
||||
* [2022 Nov 26](ChangeLog/20221126.md) - version 0.19.0
|
||||
* [2022 Aug 27](ChangeLog/20220827.md) - version 0.18.0
|
||||
* [2022 May 28](ChangeLog/20220528.md) - version 0.17.0
|
||||
* [2022 Feb 26](ChangeLog/20220226.md) - version 0.16.0
|
||||
* [2021 Nov 27](ChangeLog/20211127.md) - version 0.15.0
|
||||
* [2021 Aug 28](ChangeLog/20210828.md) - version 0.14.0
|
||||
* [2021 May 29](ChangeLog/20210529.md) - version 0.13.0
|
||||
* [2021 Feb 27](ChangeLog/20210227.md) - version 0.12.0
|
||||
* [2020 Nov 28](ChangeLog/20201128.md) - version 0.11.0
|
||||
* [2020 Aug 29](ChangeLog/20200829.md) - version 0.10.0
|
||||
* [2020 May 30](ChangeLog/20200530.md) - version 0.9.0
|
||||
* [2020 Feb 29](ChangeLog/20200229.md) - version 0.8.0
|
||||
* [2019 Aug 30](ChangeLog/20190830.md) - version 0.7.0
|
||||
* [2024 May 26](ChangeLog/20240526) - version 0.25.0
|
||||
* [2024 Feb 25](ChangeLog/20240225) - version 0.24.0
|
||||
* [2023 Nov 26](ChangeLog/20231126) - version 0.23.0
|
||||
* [2023 Aug 27](ChangeLog/20230827) - version 0.22.0
|
||||
* [2023 May 28](ChangeLog/20230528) - version 0.21.0
|
||||
* [2023 Feb 26](ChangeLog/20230226) - version 0.20.0
|
||||
* [2022 Nov 26](ChangeLog/20221126) - version 0.19.0
|
||||
* [2022 Aug 27](ChangeLog/20220827) - version 0.18.0
|
||||
* [2022 May 28](ChangeLog/20220528) - version 0.17.0
|
||||
* [2022 Feb 26](ChangeLog/20220226) - version 0.16.0
|
||||
* [2021 Nov 27](ChangeLog/20211127) - version 0.15.0
|
||||
* [2021 Aug 28](ChangeLog/20210828) - version 0.14.0
|
||||
* [2021 May 29](ChangeLog/20210529) - version 0.13.0
|
||||
* [2021 Feb 27](ChangeLog/20210227) - version 0.12.0
|
||||
* [2020 Nov 28](ChangeLog/20201128) - version 0.11.0
|
||||
* [2020 Aug 29](ChangeLog/20200829) - version 0.10.0
|
||||
* [2020 May 30](ChangeLog/20200530) - version 0.9.0
|
||||
* [2020 Feb 29](ChangeLog/20200229) - version 0.8.0
|
||||
* [2019 Aug 30](ChangeLog/20190830) - version 0.7.0
|
||||
|
12
docs/cli.md
12
docs/cli.md
@ -1,14 +1,14 @@
|
||||
# QMK CLI :id=qmk-cli
|
||||
# QMK CLI {#qmk-cli}
|
||||
|
||||
## Overview :id=overview
|
||||
## Overview {#overview}
|
||||
|
||||
The QMK CLI (command line interface) makes building and working with QMK keyboards easier. We have provided a number of commands to simplify and streamline tasks such as obtaining and compiling the QMK firmware, creating keymaps, and more.
|
||||
|
||||
### Requirements :id=requirements
|
||||
### Requirements {#requirements}
|
||||
|
||||
QMK requires Python 3.7 or greater. We try to keep the number of requirements small but you will also need to install the packages listed in [`requirements.txt`](https://github.com/qmk/qmk_firmware/blob/master/requirements.txt). These are installed automatically when you install the QMK CLI.
|
||||
|
||||
### Install Using Homebrew (macOS, some Linux) :id=install-using-homebrew
|
||||
### Install Using Homebrew (macOS, some Linux) {#install-using-homebrew}
|
||||
|
||||
If you have installed [Homebrew](https://brew.sh) you can tap and install QMK:
|
||||
|
||||
@ -18,7 +18,7 @@ export QMK_HOME='~/qmk_firmware' # Optional, set the location for `qmk_firmware`
|
||||
qmk setup # This will clone `qmk/qmk_firmware` and optionally set up your build environment
|
||||
```
|
||||
|
||||
### Install Using pip :id=install-using-easy_install-or-pip
|
||||
### Install Using pip {#install-using-easy_install-or-pip}
|
||||
|
||||
If your system is not listed above you can install QMK manually. First ensure that you have Python 3.7 (or later) installed and have installed pip. Then install QMK with this command:
|
||||
|
||||
@ -28,7 +28,7 @@ export QMK_HOME='~/qmk_firmware' # Optional, set the location for `qmk_firmware`
|
||||
qmk setup # This will clone `qmk/qmk_firmware` and optionally set up your build environment
|
||||
```
|
||||
|
||||
### Packaging For Other Operating Systems :id=packaging-for-other-operating-systems
|
||||
### Packaging For Other Operating Systems {#packaging-for-other-operating-systems}
|
||||
|
||||
We are looking for people to create and maintain a `qmk` package for more operating systems. If you would like to create a package for your OS please follow these guidelines:
|
||||
|
||||
|
@ -86,7 +86,7 @@ qmk compile -j 0 -kb <keyboard_name>
|
||||
|
||||
## `qmk flash`
|
||||
|
||||
This command is similar to `qmk compile`, but can also target a bootloader. The bootloader is optional, and is set to `:flash` by default. To specify a different bootloader, use `-bl <bootloader>`. Visit the [Flashing Firmware](flashing.md) guide for more details of the available bootloaders.
|
||||
This command is similar to `qmk compile`, but can also target a bootloader. The bootloader is optional, and is set to `:flash` by default. To specify a different bootloader, use `-bl <bootloader>`. Visit the [Flashing Firmware](flashing) guide for more details of the available bootloaders.
|
||||
|
||||
This command is directory aware. It will automatically fill in KEYBOARD and/or KEYMAP if you are in a keyboard or keymap directory.
|
||||
|
||||
@ -127,7 +127,7 @@ qmk flash -b
|
||||
|
||||
## `qmk config`
|
||||
|
||||
This command lets you configure the behavior of QMK. For the full `qmk config` documentation see [CLI Configuration](cli_configuration.md).
|
||||
This command lets you configure the behavior of QMK. For the full `qmk config` documentation see [CLI Configuration](cli_configuration).
|
||||
|
||||
**Usage**:
|
||||
|
||||
@ -254,15 +254,21 @@ qmk doctor [-y] [-n]
|
||||
|
||||
Check your environment for problems and prompt to fix them:
|
||||
|
||||
```
|
||||
qmk doctor
|
||||
```
|
||||
|
||||
Check your environment and automatically fix any problems found:
|
||||
|
||||
```
|
||||
qmk doctor -y
|
||||
```
|
||||
|
||||
Check your environment and report problems only:
|
||||
|
||||
```
|
||||
qmk doctor -n
|
||||
```
|
||||
|
||||
## `qmk format-json`
|
||||
|
||||
@ -290,15 +296,21 @@ This command is directory aware. It will automatically fill in KEYBOARD and/or K
|
||||
|
||||
Show basic information for a keyboard:
|
||||
|
||||
```
|
||||
qmk info -kb planck/rev5
|
||||
```
|
||||
|
||||
Show the matrix for a keyboard:
|
||||
|
||||
```
|
||||
qmk info -kb ergodox_ez -m
|
||||
```
|
||||
|
||||
Show a JSON keymap for a keyboard:
|
||||
|
||||
```
|
||||
qmk info -kb clueboard/california -km default
|
||||
```
|
||||
|
||||
## `qmk json2c`
|
||||
|
||||
@ -322,6 +334,18 @@ Creates a keymap.json from a keymap.c.
|
||||
qmk c2json -km KEYMAP -kb KEYBOARD [-q] [--no-cpp] [-o OUTPUT] filename
|
||||
```
|
||||
|
||||
**Examples**:
|
||||
|
||||
```
|
||||
qmk c2json -km default -kb handwired/dactyl_promicro
|
||||
```
|
||||
|
||||
or with filename:
|
||||
|
||||
```
|
||||
qmk c2json keyboards/handwired/dactyl_promicro/keymaps/default/keymap.c
|
||||
```
|
||||
|
||||
## `qmk lint`
|
||||
|
||||
Checks over a keyboard and/or keymap and highlights common errors, problems, and anti-patterns.
|
||||
@ -338,7 +362,9 @@ This command is directory aware. It will automatically fill in KEYBOARD and/or K
|
||||
|
||||
Do a basic lint check:
|
||||
|
||||
```
|
||||
qmk lint -kb rominronin/katana60/rev2
|
||||
```
|
||||
|
||||
## `qmk list-keyboards`
|
||||
|
||||
@ -691,30 +717,39 @@ Now open your dev environment and live a squiggly-free life.
|
||||
|
||||
## `qmk docs`
|
||||
|
||||
This command starts a local HTTP server which you can use for browsing or improving the docs. Default port is 8936.
|
||||
Use the `-b`/`--browser` flag to automatically open the local webserver in your default browser.
|
||||
This command starts a local HTTP server which you can use for browsing or improving the docs. Default port is 5173.
|
||||
|
||||
This command runs `docsify serve` if `docsify-cli` is installed (which provides live reload), otherwise Python's builtin HTTP server module will be used.
|
||||
This command requires `node` and `yarn` to be installed as prerequisites, and provides live reload capability whilst editing.
|
||||
|
||||
**Usage**:
|
||||
|
||||
```
|
||||
qmk docs [-b] [-p PORT]
|
||||
usage: qmk docs [-h]
|
||||
|
||||
options:
|
||||
-h, --help show this help message and exit
|
||||
```
|
||||
|
||||
## `qmk generate-docs`
|
||||
|
||||
This command allows you to generate QMK documentation locally. It can be uses for general browsing or improving the docs. External tools such as [serve](https://www.npmjs.com/package/serve) can be used to browse the generated files.
|
||||
This command allows you to generate QMK documentation locally. It can be uses for general browsing or improving the docs.
|
||||
Use the `-s`/`--serve` flag to also serve the static site once built. Default port is 4173.
|
||||
|
||||
This command requires `node` and `yarn` to be installed as prerequisites, and requires the operating system to support symlinks.
|
||||
|
||||
**Usage**:
|
||||
|
||||
```
|
||||
qmk generate-docs
|
||||
usage: qmk generate-docs [-h] [-s]
|
||||
|
||||
options:
|
||||
-h, --help show this help message and exit
|
||||
-s, --serve Serves the generated docs once built.
|
||||
```
|
||||
|
||||
## `qmk generate-rgb-breathe-table`
|
||||
|
||||
This command generates a lookup table (LUT) header file for the [RGB Lighting](feature_rgblight.md) feature's breathing animation. Place this file in your keyboard or keymap directory as `rgblight_breathe_table.h` to override the default LUT in `quantum/rgblight/`.
|
||||
This command generates a lookup table (LUT) header file for the [RGB Lighting](features/rgblight) feature's breathing animation. Place this file in your keyboard or keymap directory as `rgblight_breathe_table.h` to override the default LUT in `quantum/rgblight/`.
|
||||
|
||||
**Usage**:
|
||||
|
||||
@ -768,26 +803,76 @@ qmk pytest [-t TEST]
|
||||
|
||||
Run entire test suite:
|
||||
|
||||
```
|
||||
qmk pytest
|
||||
```
|
||||
|
||||
Run test group:
|
||||
|
||||
```
|
||||
qmk pytest -t qmk.tests.test_cli_commands
|
||||
```
|
||||
|
||||
Run single test:
|
||||
|
||||
```
|
||||
qmk pytest -t qmk.tests.test_cli_commands.test_c2json
|
||||
qmk pytest -t qmk.tests.test_qmk_path
|
||||
```
|
||||
|
||||
## `qmk painter-convert-graphics`
|
||||
|
||||
This command converts images to a format usable by QMK, i.e. the QGF File Format. See the [Quantum Painter](quantum_painter.md?id=quantum-painter-cli) documentation for more information on this command.
|
||||
This command converts images to a format usable by QMK, i.e. the QGF File Format. See the [Quantum Painter](quantum_painter#quantum-painter-cli) documentation for more information on this command.
|
||||
|
||||
## `qmk painter-make-font-image`
|
||||
|
||||
This command converts a TTF font to an intermediate format for editing, before converting to the QFF File Format. See the [Quantum Painter](quantum_painter.md?id=quantum-painter-cli) documentation for more information on this command.
|
||||
This command converts a TTF font to an intermediate format for editing, before converting to the QFF File Format. See the [Quantum Painter](quantum_painter#quantum-painter-cli) documentation for more information on this command.
|
||||
|
||||
## `qmk painter-convert-font-image`
|
||||
|
||||
This command converts an intermediate font image to the QFF File Format. See the [Quantum Painter](quantum_painter.md?id=quantum-painter-cli) documentation for more information on this command.
|
||||
This command converts an intermediate font image to the QFF File Format. See the [Quantum Painter](quantum_painter#quantum-painter-cli) documentation for more information on this command.
|
||||
|
||||
## `qmk test-c`
|
||||
|
||||
This command runs the C unit test suite. If you make changes to C code you should ensure this runs successfully.
|
||||
|
||||
**Usage**:
|
||||
|
||||
```
|
||||
qmk test-c [-h] [-t TEST] [-l] [-c] [-e ENV] [-j PARALLEL]
|
||||
|
||||
options:
|
||||
-h, --help show this help message and exit
|
||||
-t TEST, --test TEST Test to run from the available list. Supports wildcard globs. May be passed multiple times.
|
||||
-l, --list List available tests.
|
||||
-c, --clean Remove object files before compiling.
|
||||
-e ENV, --env ENV Set a variable to be passed to make. May be passed multiple times.
|
||||
-j PARALLEL, --parallel PARALLEL
|
||||
Set the number of parallel make jobs; 0 means unlimited.
|
||||
```
|
||||
|
||||
**Examples**:
|
||||
|
||||
Run entire test suite:
|
||||
|
||||
```
|
||||
qmk test-c
|
||||
```
|
||||
|
||||
List available tests:
|
||||
|
||||
```
|
||||
qmk test-c --list
|
||||
```
|
||||
|
||||
Run matching test:
|
||||
|
||||
```
|
||||
qmk test-c --test unicode*
|
||||
```
|
||||
|
||||
Run single test:
|
||||
|
||||
```
|
||||
qmk test-c --test basic
|
||||
```
|
||||
|
@ -43,7 +43,9 @@ user.keymap: None -> default
|
||||
|
||||
The `qmk config` command is used to interact with the underlying configuration. When run with no argument it shows the current configuration. When arguments are supplied they are assumed to be configuration tokens, which are strings containing no spaces with the following form:
|
||||
|
||||
```
|
||||
<subcommand|general|default>[.<key>][=<value>]
|
||||
```
|
||||
|
||||
## Setting Configuration Values
|
||||
|
||||
@ -63,19 +65,27 @@ You can read configuration values for the entire configuration, a single key, or
|
||||
|
||||
### Entire Configuration Example
|
||||
|
||||
```
|
||||
qmk config
|
||||
```
|
||||
|
||||
### Whole Section Example
|
||||
|
||||
```
|
||||
qmk config compile
|
||||
```
|
||||
|
||||
### Single Key Example
|
||||
|
||||
```
|
||||
qmk config compile.keyboard
|
||||
```
|
||||
|
||||
### Multiple Keys Example
|
||||
|
||||
```
|
||||
qmk config user compile.keyboard compile.keymap
|
||||
```
|
||||
|
||||
## Deleting Configuration Values
|
||||
|
||||
|
@ -192,17 +192,23 @@ We use nose2, flake8, and yapf to test, lint, and format code. You can use the `
|
||||
|
||||
### Testing and Linting
|
||||
|
||||
```
|
||||
qmk pytest
|
||||
```
|
||||
|
||||
### Formatting
|
||||
|
||||
```
|
||||
qmk format-python
|
||||
```
|
||||
|
||||
## Formatting Details
|
||||
|
||||
We use [yapf](https://github.com/google/yapf) to automatically format code. Our configuration is in the `[yapf]` section of `setup.cfg`.
|
||||
|
||||
?> Tip- Many editors can use yapf as a plugin to automatically format code as you type.
|
||||
::: tip
|
||||
Many editors can use yapf as a plugin to automatically format code as you type.
|
||||
:::
|
||||
|
||||
## Testing Details
|
||||
|
||||
@ -210,7 +216,9 @@ Our tests can be found in `lib/python/qmk/tests/`. You will find both unit and i
|
||||
|
||||
If your PR does not include a comprehensive set of tests please add comments like this to your code so that other people know where they can help:
|
||||
|
||||
```python
|
||||
# TODO(unassigned/<your_github_username>): Write <unit|integration> tests
|
||||
```
|
||||
|
||||
We use [nose2](https://nose2.readthedocs.io/en/latest/getting_started.html) to run our tests. You can refer to the nose2 documentation for more details on what you can do in your test functions.
|
||||
|
||||
|
@ -10,22 +10,30 @@ There are several ways you can setup tab completion.
|
||||
|
||||
Add this to the end of your `.profile` or `.bashrc`:
|
||||
|
||||
```
|
||||
source ~/qmk_firmware/util/qmk_tab_complete.sh
|
||||
```
|
||||
|
||||
If you put `qmk_firmware` into another location you will need to adjust this path.
|
||||
|
||||
Zsh users will need to load `bashcompinit`. The following can be added to `~/.zshrc` file:
|
||||
|
||||
```
|
||||
autoload -Uz bashcompinit && bashcompinit
|
||||
```
|
||||
|
||||
### System Wide Symlink
|
||||
|
||||
If you want the tab completion available to all users of the system you can add a symlink to the `qmk_tab_complete.sh` script:
|
||||
|
||||
```
|
||||
ln -s ~/qmk_firmware/util/qmk_tab_complete.sh /etc/profile.d/qmk_tab_complete.sh
|
||||
```
|
||||
|
||||
### System Wide Copy
|
||||
|
||||
In some cases a symlink may not work. Instead you can copy the file directly into place. Be aware that updates to the tab complete script may happen from time to time, you will want to recopy the file periodically.
|
||||
|
||||
```
|
||||
cp util/qmk_tab_complete.sh /etc/profile.d
|
||||
```
|
||||
|
@ -15,7 +15,7 @@ Most of our style follows PEP8 with some local modifications to make things less
|
||||
|
||||
# YAPF
|
||||
|
||||
You can use [yapf](https://github.com/google/yapf) to style your code. We provide a config in [setup.cfg](setup.cfg).
|
||||
You can use [yapf](https://github.com/google/yapf) to style your code. We provide a config in [setup.cfg](https://github.com/qmk/qmk_firmware/blob/master/setup.cfg).
|
||||
|
||||
# Imports
|
||||
|
||||
|
@ -73,7 +73,7 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s
|
||||
|
||||
* [RP2040](https://www.raspberrypi.com/documentation/microcontrollers/rp2040.html)
|
||||
|
||||
For a detailed overview about the RP2040 support by QMK see the [dedicated RP2040 page](platformdev_rp2040.md).
|
||||
For a detailed overview about the RP2040 support by QMK see the [dedicated RP2040 page](platformdev_rp2040).
|
||||
|
||||
## Atmel ATSAM
|
||||
|
||||
|
@ -6,11 +6,13 @@ There are three main types of configuration files in QMK:
|
||||
|
||||
* `config.h`, which contains various preprocessor directives (`#define`, `#ifdef`)
|
||||
* `rules.mk`, which contains additional variables
|
||||
* `info.json`, which is utilized for [data-driven configuration](https://docs.qmk.fm/#/data_driven_config)
|
||||
* `info.json`, which is utilized for [data-driven configuration](data_driven_config)
|
||||
|
||||
This page will only discuss the first two types, `config.h` and `rules.mk`.
|
||||
|
||||
?> 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](https://docs.qmk.fm/#/reference_info_json) page for more details.
|
||||
::: 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](reference_info_json) 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:
|
||||
|
||||
@ -56,10 +58,10 @@ This is a C header file that is one of the first things included, and will persi
|
||||
* the number of columns in your keyboard's matrix
|
||||
* `#define MATRIX_ROW_PINS { D0, D5, B5, B6 }`
|
||||
* pins of the rows, from top to bottom
|
||||
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions.md?id=low-level-matrix-overrides) for more information.
|
||||
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions#low-level-matrix-overrides) for more information.
|
||||
* `#define MATRIX_COL_PINS { F1, F0, B0, C7, F4, F5, F6, F7, D4, D6, B4, D7 }`
|
||||
* pins of the columns, from left to right
|
||||
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions.md?id=low-level-matrix-overrides) for more information.
|
||||
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions#low-level-matrix-overrides) for more information.
|
||||
* `#define MATRIX_IO_DELAY 30`
|
||||
* the delay in microseconds when between changing matrix pin state and reading values
|
||||
* `#define MATRIX_HAS_GHOST`
|
||||
@ -151,26 +153,26 @@ If you define these options you will enable the associated feature, which may in
|
||||
* enables handling for per key `TAPPING_TERM` settings
|
||||
* `#define RETRO_TAPPING`
|
||||
* tap anyway, even after `TAPPING_TERM`, if there was no other key interruption between press and release
|
||||
* See [Retro Tapping](tap_hold.md#retro-tapping) for details
|
||||
* See [Retro Tapping](tap_hold#retro-tapping) for details
|
||||
* `#define RETRO_TAPPING_PER_KEY`
|
||||
* enables handling for per key `RETRO_TAPPING` settings
|
||||
* `#define TAPPING_TOGGLE 2`
|
||||
* how many taps before triggering the toggle
|
||||
* `#define PERMISSIVE_HOLD`
|
||||
* makes tap and hold keys trigger the hold if another key is pressed before releasing, even if it hasn't hit the `TAPPING_TERM`
|
||||
* See [Permissive Hold](tap_hold.md#permissive-hold) for details
|
||||
* See [Permissive Hold](tap_hold#permissive-hold) for details
|
||||
* `#define PERMISSIVE_HOLD_PER_KEY`
|
||||
* enabled handling for per key `PERMISSIVE_HOLD` settings
|
||||
* `#define QUICK_TAP_TERM 100`
|
||||
* tap-then-hold timing to use a dual role key to repeat keycode
|
||||
* See [Quick Tap Term](tap_hold.md#quick-tap-term)
|
||||
* See [Quick Tap Term](tap_hold#quick-tap-term)
|
||||
* Changes the timing of Tap Toggle functionality (`TT` or the One Shot Tap Toggle)
|
||||
* Defaults to `TAPPING_TERM` if not defined
|
||||
* `#define QUICK_TAP_TERM_PER_KEY`
|
||||
* enables handling for per key `QUICK_TAP_TERM` settings
|
||||
* `#define HOLD_ON_OTHER_KEY_PRESS`
|
||||
* selects the hold action of a dual-role key as soon as the tap of the dual-role key is interrupted by the press of another key.
|
||||
* See "[hold on other key press](tap_hold.md#hold-on-other-key-press)" for details
|
||||
* See "[hold on other key press](tap_hold#hold-on-other-key-press)" for details
|
||||
* `#define HOLD_ON_OTHER_KEY_PRESS_PER_KEY`
|
||||
* enables handling for per key `HOLD_ON_OTHER_KEY_PRESS` settings
|
||||
* `#define LEADER_TIMEOUT 300`
|
||||
@ -205,7 +207,7 @@ If you define these options you will enable the associated feature, which may in
|
||||
* `#define TAP_HOLD_CAPS_DELAY 80`
|
||||
* Sets the delay for Tap Hold keys (`LT`, `MT`) when using `KC_CAPS_LOCK` keycode, as this has some special handling on MacOS. The value is in milliseconds, and defaults to 80 ms if not defined. For macOS, you may want to set this to 200 or higher.
|
||||
* `#define KEY_OVERRIDE_REPEAT_DELAY 500`
|
||||
* Sets the key repeat interval for [key overrides](feature_key_overrides.md).
|
||||
* Sets the key repeat interval for [key overrides](features/key_overrides).
|
||||
* `#define LEGACY_MAGIC_HANDLING`
|
||||
* Enables magic configuration handling for advanced keycodes (such as Mod Tap and Layer Tap)
|
||||
|
||||
@ -215,14 +217,14 @@ If you define these options you will enable the associated feature, which may in
|
||||
* `#define WS2812_DI_PIN D7`
|
||||
* pin the DI on the WS2812 is hooked-up to
|
||||
* `#define RGBLIGHT_LAYERS`
|
||||
* Lets you define [lighting layers](feature_rgblight.md?id=lighting-layers) that can be toggled on or off. Great for showing the current keyboard layer or caps lock state.
|
||||
* Lets you define [lighting layers](features/rgblight#lighting-layers) that can be toggled on or off. Great for showing the current keyboard layer or caps lock state.
|
||||
* `#define RGBLIGHT_MAX_LAYERS`
|
||||
* Defaults to 8. Can be expanded up to 32 if more [lighting layers](feature_rgblight.md?id=lighting-layers) are needed.
|
||||
* Defaults to 8. Can be expanded up to 32 if more [lighting layers](features/rgblight#lighting-layers) are needed.
|
||||
* Note: Increasing the maximum will increase the firmware size and slow sync on split keyboards.
|
||||
* `#define RGBLIGHT_LAYER_BLINK`
|
||||
* Adds ability to [blink](feature_rgblight.md?id=lighting-layer-blink) a lighting layer for a specified number of milliseconds (e.g. to acknowledge an action).
|
||||
* Adds ability to [blink](features/rgblight#lighting-layer-blink) a lighting layer for a specified number of milliseconds (e.g. to acknowledge an action).
|
||||
* `#define RGBLIGHT_LAYERS_OVERRIDE_RGB_OFF`
|
||||
* If defined, then [lighting layers](feature_rgblight?id=overriding-rgb-lighting-onoff-status) will be shown even if RGB Light is off.
|
||||
* If defined, then [lighting layers](features/rgblight#overriding-rgb-lighting-onoff-status) will be shown even if RGB Light is off.
|
||||
* `#define RGBLIGHT_LED_COUNT 12`
|
||||
* number of LEDs
|
||||
* `#define RGBLIGHT_SPLIT`
|
||||
@ -237,7 +239,7 @@ If you define these options you will enable the associated feature, which may in
|
||||
* units to step when in/decreasing saturation
|
||||
* `#define RGBLIGHT_VAL_STEP 12`
|
||||
* units to step when in/decreasing value (brightness)
|
||||
* `#define RGBW`
|
||||
* `#define WS2812_RGBW`
|
||||
* Enables RGBW LED support
|
||||
|
||||
## Mouse Key Options
|
||||
@ -294,7 +296,7 @@ There are a few different ways to set handedness for split keyboards (listed in
|
||||
* `#define MATRIX_ROW_PINS_RIGHT { <row pins> }`
|
||||
* `#define MATRIX_COL_PINS_RIGHT { <col pins> }`
|
||||
* If you want to specify a different pinout for the right half than the left half, you can define `MATRIX_ROW_PINS_RIGHT`/`MATRIX_COL_PINS_RIGHT`. Currently, the size of `MATRIX_ROW_PINS` must be the same as `MATRIX_ROW_PINS_RIGHT` and likewise for the definition of columns.
|
||||
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions.md?id=low-level-matrix-overrides) for more information.
|
||||
* may be omitted by the keyboard designer if matrix reads are handled in an alternate manner. See [low-level matrix overrides](custom_quantum_functions#low-level-matrix-overrides) for more information.
|
||||
|
||||
* `#define DIRECT_PINS_RIGHT { { F1, F0, B0, C7 }, { F4, F5, F6, F7 } }`
|
||||
* If you want to specify a different direct pinout for the right half than the left half, you can define `DIRECT_PINS_RIGHT`. Currently, the size of `DIRECT_PINS` must be the same as `DIRECT_PINS_RIGHT`.
|
||||
@ -356,7 +358,7 @@ There are a few different ways to set handedness for split keyboards (listed in
|
||||
|
||||
* `#define SPLIT_TRANSACTION_IDS_KB .....`
|
||||
* `#define SPLIT_TRANSACTION_IDS_USER .....`
|
||||
* Allows for custom data sync with the slave when using the QMK-provided split transport. See [custom data sync between sides](feature_split_keyboard.md#custom-data-sync) for more information.
|
||||
* Allows for custom data sync with the slave when using the QMK-provided split transport. See [custom data sync between sides](features/split_keyboard#custom-data-sync) for more information.
|
||||
|
||||
# The `rules.mk` File
|
||||
|
||||
@ -385,7 +387,7 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
|
||||
... a.o c.o ... lib_b.a lib_d.a ...
|
||||
```
|
||||
* `LAYOUTS`
|
||||
* A list of [layouts](feature_layouts.md) this keyboard supports.
|
||||
* A list of [layouts](feature_layouts) this keyboard supports.
|
||||
* `LTO_ENABLE`
|
||||
* Enables Link Time Optimization (LTO) when compiling the keyboard. This makes the process take longer, but it can significantly reduce the compiled size (and since the firmware is small, the added time is not noticeable).
|
||||
|
||||
@ -404,7 +406,7 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
|
||||
* `bootloadhid`
|
||||
* `usbasploader`
|
||||
|
||||
## Feature Options :id=feature-options
|
||||
## Feature 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.
|
||||
|
||||
@ -446,12 +448,12 @@ Use these to enable or disable building certain features. The more you have enab
|
||||
* Allows replacing the standard matrix scanning routine with a custom one.
|
||||
* `DEBOUNCE_TYPE`
|
||||
* Allows replacing the standard key debouncing routine with an alternative or custom one.
|
||||
* `WAIT_FOR_USB`
|
||||
* `USB_WAIT_FOR_ENUMERATION`
|
||||
* Forces the keyboard to wait for a USB connection to be established before it starts up
|
||||
* `NO_USB_STARTUP_CHECK`
|
||||
* Disables usb suspend check after keyboard startup. Usually the keyboard waits for the host to wake it up before any tasks are performed. This is useful for split keyboards as one half will not get a wakeup call but must send commands to the master.
|
||||
* `DEFERRED_EXEC_ENABLE`
|
||||
* Enables deferred executor support -- timed delays before callbacks are invoked. See [deferred execution](custom_quantum_functions.md#deferred-execution) for more information.
|
||||
* Enables deferred executor support -- timed delays before callbacks are invoked. See [deferred execution](custom_quantum_functions#deferred-execution) for more information.
|
||||
* `DYNAMIC_TAPPING_TERM_ENABLE`
|
||||
* Allows to configure the global tapping term on the fly.
|
||||
|
||||
|
@ -1,9 +1,9 @@
|
||||
# Adding Default Keymaps to QMK Configurator :id=adding-default-keymaps
|
||||
# Adding Default Keymaps to QMK Configurator {#adding-default-keymaps}
|
||||
|
||||
This page covers how to add a default keymap for a keyboard to QMK Configurator.
|
||||
|
||||
|
||||
## Technical Information :id=technical-information
|
||||
## Technical Information {#technical-information}
|
||||
|
||||
QMK Configurator uses JSON as its native file format for keymaps. As much as possible, these should be kept such that they behave the same as running `make <keyboard>:default` from `qmk_firmware`.
|
||||
|
||||
@ -27,7 +27,7 @@ f14629ed1cd7c7ec9089604d64f29a99981558e8 Remove/migrate action_get_macro()s from
|
||||
In this example, `f14629ed1cd7c7ec9089604d64f29a99981558e8` is the value that should be used for `commit`.
|
||||
|
||||
|
||||
## Example :id=example
|
||||
## Example {#example}
|
||||
|
||||
If one wished to add a default keymap for the H87a by Hineybush, one would run the `git log` command above against the H87a's default keymap in `qmk_firmware`:
|
||||
|
||||
@ -96,9 +96,9 @@ The default keymap uses the `LAYOUT_all` macro, so that will be the value of the
|
||||
The white space in the `layers` arrays have no effect on the functionality of the keymap, but are used to make these files easier for humans to read.
|
||||
|
||||
|
||||
## Caveats :id=caveats
|
||||
## Caveats {#caveats}
|
||||
|
||||
### Layers can only be referenced by number :id=layer-references
|
||||
### Layers can only be referenced by number {#layer-references}
|
||||
|
||||
A common QMK convention is to name layers using a series of `#define`s, or an `enum` statement:
|
||||
|
||||
@ -112,11 +112,11 @@ enum layer_names {
|
||||
|
||||
This works in C, but for Configurator, you *must* use the layer's numeric index – `MO(_FN)` would need to be `MO(2)` in the above example.
|
||||
|
||||
### No support for custom code of any kind :id=custom-code
|
||||
### No support for custom code of any kind {#custom-code}
|
||||
|
||||
Features that require adding functions to the keymap.c file, such as Tap Dance or Unicode, can not be compiled in Configurator **at all**. Even setting `TAP_DANCE_ENABLE = yes` in the `qmk_firmware` repository at the keyboard level will prevent Configurator from compiling **any** firmware for that keyboard. This is limited both by the API and the current spec of our JSON keymap format.
|
||||
|
||||
### Limited Support for Custom keycodes :id=custom-keycodes
|
||||
### Limited Support for Custom keycodes {#custom-keycodes}
|
||||
|
||||
There is a way to support custom keycodes: if the logic for a custom keycode is implemented at the keyboard level instead of the keymap level in qmk_firmware, that keycode *can* be used in Configurator and it *will* compile and work. Instead of using the following in your `keymap.c`:
|
||||
|
||||
@ -186,6 +186,6 @@ bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
|
||||
|
||||
Note the call to `process_record_user()` at the end.
|
||||
|
||||
## Additional Reading :id=additional-reading
|
||||
## Additional Reading {#additional-reading}
|
||||
|
||||
For QMK Configurator to support your keyboard, your keyboard must be present in the `master` branch of the `qmk_firmware` repository. For instructions on this, please see [Supporting Your Keyboard in QMK Configurator](reference_configurator_support.md).
|
||||
For QMK Configurator to support your keyboard, your keyboard must be present in the `master` branch of the `qmk_firmware` repository. For instructions on this, please see [Supporting Your Keyboard in QMK Configurator](reference_configurator_support).
|
||||
|
@ -6,25 +6,35 @@ This page describes the steps for building your firmware in QMK Configurator.
|
||||
|
||||
Click the drop down box and select the keyboard you want to create a keymap for.
|
||||
|
||||
?> If your keyboard has several versions, make sure you select the correct one.
|
||||
::: tip
|
||||
If your keyboard has several versions, make sure you select the correct one.
|
||||
:::
|
||||
|
||||
I'll say that again because it's important:
|
||||
|
||||
!> **MAKE SURE YOU SELECT THE RIGHT VERSION!**
|
||||
::: warning
|
||||
**MAKE SURE YOU SELECT THE RIGHT VERSION!**
|
||||
:::
|
||||
|
||||
If your keyboard has been advertised to be powered by QMK but is not in the list, chances are a developer hasn't gotten to it yet or we haven't had a chance to merge it in yet. File an issue at [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) requesting to support that particular keyboard, if there is no active [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) for it. There are also QMK powered keyboards that are in their manufacturer's own GitHub accounts. Double check for that as well. <!-- FIXME(skullydazed): This feels too wordy and I'm not sure we want to encourage these kinds of issues. Also, should we prompt them to bug the manufacutrer? -->
|
||||
Unfortunately if your keyboard has been advertised to be powered by QMK but is not in the list, you will **not** be able to use Configurator to customize your keyboard.
|
||||
|
||||
Chances are a developer hasn't gotten round to adding support or we haven't had a chance to merge it in yet. If there is no active [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard), contact the manufacturer and encourage them to add support.
|
||||
|
||||
## Step 2: Select Your Keyboard Layout
|
||||
|
||||
Choose the layout that best represents the keymap you want to create. Some keyboards do not have enough layouts or correct layouts defined yet. They will be supported in the future.
|
||||
|
||||
!> Sometimes there isn't a layout that supports your exact build. In that case select `LAYOUT_all`.
|
||||
::: warning
|
||||
Sometimes there isn't a layout that supports your exact build. In that case select `LAYOUT_all`.
|
||||
:::
|
||||
|
||||
## Step 3: Name Your Keymap
|
||||
|
||||
Call this keymap what you want.
|
||||
|
||||
?> If you are running into issues when compiling, it may be worth changing this name, as it may already exist in the QMK Firmware repo.
|
||||
::: tip
|
||||
If you are running into issues when compiling, it may be worth changing this name, as it may already exist in the QMK Firmware repo.
|
||||
:::
|
||||
|
||||
## Step 4: Define Your Keymap
|
||||
|
||||
@ -34,18 +44,24 @@ Keycode Entry is accomplished in one of 3 ways:
|
||||
2. Clicking on an empty spot on the layout, then clicking the keycode you desire
|
||||
3. Clicking on an empty spot on the layout, then pressing the physical key on your keyboard
|
||||
|
||||
?> Hover your mouse over a key and a short blurb will tell you what that keycode does. For a more verbose description please see:
|
||||
::: tip
|
||||
Hover your mouse over a key and a short blurb will tell you what that keycode does. For a more verbose description please see:
|
||||
:::
|
||||
|
||||
* [Basic Keycode Reference](keycodes_basic.md)
|
||||
* [Advanced Keycode Reference](feature_advanced_keycodes.md)
|
||||
* [Basic Keycode Reference](keycodes_basic)
|
||||
* [Advanced Keycode Reference](feature_advanced_keycodes)
|
||||
|
||||
!> If your selected layout doesn't match your physical build leave the unused keys blank. If you're not sure which key is in use, for example you have a one backspace key but `LAYOUT_all` has 2 keys, put the same keycode in both locations.
|
||||
::: warning
|
||||
If your selected layout doesn't match your physical build leave the unused keys blank. If you're not sure which key is in use, for example you have a one backspace key but `LAYOUT_all` has 2 keys, put the same keycode in both locations.
|
||||
:::
|
||||
|
||||
## Step 5: Save Your Keymap for Future Changes
|
||||
|
||||
When you're satisfied with your keymap or just want to work on it later, press the `Download this QMK Keymap JSON File` button. It will save your keymap to your computer. You can then load this .json file in the future by pressing the `Upload a QMK Keymap JSON File` button.
|
||||
|
||||
!> **CAUTION:** This is not the same type of .json file used for kbfirmware.com or any other tool. If you try to use this for those tools, or the .json from those tools with QMK Configurator, you will encounter problems.
|
||||
::: warning
|
||||
**CAUTION:** This is not the same type of .json file used for kbfirmware.com or any other tool. If you try to use this for those tools, or the .json from those tools with QMK Configurator, you will encounter problems.
|
||||
:::
|
||||
|
||||
## Step 6: Compile Your Firmware File
|
||||
|
||||
@ -55,4 +71,4 @@ When the compilation is done, you will be able to press the green `Download Firm
|
||||
|
||||
## Next steps: Flashing Your Keyboard
|
||||
|
||||
Please refer to [Flashing Firmware](newbs_flashing.md).
|
||||
Please refer to [Flashing Firmware](newbs_flashing).
|
||||
|
@ -14,8 +14,8 @@ If you're referring to having three spots for space bar, the best course of acti
|
||||
|
||||
Please see:
|
||||
|
||||
* [Basic Keycode Reference](keycodes_basic.md)
|
||||
* [Advanced Keycode Reference](feature_advanced_keycodes.md)
|
||||
* [Basic Keycode Reference](keycodes_basic)
|
||||
* [Advanced Keycode Reference](feature_advanced_keycodes)
|
||||
|
||||
## It won't compile
|
||||
|
||||
|
@ -56,8 +56,8 @@ Never made an open source contribution before? Wondering how contributions work
|
||||
|
||||
Most of our style is pretty easy to pick up on. If you are familiar with either C or Python you should not have too much trouble with our local styles.
|
||||
|
||||
* [Coding Conventions - C](coding_conventions_c.md)
|
||||
* [Coding Conventions - Python](coding_conventions_python.md)
|
||||
* [Coding Conventions - C](coding_conventions_c)
|
||||
* [Coding Conventions - Python](coding_conventions_python)
|
||||
|
||||
# General Guidelines
|
||||
|
||||
@ -101,17 +101,15 @@ enum my_keycodes {
|
||||
};
|
||||
```
|
||||
|
||||
### Previewing the Documentation :id=previewing-the-documentation
|
||||
### Previewing the Documentation {#previewing-the-documentation}
|
||||
|
||||
Before opening a pull request, you can preview your changes if you have set up the development environment by running this command from the `qmk_firmware/` folder:
|
||||
|
||||
```
|
||||
qmk docs
|
||||
```
|
||||
|
||||
or if you only have Python 3 installed:
|
||||
|
||||
python3 -m http.server 8936 --directory docs
|
||||
|
||||
and navigating to `http://localhost:8936/`.
|
||||
and navigating to `http://localhost:5173/`.
|
||||
|
||||
## Keyboards
|
||||
|
||||
@ -119,7 +117,7 @@ Keyboards are the raison d'être for QMK. Some keyboards are community maintaine
|
||||
|
||||
We also ask that you follow these guidelines:
|
||||
|
||||
* Write a `readme.md` using [the template](documentation_templates.md).
|
||||
* Write a `readme.md` using [the template](documentation_templates).
|
||||
* Include a `default` keymap that provides a clean slate for users to start with when creating their own keymaps.
|
||||
* Do not lump core features in with new keyboards. Submit the feature first and then submit a separate PR for the keyboard.
|
||||
* Name `.c`/`.h` file after the immediate parent folder, eg `/keyboards/<kb1>/<kb2>/<kb2>.[ch]`
|
||||
@ -128,7 +126,7 @@ We also ask that you follow these guidelines:
|
||||
|
||||
## Quantum/TMK Core
|
||||
|
||||
Before you put a lot of work into building your new feature you should make sure you are implementing it in the best way. You can get a basic understanding of QMK by reading [Understanding QMK](understanding_qmk.md), which will take you on a tour of the QMK program flow. From here you should talk to us to get a sense of the best way to implement your idea. There are two main ways to do this:
|
||||
Before you put a lot of work into building your new feature you should make sure you are implementing it in the best way. You can get a basic understanding of QMK by reading [Understanding QMK](understanding_qmk), which will take you on a tour of the QMK program flow. From here you should talk to us to get a sense of the best way to implement your idea. There are two main ways to do this:
|
||||
|
||||
* [Chat on Discord](https://discord.gg/Uq7gcHh)
|
||||
* [Open an Issue](https://github.com/qmk/qmk_firmware/issues/new)
|
||||
@ -146,7 +144,7 @@ We also ask that you follow these guidelines:
|
||||
|
||||
* Keep the number of commits reasonable or we will squash your PR
|
||||
* Do not lump keyboards or keymaps in with core changes. Submit your core changes first.
|
||||
* Write [Unit Tests](unit_testing.md) for your feature
|
||||
* Write [Unit Tests](unit_testing) for your feature
|
||||
* Follow the style of the file you are editing. If the style is unclear or there are mixed styles you should conform to the [coding conventions](#coding-conventions) above.
|
||||
|
||||
## Refactoring
|
||||
|
@ -2,9 +2,9 @@
|
||||
|
||||
For a lot of people a custom keyboard is about more than sending button presses to your computer. You want to be able to do things that are more complex than simple button presses and macros. QMK has hooks that allow you to inject code, override functionality, and otherwise customize how your keyboard behaves in different situations.
|
||||
|
||||
This page does not assume any special knowledge about QMK, but reading [Understanding QMK](understanding_qmk.md) will help you understand what is going on at a more fundamental level.
|
||||
This page does not assume any special knowledge about QMK, but reading [Understanding QMK](understanding_qmk) will help you understand what is going on at a more fundamental level.
|
||||
|
||||
## A Word on Core vs Keyboards vs Keymap :id=a-word-on-core-vs-keyboards-vs-keymap
|
||||
## A Word on Core vs Keyboards vs Keymap {#a-word-on-core-vs-keyboards-vs-keymap}
|
||||
|
||||
We have structured QMK as a hierarchy:
|
||||
|
||||
@ -34,7 +34,7 @@ enum my_keycodes {
|
||||
};
|
||||
```
|
||||
|
||||
## Programming the Behavior of Any Keycode :id=programming-the-behavior-of-any-keycode
|
||||
## Programming the Behavior of Any Keycode {#programming-the-behavior-of-any-keycode}
|
||||
|
||||
When you want to override the behavior of an existing key, or define the behavior for a new key, you should use the `process_record_kb()` and `process_record_user()` functions. These are called by QMK during key processing before the actual key event is handled. If these functions return `true` QMK will process the keycodes as usual. That can be handy for extending the functionality of a key rather than replacing it. If these functions return `false` QMK will skip the normal key handling, and it will be up to you to send any key up or down events that are required.
|
||||
|
||||
@ -98,7 +98,9 @@ These are the three main initialization functions, listed in the order that they
|
||||
* `matrix_init_*` - Happens midway through the firmware's startup process. Hardware is initialized, but features may not be yet.
|
||||
* `keyboard_post_init_*` - Happens at the end of the firmware's startup process. This is where you'd want to put "customization" code, for the most part.
|
||||
|
||||
!> For most people, the `keyboard_post_init_user` function is what you want to call. For instance, this is where you want to set up things for RGB Underglow.
|
||||
::: warning
|
||||
For most people, the `keyboard_post_init_user` function is what you want to call. For instance, this is where you want to set up things for RGB Underglow.
|
||||
:::
|
||||
|
||||
## Keyboard Pre Initialization code
|
||||
|
||||
@ -144,7 +146,7 @@ This is useful for setting up stuff that you may need elsewhere, but isn't hardw
|
||||
* Keyboard/Revision: `void matrix_init_kb(void)`
|
||||
* Keymap: `void matrix_init_user(void)`
|
||||
|
||||
### Low-level Matrix Overrides Function Documentation :id=low-level-matrix-overrides
|
||||
### Low-level Matrix Overrides Function Documentation {#low-level-matrix-overrides}
|
||||
|
||||
* GPIO pin initialisation: `void matrix_init_pins(void)`
|
||||
* This needs to perform the low-level initialisation of all row and column pins. By default this will initialise the input/output state of each of the GPIO pins listed in `MATRIX_ROW_PINS` and `MATRIX_COL_PINS`, based on whether or not the keyboard is set up for `ROW2COL`, `COL2ROW`, or `DIRECT_PINS`. Should the keyboard designer override this function, no initialisation of pin state will occur within QMK itself, instead deferring to the keyboard's override.
|
||||
@ -204,7 +206,7 @@ Similar to `matrix_scan_*`, these are called as often as the MCU can handle. To
|
||||
|
||||
### Example `void housekeeping_task_user(void)` implementation
|
||||
|
||||
This example will show you how to use `void housekeeping_task_user(void)` to turn off [RGB Light](feature_rgblight.md). For RGB Matrix, the [builtin](https://docs.qmk.fm/#/feature_rgb_matrix?id=additional-configh-options) `RGB_MATRIX_TIMEOUT` should be used.
|
||||
This example will show you how to use `void housekeeping_task_user(void)` to turn off [RGB Light](features/rgblight). For RGB Matrix, the [builtin](features/rgb_matrix#additional-configh-options) `RGB_MATRIX_TIMEOUT` should be used.
|
||||
|
||||
First, add the following lines to your keymap's `config.h`:
|
||||
|
||||
@ -284,7 +286,7 @@ void suspend_wakeup_init_user(void) {
|
||||
* Keymap: `void suspend_power_down_kb(void)` and `void suspend_wakeup_init_user(void)`
|
||||
|
||||
|
||||
# Keyboard Shutdown/Reboot Code :id=keyboard-shutdown-reboot-code
|
||||
# Keyboard Shutdown/Reboot Code {#keyboard-shutdown-reboot-code}
|
||||
|
||||
This function gets called whenever the firmware is reset, whether it's a soft reset or reset to the bootloader. This is the spot to use for any sort of cleanup, as this happens right before the actual reset. And it can be useful for turning off different systems (such as RGB, onboard screens, etc).
|
||||
|
||||
@ -296,7 +298,9 @@ If `jump_to_bootloader` is set to `true`, this indicates that the board will be
|
||||
|
||||
As there is a keyboard and user level function, returning `false` for the user function will disable the keyboard level function, allowing for customization.
|
||||
|
||||
?> Bootmagic does not trigger `shutdown_*()` as it happens before most of the initialization process.
|
||||
::: tip
|
||||
Bootmagic does not trigger `shutdown_*()` as it happens before most of the initialization process.
|
||||
:::
|
||||
|
||||
### Example `shutdown_kb()` Implementation
|
||||
|
||||
@ -342,7 +346,7 @@ bool shutdown_user(bool jump_to_bootloader) {
|
||||
* Keyboard/Revision: `bool shutdown_kb(bool jump_to_bootloader)`
|
||||
* Keymap: `bool shutdown_user(bool jump_to_bootloader)`
|
||||
|
||||
# Deferred Execution :id=deferred-execution
|
||||
# Deferred Execution {#deferred-execution}
|
||||
|
||||
QMK has the ability to execute a callback after a specified period of time, rather than having to manually manage timers. To enable this functionality, set `DEFERRED_EXEC_ENABLE = yes` in rules.mk.
|
||||
|
||||
@ -364,7 +368,9 @@ The second argument `cb_arg` is the same argument passed into `defer_exec()` bel
|
||||
|
||||
The return value is the number of milliseconds to use if the function should be repeated -- if the callback returns `0` then it's automatically unregistered. In the example above, a hypothetical `my_deferred_functionality()` is invoked to determine if the callback needs to be repeated -- if it does, it reschedules for a `500` millisecond delay, otherwise it informs the deferred execution background task that it's done, by returning `0`.
|
||||
|
||||
?> Note that the returned delay will be applied to the intended trigger time, not the time of callback invocation. This allows for generally consistent timing even in the face of occasional late execution.
|
||||
::: tip
|
||||
Note that the returned delay will be applied to the intended trigger time, not the time of callback invocation. This allows for generally consistent timing even in the face of occasional late execution.
|
||||
:::
|
||||
|
||||
## Deferred executor registration
|
||||
|
||||
@ -408,14 +414,14 @@ If registrations fail, then you can increase this value in your keyboard or keym
|
||||
#define MAX_DEFERRED_EXECUTORS 16
|
||||
```
|
||||
|
||||
# Advanced topics :id=advanced-topics
|
||||
# Advanced topics {#advanced-topics}
|
||||
|
||||
This page used to encompass a large set of features. We have moved many sections that used to be part of this page to their own pages. Everything below this point is simply a redirect so that people following old links on the web find what they're looking for.
|
||||
|
||||
## Layer Change Code :id=layer-change-code
|
||||
## Layer Change Code {#layer-change-code}
|
||||
|
||||
[Layer change code](feature_layers.md#layer-change-code)
|
||||
[Layer change code](feature_layers#layer-change-code)
|
||||
|
||||
## Persistent Configuration (EEPROM) :id=persistent-configuration-eeprom
|
||||
## Persistent Configuration (EEPROM) {#persistent-configuration-eeprom}
|
||||
|
||||
[Persistent Configuration (EEPROM)](feature_eeprom.md)
|
||||
[Persistent Configuration (EEPROM)](feature_eeprom)
|
||||
|
@ -4,7 +4,7 @@ This page describes how QMK's data driven JSON configuration system works. It is
|
||||
|
||||
## History
|
||||
|
||||
Historically QMK has been configured through a combination of two mechanisms- `rules.mk` and `config.h`. While this worked well when QMK was only a handful of keyboards we've grown to encompass nearly 1500 supported keyboards. That extrapolates out to 6000 configuration files under `keyboards/` 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.
|
||||
Historically QMK has been configured through a combination of two mechanisms- `rules.mk` and `config.h`. 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 `keyboards/` 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.
|
||||
|
||||
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 `info.json` as a first step towards this. The QMK API is an effort to combine these 3 sources of information- `config.h`, `rules.mk`, and `info.json`- into a single source of truth that end-user tools can use.
|
||||
|
||||
@ -75,7 +75,7 @@ Whenever QMK generates a complete `info.json` it extracts information from `conf
|
||||
|
||||
If you are not sure how to edit this file or are not comfortable with Python [open an issue](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=) or [join #cli on Discord](https://discord.gg/heQPAgy) and someone can help you with this part.
|
||||
|
||||
### Add code to generate it :id=add-code-to-generate-it
|
||||
### Add code to generate it {#add-code-to-generate-it}
|
||||
|
||||
The final piece of the puzzle is providing your new option to the build system. This is done by generating two files:
|
||||
|
||||
|
@ -25,22 +25,30 @@ You can have styled hint blocks drawn around text to draw attention to it.
|
||||
### Important
|
||||
|
||||
```
|
||||
!> This is important
|
||||
::: warning
|
||||
This is important
|
||||
:::
|
||||
```
|
||||
|
||||
Renders as:
|
||||
|
||||
!> This is important
|
||||
::: warning
|
||||
This is important
|
||||
:::
|
||||
|
||||
### General Tips
|
||||
|
||||
```
|
||||
?> This is a helpful tip.
|
||||
::: tip
|
||||
This is a helpful tip.
|
||||
:::
|
||||
```
|
||||
|
||||
Renders as:
|
||||
|
||||
?> This is a helpful tip.
|
||||
::: tip
|
||||
This is a helpful tip.
|
||||
:::
|
||||
|
||||
|
||||
# Documenting Features
|
||||
@ -61,4 +69,4 @@ This page describes my cool feature. You can use my cool feature to make coffee
|
||||
|KC_SUGAR||Order Sugar|
|
||||
```
|
||||
|
||||
Place your documentation into `docs/feature_<my_cool_feature>.md`, and add that file to the appropriate place in `docs/_summary.md`. If you have added any keycodes be sure to add them to `docs/keycodes.md` with a link back to your feature page.
|
||||
Place your documentation into `docs/features/<my_cool_feature>.md`, and add that file to the appropriate place in `docs/_sidebar.json`. If you have added any keycodes be sure to add them to `docs/keycodes.md` with a link back to your feature page.
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
This page documents the templates you should use when submitting new Keymaps and Keyboards to QMK.
|
||||
|
||||
## Keymap `readme.md` Template :id=keyboard-readmemd-template
|
||||
## Keymap `readme.md` Template {#keyboard-readmemd-template}
|
||||
|
||||
Most keymaps have an image depicting the layout. You can use [Keyboard Layout Editor](http://keyboard-layout-editor.com) to create an image. Upload it to [Imgur](https://imgur.com) or another hosting service, please do not include images in your Pull Request.
|
||||
|
||||
@ -40,7 +40,7 @@ Flashing example for this keyboard:
|
||||
|
||||
make planck/rev4:default:flash
|
||||
|
||||
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
|
||||
See the [build environment setup](getting_started_build_tools) and the [make instructions](getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](newbs).
|
||||
|
||||
## Bootloader
|
||||
|
||||
|
@ -8,15 +8,17 @@ We recommend the use of the [Zadig](https://zadig.akeo.ie/) utility. If you have
|
||||
|
||||
## Installation
|
||||
|
||||
Put your keyboard into bootloader mode, either by hitting the `QK_BOOT` keycode (which may be on a different layer), or by pressing the reset switch that's usually located on the underside of the board. If your keyboard has neither, try holding Escape or Space+`B` as you plug it in (see the [Bootmagic Lite](feature_bootmagic.md) docs for more details). Some boards use [Command](feature_command.md) instead of Bootmagic; in this case, you can enter bootloader mode by hitting Left Shift+Right Shift+`B` or Left Shift+Right Shift+Escape at any point while the keyboard is plugged in.
|
||||
Some keyboards may have specific instructions for entering the bootloader. For example, the [Bootmagic Lite](feature_bootmagic.md) key (default: Escape) might be on a different key, e.g. Left Control; or the magic combination for Command (default: Left Shift+Right Shift) might require you to hold something else, e.g. Left Control+Right Control. Refer to the board's README file if you are unsure.
|
||||
Put your keyboard into bootloader mode, either by hitting the `QK_BOOT` keycode (which may be on a different layer), or by pressing the reset switch that's usually located on the underside of the board. If your keyboard has neither, try holding Escape or Space+`B` as you plug it in (see the [Bootmagic Lite](features/bootmagic) docs for more details). Some boards use [Command](features/command) instead of Bootmagic; in this case, you can enter bootloader mode by hitting Left Shift+Right Shift+`B` or Left Shift+Right Shift+Escape at any point while the keyboard is plugged in.
|
||||
Some keyboards may have specific instructions for entering the bootloader. For example, the [Bootmagic Lite](features/bootmagic) key (default: Escape) might be on a different key, e.g. Left Control; or the magic combination for Command (default: Left Shift+Right Shift) might require you to hold something else, e.g. Left Control+Right Control. Refer to the board's README file if you are unsure.
|
||||
|
||||
To put a device in bootloader mode with USBaspLoader, tap the `RESET` button while holding down the `BOOT` button.
|
||||
Alternatively, hold `BOOT` while inserting the USB cable.
|
||||
|
||||
Zadig should automatically detect the bootloader device, but you may sometimes need to check **Options → List All Devices** and select the device from the dropdown instead.
|
||||
|
||||
!> If Zadig lists one or more devices with the `HidUsb` driver, your keyboard is probably not in bootloader mode. The arrow will be colored orange and you will be asked to confirm modifying a system driver. **Do not** proceed if this is the case!
|
||||
::: warning
|
||||
If Zadig lists one or more devices with the `HidUsb` driver, your keyboard is probably not in bootloader mode. The arrow will be colored orange and you will be asked to confirm modifying a system driver. **Do not** proceed if this is the case!
|
||||
:::
|
||||
|
||||
If the arrow appears green, select the driver, and click **Install Driver**. See the [list of known bootloaders](#list-of-known-bootloaders) for the correct driver to install.
|
||||
|
||||
@ -40,7 +42,9 @@ Right-click each entry and hit **Uninstall device**. Make sure to tick **Delete
|
||||
|
||||
Click **Action → Scan for hardware changes**. At this point, you should be able to type again. Double check in Zadig that the keyboard device(s) are using the `HidUsb` driver. If so, you're all done, and your board should be functional again! Otherwise, repeat this process until Zadig reports the correct driver.
|
||||
|
||||
?> A full reboot of your computer may sometimes be necessary at this point, to get Windows to pick up the new driver.
|
||||
::: tip
|
||||
A full reboot of your computer may sometimes be necessary at this point, to get Windows to pick up the new driver.
|
||||
:::
|
||||
|
||||
## Uninstallation
|
||||
|
||||
@ -60,7 +64,9 @@ Run `pnputil /delete-driver oemXX.inf /uninstall`. This will delete the driver a
|
||||
|
||||
As with the previous section, this process may need to be repeated multiple times, as multiple drivers can be applicable to the same device.
|
||||
|
||||
!> **WARNING:** Be *extremely careful* when doing this! You could potentially uninstall the driver for some other critical device. If you are unsure, double check the output of `/enum-drivers`, and omit the `/uninstall` flag when running `/delete-driver`.
|
||||
::: warning
|
||||
Be *extremely careful* when doing this! You could potentially uninstall the driver for some other critical device. If you are unsure, double check the output of `/enum-drivers`, and omit the `/uninstall` flag when running `/delete-driver`.
|
||||
:::
|
||||
|
||||
## List of Known Bootloaders
|
||||
|
||||
|
173
docs/drivers/adc.md
Normal file
173
docs/drivers/adc.md
Normal file
@ -0,0 +1,173 @@
|
||||
# ADC Driver
|
||||
|
||||
QMK can leverage the Analog-to-Digital Converter (ADC) on supported MCUs to measure voltages on certain pins. This can be useful for implementing things such as battery level indicators for Bluetooth keyboards, or volume controls using a potentiometer, as opposed to a [rotary encoder](../features/encoders).
|
||||
|
||||
This driver currently supports both AVR and a limited selection of ARM devices. The values returned are 10-bit integers (0-1023) mapped between 0V and VCC (usually 5V or 3.3V for AVR, 3.3V only for ARM), however on ARM there is more flexibility in control of operation through `#define`s if you need more precision.
|
||||
|
||||
## Usage
|
||||
|
||||
To use this driver, add the following to your `rules.mk`:
|
||||
|
||||
```make
|
||||
ANALOG_DRIVER_REQUIRED = yes
|
||||
```
|
||||
|
||||
Then place this include at the top of your code:
|
||||
|
||||
```c
|
||||
#include "analog.h"
|
||||
```
|
||||
|
||||
## Channels
|
||||
|
||||
### AVR
|
||||
|
||||
|Channel|AT90USB64/128|ATmega16/32U4|ATmega32A|ATmega328/P|
|
||||
|-------|-------------|-------------|---------|----------|
|
||||
|0 |`F0` |`F0` |`A0` |`C0` |
|
||||
|1 |`F1` |`F1` |`A1` |`C1` |
|
||||
|2 |`F2` | |`A2` |`C2` |
|
||||
|3 |`F3` | |`A3` |`C3` |
|
||||
|4 |`F4` |`F4` |`A4` |`C4` |
|
||||
|5 |`F5` |`F5` |`A5` |`C5` |
|
||||
|6 |`F6` |`F6` |`A6` |* |
|
||||
|7 |`F7` |`F7` |`A7` |* |
|
||||
|8 | |`D4` | | |
|
||||
|9 | |`D6` | | |
|
||||
|10 | |`D7` | | |
|
||||
|11 | |`B4` | | |
|
||||
|12 | |`B5` | | |
|
||||
|13 | |`B6` | | |
|
||||
|
||||
<sup>\* The ATmega328/P possesses two extra ADC channels; however, they are not present on the DIP pinout, and are not shared with GPIO pins. You can use `adc_read()` directly to gain access to these.</sup>
|
||||
|
||||
### ARM
|
||||
|
||||
#### STM32
|
||||
|
||||
Note that some of these pins are doubled-up on ADCs with the same channel. This is because the pins can be used for either ADC.
|
||||
|
||||
Also note that the F0 and F3 use different numbering schemes. The F0 has a single ADC and the channels are 0-indexed, whereas the F3 has 4 ADCs and the channels are 1-indexed. This is because the F0 uses the `ADCv1` implementation of the ADC, whereas the F3 uses the `ADCv3` implementation.
|
||||
|
||||
|ADC|Channel|STM32F0xx|STM32F1xx|STM32F3xx|STM32F4xx|
|
||||
|---|-------|---------|---------|---------|---------|
|
||||
|1 |0 |`A0` |`A0` | |`A0` |
|
||||
|1 |1 |`A1` |`A1` |`A0` |`A1` |
|
||||
|1 |2 |`A2` |`A2` |`A1` |`A2` |
|
||||
|1 |3 |`A3` |`A3` |`A2` |`A3` |
|
||||
|1 |4 |`A4` |`A4` |`A3` |`A4` |
|
||||
|1 |5 |`A5` |`A5` |`F4` |`A5` |
|
||||
|1 |6 |`A6` |`A6` |`C0` |`A6` |
|
||||
|1 |7 |`A7` |`A7` |`C1` |`A7` |
|
||||
|1 |8 |`B0` |`B0` |`C2` |`B0` |
|
||||
|1 |9 |`B1` |`B1` |`C3` |`B1` |
|
||||
|1 |10 |`C0` |`C0` |`F2` |`C0` |
|
||||
|1 |11 |`C1` |`C1` | |`C1` |
|
||||
|1 |12 |`C2` |`C2` | |`C2` |
|
||||
|1 |13 |`C3` |`C3` | |`C3` |
|
||||
|1 |14 |`C4` |`C4` | |`C4` |
|
||||
|1 |15 |`C5` |`C5` | |`C5` |
|
||||
|1 |16 | | | | |
|
||||
|2 |0 | |`A0`¹ | |`A0`² |
|
||||
|2 |1 | |`A1`¹ |`A4` |`A1`² |
|
||||
|2 |2 | |`A2`¹ |`A5` |`A2`² |
|
||||
|2 |3 | |`A3`¹ |`A6` |`A3`² |
|
||||
|2 |4 | |`A4`¹ |`A7` |`A4`² |
|
||||
|2 |5 | |`A5`¹ |`C4` |`A5`² |
|
||||
|2 |6 | |`A6`¹ |`C0` |`A6`² |
|
||||
|2 |7 | |`A7`¹ |`C1` |`A7`² |
|
||||
|2 |8 | |`B0`¹ |`C2` |`B0`² |
|
||||
|2 |9 | |`B1`¹ |`C3` |`B1`² |
|
||||
|2 |10 | |`C0`¹ |`F2` |`C0`² |
|
||||
|2 |11 | |`C1`¹ |`C5` |`C1`² |
|
||||
|2 |12 | |`C2`¹ |`B2` |`C2`² |
|
||||
|2 |13 | |`C3`¹ | |`C3`² |
|
||||
|2 |14 | |`C4`¹ | |`C4`² |
|
||||
|2 |15 | |`C5`¹ | |`C5`² |
|
||||
|2 |16 | | | | |
|
||||
|3 |0 | |`A0`¹ | |`A0`² |
|
||||
|3 |1 | |`A1`¹ |`B1` |`A1`² |
|
||||
|3 |2 | |`A2`¹ |`E9` |`A2`² |
|
||||
|3 |3 | |`A3`¹ |`E13` |`A3`² |
|
||||
|3 |4 | |`F6`¹ | |`F6`² |
|
||||
|3 |5 | |`F7`¹ |`B13` |`F7`² |
|
||||
|3 |6 | |`F8`¹ |`E8` |`F8`² |
|
||||
|3 |7 | |`F9`¹ |`D10` |`F9`² |
|
||||
|3 |8 | |`F10`¹ |`D11` |`F10`² |
|
||||
|3 |9 | | |`D12` |`F3`² |
|
||||
|3 |10 | |`C0`¹ |`D13` |`C0`² |
|
||||
|3 |11 | |`C1`¹ |`D14` |`C1`² |
|
||||
|3 |12 | |`C2`¹ |`B0` |`C2`² |
|
||||
|3 |13 | |`C3`¹ |`E7` |`C3`² |
|
||||
|3 |14 | | |`E10` |`F4`² |
|
||||
|3 |15 | | |`E11` |`F5`² |
|
||||
|3 |16 | | |`E12` | |
|
||||
|4 |1 | | |`E14` | |
|
||||
|4 |2 | | |`E15` | |
|
||||
|4 |3 | | |`B12` | |
|
||||
|4 |4 | | |`B14` | |
|
||||
|4 |5 | | |`B15` | |
|
||||
|4 |6 | | |`E8` | |
|
||||
|4 |7 | | |`D10` | |
|
||||
|4 |8 | | |`D11` | |
|
||||
|4 |9 | | |`D12` | |
|
||||
|4 |10 | | |`D13` | |
|
||||
|4 |11 | | |`D14` | |
|
||||
|4 |12 | | |`D8` | |
|
||||
|4 |13 | | |`D9` | |
|
||||
|4 |14 | | | | |
|
||||
|4 |15 | | | | |
|
||||
|4 |16 | | | | |
|
||||
|
||||
<sup>¹ As of ChibiOS 20.3.4, the ADC driver for STM32F1xx devices supports only ADC1, therefore any configurations involving ADC2 or ADC3 cannot actually be used. In particular, pins `F6`…`F10`, which are present at least on some STM32F103x[C-G] devices, cannot be used as ADC inputs because of this driver limitation.</sup>
|
||||
|
||||
<sup>² Not all STM32F4xx devices have ADC2 and/or ADC3, therefore some configurations shown in this table may be unavailable; in particular, pins `F4`…`F10` cannot be used as ADC inputs on devices which do not have ADC3. Check the device datasheet to confirm which pin functions are supported.</sup>
|
||||
|
||||
#### RP2040
|
||||
|
||||
RP2040 has only a single ADC (`ADCD1` in ChibiOS); in the QMK API the index for that ADC is 0.
|
||||
|
||||
|Channel|Pin |
|
||||
|-------|-------------------|
|
||||
|0 |`GP26` |
|
||||
|1 |`GP27` |
|
||||
|2 |`GP28` |
|
||||
|3 |`GP29` |
|
||||
|4 |Temperature sensor*|
|
||||
|
||||
|
||||
<sup>* The temperature sensor is disabled by default and needs to be enabled by the RP2040-specific function: `adcRPEnableTS(&ADCD1)`. The ADC must be initialized before calling that function; an easy way to ensure that is to perform a dummy conversion.</sup>
|
||||
|
||||
## Functions
|
||||
|
||||
### AVR
|
||||
|
||||
|Function |Description |
|
||||
|----------------------------|-------------------------------------------------------------------------------------------------------------------|
|
||||
|`analogReference(mode)` |Sets the analog voltage reference source. Must be one of `ADC_REF_EXTERNAL`, `ADC_REF_POWER` or `ADC_REF_INTERNAL`.|
|
||||
|`analogReadPin(pin)` |Reads the value from the specified pin, eg. `F6` for ADC6 on the ATmega32U4. |
|
||||
|`pinToMux(pin)` |Translates a given pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)". |
|
||||
|`adc_read(mux)` |Reads the value from the ADC according to the specified mux. See your MCU's datasheet for more information. |
|
||||
|
||||
### ARM
|
||||
|
||||
|Function |Description |
|
||||
|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|`analogReadPin(pin)` |Reads the value from the specified pin, eg. `A0` for channel 0 on the STM32F0 and ADC1 channel 1 on the STM32F3. Note that if a pin can be used for multiple ADCs, it will pick the lower numbered ADC for this function. eg. `C0` will be channel 6 of ADC 1 when it could be used for ADC 2 as well.|
|
||||
|`analogReadPinAdc(pin, adc)`|Reads the value from the specified pin and ADC, eg. `C0, 1` will read from channel 6, ADC 2 instead of ADC 1. Note that the ADCs are 0-indexed for this function. |
|
||||
|`pinToMux(pin)` |Translates a given pin to a channel and ADC combination. If an unsupported pin is given, returns the mux value for "0V (GND)". |
|
||||
|`adc_read(mux)` |Reads the value from the ADC according to the specified pin and ADC combination. See your MCU's datasheet for more information. |
|
||||
|
||||
## Configuration
|
||||
|
||||
## ARM
|
||||
|
||||
The ARM implementation of the ADC has a few additional options that you can override in your own keyboards and keymaps to change how it operates. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.
|
||||
|
||||
|`#define` |Type |Default |Description |
|
||||
|---------------------|------|----------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|`ADC_CIRCULAR_BUFFER`|`bool`|`false` |If `true`, then the implementation will use a circular buffer. |
|
||||
|`ADC_NUM_CHANNELS` |`int` |`1` |Sets the number of channels that will be scanned as part of an ADC operation. The current implementation only supports `1`. |
|
||||
|`ADC_BUFFER_DEPTH` |`int` |`2` |Sets the depth of each result. Since we are only getting a 10-bit result by default, we set this to 2 bytes so we can contain our one value. This could be set to 1 if you opt for an 8-bit or lower result.|
|
||||
|`ADC_SAMPLING_RATE` |`int` |`ADC_SMPR_SMP_1P5` |Sets the sampling rate of the ADC. By default, it is set to the fastest setting. |
|
||||
|`ADC_RESOLUTION` |`int` |`ADC_CFGR1_RES_10BIT` or `ADC_CFGR_RES_10BITS`|The resolution of your result. We choose 10 bit by default, but you can opt for 12, 10, 8, or 6 bit. Different MCUs use slightly different names for the resolution constants. |
|
49
docs/drivers/apa102.md
Normal file
49
docs/drivers/apa102.md
Normal file
@ -0,0 +1,49 @@
|
||||
# APA102 Driver {#apa102-driver}
|
||||
|
||||
This driver provides support for APA102 addressable RGB LEDs. They are similar to the [WS2812](ws2812) LEDs, but have increased data and refresh rates.
|
||||
|
||||
## Usage {#usage}
|
||||
|
||||
In most cases, the APA102 driver code is automatically included if you are using either the [RGBLight](../features/rgblight) or [RGB Matrix](../features/rgb_matrix) feature with the `apa102` driver set, and you would use those APIs instead.
|
||||
|
||||
However, if you need to use the driver standalone, add the following to your `rules.mk`:
|
||||
|
||||
```make
|
||||
APA102_DRIVER_REQUIRED = yes
|
||||
```
|
||||
|
||||
You can then call the APA102 API by including `apa102.h` in your code.
|
||||
|
||||
## Basic Configuration {#basic-configuration}
|
||||
|
||||
Add the following to your `config.h`:
|
||||
|
||||
|Define |Default |Description |
|
||||
|---------------------------|-------------|------------------------------------------------------------------|
|
||||
|`APA102_DI_PIN` |*Not defined*|The GPIO pin connected to the DI pin of the first LED in the chain|
|
||||
|`APA102_CI_PIN` |*Not defined*|The GPIO pin connected to the CI pin of the first LED in the chain|
|
||||
|`APA102_DEFAULT_BRIGHTNESS`|`31` |The default global brightness level of the LEDs, from 0 to 31 |
|
||||
|
||||
## API {#api}
|
||||
|
||||
### `void apa102_setleds(rgb_led_t *start_led, uint16_t num_leds)`
|
||||
|
||||
Send RGB data to the APA102 LED chain.
|
||||
|
||||
#### Arguments {#api-apa102-setleds-arguments}
|
||||
|
||||
- `rgb_led_t *start_led`
|
||||
A pointer to the LED array.
|
||||
- `uint16_t num_leds`
|
||||
The length of the LED array.
|
||||
|
||||
---
|
||||
|
||||
### `void apa102_set_brightness(uint8_t brightness)`
|
||||
|
||||
Set the global brightness.
|
||||
|
||||
#### Arguments {#api-apa102-set-brightness-arguments}
|
||||
|
||||
- `uint8_t brightness`
|
||||
The brightness level to set, from 0 to 31.
|
239
docs/drivers/audio.md
Normal file
239
docs/drivers/audio.md
Normal file
@ -0,0 +1,239 @@
|
||||
# Audio Driver {#audio-driver}
|
||||
|
||||
The [Audio feature](../features/audio) breaks the hardware specifics out into separate, exchangeable driver units, with a common interface to the audio-"core" - which itself handles playing songs and notes while tracking their progress in an internal state, initializing/starting/stopping the driver as needed.
|
||||
|
||||
Not all MCUs support every available driver, either the platform-support is not there (yet?) or the MCU simply does not have the required hardware peripheral.
|
||||
|
||||
|
||||
## AVR {#avr}
|
||||
|
||||
Boards built around an Atmega32U4 can use two sets of PWM capable pins, each driving a separate speaker.
|
||||
The possible configurations are:
|
||||
|
||||
| | Timer3 | Timer1 |
|
||||
|--------------|-------------|--------------|
|
||||
| one speaker | C4,C5 or C6 | |
|
||||
| one speaker | | B4, B5 or B7 |
|
||||
| two speakers | C4,C5 or C6 | B4, B5 or B7 |
|
||||
|
||||
Currently there is only one/default driver for AVR based boards, which is automatically configured to:
|
||||
|
||||
```make
|
||||
AUDIO_DRIVER = pwm_hardware
|
||||
```
|
||||
|
||||
|
||||
## ARM {#arm}
|
||||
|
||||
For Arm based boards, QMK depends on ChibiOS - hence any MCU supported by the later is likely usable, as long as certain hardware peripherals are available.
|
||||
|
||||
Supported wiring configurations, with their ChibiOS/MCU peripheral requirement are listed below;
|
||||
piezo speakers are marked with :one: for the first/primary and :two: for the secondary.
|
||||
|
||||
| driver | GPTD6<br>Tim6 | GPTD7<br>Tim7 | GPTD8<br>Tim8 | PWMD1<sup>1</sup><br>Tim1_Ch1 |
|
||||
|--------------|------------------------------------------|------------------------|---------------|-------------------------------|
|
||||
| dac_basic | A4+DACD1 = :one: | A5+DACD2 = :one: | state | |
|
||||
| | A4+DACD1 = :one: + Gnd | A5+DACD2 = :two: + Gnd | state | |
|
||||
| | A4+DACD1 = :two: + Gnd | A5+DACD2 = :one: + Gnd | state | |
|
||||
| | A4+DACD1 = :one: + Gnd | | state | |
|
||||
| | | A5+DACD2 = :one: + Gnd | state | |
|
||||
| dac_additive | A4+DACD1 = :one: + Gnd | | | |
|
||||
| | A5+DACD2 = :one: + Gnd | | | |
|
||||
| | A4+DACD1 + A5+DACD2 = :one: <sup>2</sup> | | | |
|
||||
| pwm_software | state-update | | | any = :one: |
|
||||
| pwm hardware | state-update | | | A8 = :one: <sup>3</sup> |
|
||||
|
||||
|
||||
<sup>1</sup>: the routing and alternate functions for PWM differ sometimes between STM32 MCUs, if in doubt consult the data-sheet
|
||||
<sup>2</sup>: one piezo connected to A4 and A5, with AUDIO_PIN_ALT_AS_NEGATIVE set
|
||||
<sup>3</sup>: TIM1_CH1 = A8 on STM32F103C8, other combinations are possible, see Data-sheet. configured with: AUDIO_PWM_DRIVER and AUDIO_PWM_CHANNEL
|
||||
|
||||
|
||||
|
||||
### DAC basic {#dac-basic}
|
||||
|
||||
The default driver for ARM boards, in absence of an overriding configuration.
|
||||
This driver needs one Timer per enabled/used DAC channel, to trigger conversion; and a third timer to trigger state updates with the audio-core.
|
||||
|
||||
Additionally, in the board config, you'll want to make changes to enable the DACs, GPT for Timers 6, 7 and 8:
|
||||
|
||||
```c
|
||||
//halconf.h:
|
||||
#define HAL_USE_DAC TRUE
|
||||
#define HAL_USE_GPT TRUE
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
|
||||
```c
|
||||
// mcuconf.h:
|
||||
#include_next <mcuconf.h>
|
||||
#undef STM32_DAC_USE_DAC1_CH1
|
||||
#define STM32_DAC_USE_DAC1_CH1 TRUE
|
||||
#undef STM32_DAC_USE_DAC1_CH2
|
||||
#define STM32_DAC_USE_DAC1_CH2 TRUE
|
||||
#undef STM32_GPT_USE_TIM6
|
||||
#define STM32_GPT_USE_TIM6 TRUE
|
||||
#undef STM32_GPT_USE_TIM7
|
||||
#define STM32_GPT_USE_TIM7 TRUE
|
||||
#undef STM32_GPT_USE_TIM8
|
||||
#define STM32_GPT_USE_TIM8 TRUE
|
||||
```
|
||||
|
||||
::: tip
|
||||
Note: DAC1 (A4) uses TIM6, DAC2 (A5) uses TIM7, and the audio state timer uses TIM8 (configurable).
|
||||
:::
|
||||
|
||||
You can also change the timer used for the overall audio state by defining the driver. For instance:
|
||||
|
||||
```c
|
||||
#define AUDIO_STATE_TIMER GPTD9
|
||||
```
|
||||
|
||||
### DAC additive {#dac-additive}
|
||||
|
||||
only needs one timer (GPTD6, Tim6) to trigger the DAC unit to do a conversion; the audio state updates are in turn triggered during the DAC callback.
|
||||
|
||||
Additionally, in the board config, you'll want to make changes to enable the DACs, GPT for Timer 6:
|
||||
|
||||
```c
|
||||
//halconf.h:
|
||||
#define HAL_USE_DAC TRUE
|
||||
#define HAL_USE_GPT TRUE
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
|
||||
```c
|
||||
// mcuconf.h:
|
||||
#include_next <mcuconf.h>
|
||||
#undef STM32_DAC_USE_DAC1_CH1
|
||||
#define STM32_DAC_USE_DAC1_CH1 TRUE
|
||||
#undef STM32_DAC_USE_DAC1_CH2
|
||||
#define STM32_DAC_USE_DAC1_CH2 TRUE
|
||||
#undef STM32_GPT_USE_TIM6
|
||||
#define STM32_GPT_USE_TIM6 TRUE
|
||||
```
|
||||
|
||||
### DAC Config
|
||||
|
||||
| Define | Defaults | Description |
|
||||
| -------------------------------- | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `AUDIO_DAC_SAMPLE_MAX` | `4095U` | Highest value allowed. Lower value means lower volume. And 4095U is the upper limit, since this is limited to a 12 bit value. Only effects non-pregenerated samples. |
|
||||
| `AUDIO_DAC_OFF_VALUE` | `AUDIO_DAC_SAMPLE_MAX / 2` | The value of the DAC when not playing anything. Some setups may require a high (`AUDIO_DAC_SAMPLE_MAX`) or low (`0`) value here. |
|
||||
| `AUDIO_MAX_SIMULTANEOUS_TONES` | __see next table__ | The number of tones that can be played simultaneously. A value that is too high may freeze the controller or glitch out when too many tones are being played. |
|
||||
| `AUDIO_DAC_SAMPLE_RATE` | __see next table__ | Effective bit rate of the DAC (in hertz), higher limits simultaneous tones, and lower sacrifices quality. |
|
||||
| `AUDIO_DAC_BUFFER_SIZE` | __see next table__ | Number of samples generated every refill. Too few may cause excessive CPU load; too many may cause freezes, RAM or flash exhaustion or lags during matrix scanning. |
|
||||
|
||||
There are a number of predefined quality settings that you can use, with "sane minimum" being the default. You can use custom values by simply defining the sample rate, number of simultaneous tones and buffer size, instead of using one of the listed presets.
|
||||
|
||||
| Define | Sample Rate | Simultaneous tones | Buffer size |
|
||||
| --------------------------------- | ----------- | ------------------- | ----------- |
|
||||
| `AUDIO_DAC_QUALITY_VERY_LOW` | `11025U` | `8` | `64U` |
|
||||
| `AUDIO_DAC_QUALITY_LOW` | `22050U` | `4` | `128U` |
|
||||
| `AUDIO_DAC_QUALITY_HIGH` | `44100U` | `2` | `256U` |
|
||||
| `AUDIO_DAC_QUALITY_VERY_HIGH` | `88200U` | `1` | `256U` |
|
||||
| `AUDIO_DAC_QUALITY_SANE_MINIMUM` | `16384U` | `8` | `64U` |
|
||||
|
||||
#### Notes on buffer size {#buffer-size}
|
||||
|
||||
By default, the buffer size attempts to keep to these constraints:
|
||||
|
||||
* The interval between buffer refills can't be too short, since the microcontroller would then only be servicing buffer refills and would freeze up.
|
||||
* On the additive driver, the interval between buffer refills can't be too long, since matrix scanning would suffer lengthy pauses every so often, which would delay key presses or releases or lose some short taps altogether.
|
||||
* The interval between buffer refills is kept to a minimum, which allows notes to stop as soon as possible after they should.
|
||||
* For greater compatibility, the buffer size should be a power of 2.
|
||||
* The buffer size being too large causes resource exhaustion leading to build failures or freezing at runtime: RAM usage (on the additive driver) or flash usage (on the basic driver).
|
||||
|
||||
You can lower the buffer size if you need a bit more space in your firmware, or raise it if your keyboard freezes up.
|
||||
|
||||
|
||||
```c
|
||||
/* zero crossing (or approach, whereas zero == DAC_OFF_VALUE, which can be configured to anything from 0 to DAC_SAMPLE_MAX)
|
||||
* ============================*=*========================== AUDIO_DAC_SAMPLE_MAX
|
||||
* * *
|
||||
* * *
|
||||
* ---------------------------------------------------------
|
||||
* * * } AUDIO_DAC_SAMPLE_MAX/100
|
||||
* --------------------------------------------------------- AUDIO_DAC_OFF_VALUE
|
||||
* * * } AUDIO_DAC_SAMPLE_MAX/100
|
||||
* ---------------------------------------------------------
|
||||
* *
|
||||
* * *
|
||||
* * *
|
||||
* =====*=*================================================= 0x0
|
||||
*/
|
||||
```
|
||||
|
||||
|
||||
### PWM hardware {#pwm-hardware}
|
||||
|
||||
This driver uses the ChibiOS-PWM system to produce a square-wave on specific output pins that are connected to the PWM hardware.
|
||||
The hardware directly toggles the pin via its alternate function. See your MCU's data-sheet for which pin can be driven by what timer - looking for TIMx_CHy and the corresponding alternate function.
|
||||
|
||||
A configuration example for the STM32F103C8 would be:
|
||||
```c
|
||||
//halconf.h:
|
||||
#define HAL_USE_PWM TRUE
|
||||
#define HAL_USE_PAL TRUE
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
|
||||
```c
|
||||
// mcuconf.h:
|
||||
#include_next <mcuconf.h>
|
||||
#undef STM32_PWM_USE_TIM1
|
||||
#define STM32_PWM_USE_TIM1 TRUE
|
||||
```
|
||||
|
||||
If we now target pin A8, looking through the data-sheet of the STM32F103C8, for the timers and alternate functions
|
||||
- TIM1_CH1 = PA8 <- alternate0
|
||||
- TIM1_CH2 = PA9
|
||||
- TIM1_CH3 = PA10
|
||||
- TIM1_CH4 = PA11
|
||||
|
||||
with all this information, the configuration would contain these lines:
|
||||
```c
|
||||
//config.h:
|
||||
#define AUDIO_PIN A8
|
||||
#define AUDIO_PWM_DRIVER PWMD1
|
||||
#define AUDIO_PWM_CHANNEL 1
|
||||
```
|
||||
|
||||
ChibiOS uses GPIOv1 for the F103, which only knows of one alternate function.
|
||||
On 'larger' STM32s, GPIOv2 or GPIOv3 are used; with them it is also necessary to configure `AUDIO_PWM_PAL_MODE` to the correct alternate function for the selected pin, timer and timer-channel.
|
||||
|
||||
You can also use the Complementary output (`TIMx_CHyN`) for PWM on supported controllers. To enable this functionality, you will need to make the following changes:
|
||||
```c
|
||||
// config.h:
|
||||
#define AUDIO_PWM_COMPLEMENTARY_OUTPUT
|
||||
```
|
||||
|
||||
### PWM software {#pwm-software}
|
||||
|
||||
This driver uses the PWM callbacks from PWMD1 with TIM1_CH1 to toggle the selected AUDIO_PIN in software.
|
||||
During the same callback, with AUDIO_PIN_ALT_AS_NEGATIVE set, the AUDIO_PIN_ALT is toggled inversely to AUDIO_PIN. This is useful for setups that drive a piezo from two pins (instead of one and Gnd).
|
||||
|
||||
You can also change the timer used for software PWM by defining the driver. For instance:
|
||||
|
||||
```c
|
||||
#define AUDIO_STATE_TIMER GPTD8
|
||||
```
|
||||
|
||||
|
||||
### Testing Notes {#testing-notes}
|
||||
|
||||
While not an exhaustive list, the following table provides the scenarios that have been partially validated:
|
||||
|
||||
| | DAC basic | DAC additive | PWM hardware | PWM software |
|
||||
| ------------------------ | ------------------ | ------------------ | ------------------ | ------------------ |
|
||||
| Atmega32U4 | :o: | :o: | :heavy_check_mark: | :o: |
|
||||
| RP2040 | :x: | :x: | :heavy_check_mark: | ? |
|
||||
| STM32F103C8 (bluepill) | :x: | :x: | :heavy_check_mark: | :heavy_check_mark: |
|
||||
| STM32F303CCT6 (proton-c) | :heavy_check_mark: | :heavy_check_mark: | ? | :heavy_check_mark: |
|
||||
| STM32F405VG | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
|
||||
| L0xx | :x: (no Tim8) | ? | ? | ? |
|
||||
|
||||
:heavy_check_mark: : works and was tested
|
||||
:o: : does not apply
|
||||
:x: : not supported by MCU
|
||||
|
||||
*Other supported ChibiOS boards and/or pins may function, it will be highly chip and configuration dependent.*
|
180
docs/drivers/eeprom.md
Normal file
180
docs/drivers/eeprom.md
Normal file
@ -0,0 +1,180 @@
|
||||
# EEPROM Driver Configuration {#eeprom-driver-configuration}
|
||||
|
||||
The EEPROM driver can be swapped out depending on the needs of the keyboard, or whether extra hardware is present.
|
||||
|
||||
Selecting the EEPROM driver is done in your keyboard's `rules.mk`:
|
||||
|
||||
Driver | Description
|
||||
-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
`EEPROM_DRIVER = vendor` (default) | Uses the on-chip driver provided by the chip manufacturer. For AVR, this is provided by avr-libc. This is supported on ARM for a subset of chips -- STM32F3xx, STM32F1xx, and STM32F072xB will be emulated by writing to flash. STM32L0xx and STM32L1xx will use the onboard dedicated true EEPROM. Other chips will generally act as "transient" below.
|
||||
`EEPROM_DRIVER = i2c` | Supports writing to I2C-based 24xx EEPROM chips. See the driver section below.
|
||||
`EEPROM_DRIVER = spi` | Supports writing to SPI-based 25xx EEPROM chips. See the driver section below.
|
||||
`EEPROM_DRIVER = transient` | Fake EEPROM driver -- supports reading/writing to RAM, and will be discarded when power is lost.
|
||||
`EEPROM_DRIVER = wear_leveling` | Frontend driver for the wear_leveling system, allowing for EEPROM emulation on top of flash -- both in-MCU and external SPI NOR flash.
|
||||
|
||||
## Vendor Driver Configuration {#vendor-eeprom-driver-configuration}
|
||||
|
||||
#### STM32 L0/L1 Configuration {#stm32l0l1-eeprom-driver-configuration}
|
||||
|
||||
::: warning
|
||||
Resetting EEPROM using an STM32L0/L1 device takes up to 1 second for every 1kB of internal EEPROM used.
|
||||
:::
|
||||
|
||||
`config.h` override | Description | Default Value
|
||||
------------------------------------|--------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------
|
||||
`#define STM32_ONBOARD_EEPROM_SIZE` | The size of the EEPROM to use, in bytes. Erase times can be high, so it's configurable here, if not using the default value. | Minimum required to cover base _eeconfig_ data, or `1024` if VIA is enabled.
|
||||
|
||||
## I2C Driver Configuration {#i2c-eeprom-driver-configuration}
|
||||
|
||||
Currently QMK supports 24xx-series chips over I2C. As such, requires a working i2c_master driver configuration. You can override the driver configuration via your config.h:
|
||||
|
||||
`config.h` override | Description | Default Value
|
||||
------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------
|
||||
`#define EXTERNAL_EEPROM_I2C_BASE_ADDRESS` | Base I2C address for the EEPROM -- shifted left by 1 as per i2c_master requirements | 0b10100000
|
||||
`#define EXTERNAL_EEPROM_I2C_ADDRESS(addr)` | Calculated I2C address for the EEPROM | `(EXTERNAL_EEPROM_I2C_BASE_ADDRESS)`
|
||||
`#define EXTERNAL_EEPROM_BYTE_COUNT` | Total size of the EEPROM in bytes | 8192
|
||||
`#define EXTERNAL_EEPROM_PAGE_SIZE` | Page size of the EEPROM in bytes, as specified in the datasheet | 32
|
||||
`#define EXTERNAL_EEPROM_ADDRESS_SIZE` | The number of bytes to transmit for the memory location within the EEPROM | 2
|
||||
`#define EXTERNAL_EEPROM_WRITE_TIME` | Write cycle time of the EEPROM, as specified in the datasheet | 5
|
||||
`#define EXTERNAL_EEPROM_WP_PIN` | If defined the WP pin will be toggled appropriately when writing to the EEPROM. | _none_
|
||||
|
||||
Some I2C EEPROM manufacturers explicitly recommend against hardcoding the WP pin to ground. This is in order to protect the eeprom memory content during power-up/power-down/brown-out conditions at low voltage where the eeprom is still operational, but the i2c master output might be unpredictable. If a WP pin is configured, then having an external pull-up on the WP pin is recommended.
|
||||
|
||||
Default values and extended descriptions can be found in `drivers/eeprom/eeprom_i2c.h`.
|
||||
|
||||
Alternatively, there are pre-defined hardware configurations for available chips/modules:
|
||||
|
||||
Module | Equivalent `#define` | Source
|
||||
-----------------|---------------------------------|------------------------------------------
|
||||
CAT24C512 EEPROM | `#define EEPROM_I2C_CAT24C512` | <https://www.sparkfun.com/products/14764>
|
||||
RM24C512C EEPROM | `#define EEPROM_I2C_RM24C512C` | <https://www.sparkfun.com/products/14764>
|
||||
24LC32A EEPROM | `#define EEPROM_I2C_24LC32A` | <https://www.microchip.com/en-us/product/24LC32A>
|
||||
24LC64 EEPROM | `#define EEPROM_I2C_24LC64` | <https://www.microchip.com/en-us/product/24LC64>
|
||||
24LC128 EEPROM | `#define EEPROM_I2C_24LC128` | <https://www.microchip.com/en-us/product/24LC128>
|
||||
24LC256 EEPROM | `#define EEPROM_I2C_24LC256` | <https://www.sparkfun.com/products/525>
|
||||
MB85RC256V FRAM | `#define EEPROM_I2C_MB85RC256V` | <https://www.adafruit.com/product/1895>
|
||||
|
||||
::: tip
|
||||
If you find that the EEPROM is not cooperating, ensure you've correctly shifted up your EEPROM address by 1. For example, the datasheet might state the address as `0b01010000` -- the correct value of `EXTERNAL_EEPROM_I2C_BASE_ADDRESS` needs to be `0b10100000`.
|
||||
:::
|
||||
|
||||
## SPI Driver Configuration {#spi-eeprom-driver-configuration}
|
||||
|
||||
Currently QMK supports 25xx-series chips over SPI. As such, requires a working spi_master driver configuration. You can override the driver configuration via your config.h:
|
||||
|
||||
`config.h` override | Default Value | Description
|
||||
-----------------------------------------------|---------------|-------------------------------------------------------------------------------------
|
||||
`#define EXTERNAL_EEPROM_SPI_SLAVE_SELECT_PIN` | _none_ | SPI Slave select pin in order to inform that the EEPROM is currently being addressed
|
||||
`#define EXTERNAL_EEPROM_SPI_CLOCK_DIVISOR` | `64` | Clock divisor used to divide the peripheral clock to derive the SPI frequency
|
||||
`#define EXTERNAL_EEPROM_BYTE_COUNT` | `8192` | Total size of the EEPROM in bytes
|
||||
`#define EXTERNAL_EEPROM_PAGE_SIZE` | `32` | Page size of the EEPROM in bytes, as specified in the datasheet
|
||||
`#define EXTERNAL_EEPROM_ADDRESS_SIZE` | `2` | The number of bytes to transmit for the memory location within the EEPROM
|
||||
|
||||
Default values and extended descriptions can be found in `drivers/eeprom/eeprom_spi.h`.
|
||||
|
||||
Alternatively, there are pre-defined hardware configurations for available chips/modules:
|
||||
|
||||
Module | Equivalent `#define` | Source
|
||||
-----------------|---------------------------------|------------------------------------------
|
||||
MB85RS64V FRAM | `define EEPROM_SPI_MB85RS64V` | <https://www.adafruit.com/product/1897>
|
||||
|
||||
::: warning
|
||||
There's no way to determine if there is an SPI EEPROM actually responding. Generally, this will result in reads of nothing but zero.
|
||||
:::
|
||||
|
||||
## Transient Driver configuration {#transient-eeprom-driver-configuration}
|
||||
|
||||
The only configurable item for the transient EEPROM driver is its size:
|
||||
|
||||
`config.h` override | Description | Default Value
|
||||
------------------------------- | ----------------------------------------- | -------------
|
||||
`#define TRANSIENT_EEPROM_SIZE` | Total size of the EEPROM storage in bytes | 64
|
||||
|
||||
Default values and extended descriptions can be found in `drivers/eeprom/eeprom_transient.h`.
|
||||
|
||||
## Wear-leveling Driver Configuration {#wear_leveling-eeprom-driver-configuration}
|
||||
|
||||
The wear-leveling driver uses an algorithm to minimise the number of erase cycles on the underlying MCU flash memory.
|
||||
|
||||
There is no specific configuration for this driver, but the wear-leveling system used by this driver may need configuration. See the [wear-leveling configuration](#wear_leveling-configuration) section for more information.
|
||||
|
||||
# Wear-leveling Configuration {#wear_leveling-configuration}
|
||||
|
||||
The wear-leveling driver has a few possible _backing stores_ that may be used by adding to your keyboard's `rules.mk` file:
|
||||
|
||||
Driver | Description
|
||||
----------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
`WEAR_LEVELING_DRIVER = embedded_flash` | This driver is used for emulating EEPROM by writing to embedded flash on the MCU.
|
||||
`WEAR_LEVELING_DRIVER = spi_flash` | This driver is used to address external SPI NOR Flash peripherals.
|
||||
`WEAR_LEVELING_DRIVER = rp2040_flash` | This driver is used to write to the same storage the RP2040 executes code from.
|
||||
`WEAR_LEVELING_DRIVER = legacy` | This driver is the "legacy" emulated EEPROM provided in historical revisions of QMK. Currently used for STM32F0xx and STM32F4x1, but slated for deprecation and removal once `embedded_flash` support for those MCU families is complete.
|
||||
|
||||
::: warning
|
||||
All wear-leveling drivers require an amount of RAM equivalent to the selected logical EEPROM size. Increasing the size to 32kB of EEPROM requires 32kB of RAM, which a significant number of MCUs simply do not have.
|
||||
:::
|
||||
|
||||
## Wear-leveling Embedded Flash Driver Configuration {#wear_leveling-efl-driver-configuration}
|
||||
|
||||
This driver performs writes to the embedded flash storage embedded in the MCU. In most circumstances, the last few of sectors of flash are used in order to minimise the likelihood of collision with program code.
|
||||
|
||||
Configurable options in your keyboard's `config.h`:
|
||||
|
||||
`config.h` override | Default | Description
|
||||
-----------------------------------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
`#define WEAR_LEVELING_EFL_FIRST_SECTOR` | _unset_ | The first sector on the MCU to use. By default this is not defined and calculated at runtime based on the MCU. However, different flash sizes on MCUs may require custom configuration.
|
||||
`#define WEAR_LEVELING_EFL_FLASH_SIZE` | _unset_ | Allows overriding the flash size available for use for wear-leveling. Under normal circumstances this is automatically calculated and should not need to be overridden. Specifying a size larger than the amount actually available in flash will usually prevent the MCU from booting.
|
||||
`#define WEAR_LEVELING_LOGICAL_SIZE` | `(backing_size/2)` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM.
|
||||
`#define WEAR_LEVELING_BACKING_SIZE` | `2048` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size.
|
||||
`#define BACKING_STORE_WRITE_SIZE` | _automatic_ | The byte width of the underlying write used on the MCU, and is usually automatically determined from the selected MCU family. If an error occurs in the auto-detection, you'll need to consult the MCU's datasheet and determine this value, specifying it directly.
|
||||
|
||||
::: warning
|
||||
If your MCU does not boot after swapping to the EFL wear-leveling driver, it's likely that the flash size is incorrectly detected, usually as an MCU with larger flash and may require overriding.
|
||||
:::
|
||||
|
||||
## Wear-leveling SPI Flash Driver Configuration {#wear_leveling-flash_spi-driver-configuration}
|
||||
|
||||
This driver performs writes to an external SPI NOR Flash peripheral. It also requires a working configuration for the SPI NOR Flash peripheral -- see the [flash driver](flash) documentation for more information.
|
||||
|
||||
Configurable options in your keyboard's `config.h`:
|
||||
|
||||
`config.h` override | Default | Description
|
||||
----------------------------------------------------|--------------------------------|--------------------------------------------------------------------------------------------------------------------------------
|
||||
`#define WEAR_LEVELING_EXTERNAL_FLASH_BLOCK_COUNT` | `1` | Number of blocks in the external flash used by the wear-leveling algorithm.
|
||||
`#define WEAR_LEVELING_EXTERNAL_FLASH_BLOCK_OFFSET` | `0` | The index first block in the external flash used by the wear-leveling algorithm.
|
||||
`#define WEAR_LEVELING_LOGICAL_SIZE` | `((block_count*block_size)/2)` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM. Result must be <= 64kB.
|
||||
`#define WEAR_LEVELING_BACKING_SIZE` | `(block_count*block_size)` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size.
|
||||
`#define BACKING_STORE_WRITE_SIZE` | `8` | The write width used whenever a write is performed on the external flash peripheral.
|
||||
|
||||
::: warning
|
||||
There is currently a limit of 64kB for the EEPROM subsystem within QMK, so using a larger flash is not going to be beneficial as the logical size cannot be increased beyond 65536. The backing size may be increased to a larger value, but erase timing may suffer as a result.
|
||||
:::
|
||||
|
||||
## Wear-leveling RP2040 Driver Configuration {#wear_leveling-rp2040-driver-configuration}
|
||||
|
||||
This driver performs writes to the same underlying storage that the RP2040 executes its code.
|
||||
|
||||
Configurable options in your keyboard's `config.h`:
|
||||
|
||||
`config.h` override | Default | Description
|
||||
------------------------------------------|----------------------------|--------------------------------------------------------------------------------------------------------------------------------
|
||||
`#define WEAR_LEVELING_RP2040_FLASH_SIZE` | `PICO_FLASH_SIZE_BYTES` | Number of bytes of flash on the board.
|
||||
`#define WEAR_LEVELING_RP2040_FLASH_BASE` | `(flash_size-sector_size)` | The byte-wise location that the backing storage should be located.
|
||||
`#define WEAR_LEVELING_LOGICAL_SIZE` | `(backing_size/2)` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM.
|
||||
`#define WEAR_LEVELING_BACKING_SIZE` | `8192` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size as well as the sector size.
|
||||
`#define BACKING_STORE_WRITE_SIZE` | `2` | The write width used whenever a write is performed on the external flash peripheral.
|
||||
|
||||
## Wear-leveling Legacy EEPROM Emulation Driver Configuration {#wear_leveling-legacy-driver-configuration}
|
||||
|
||||
This driver performs writes to the embedded flash storage embedded in the MCU much like the normal Embedded Flash Driver, and is only for use with STM32F0xx and STM32F4x1 devices. This flash implementation is still currently provided as the EFL driver is currently non-functional for the previously mentioned families.
|
||||
|
||||
By default, `1024` bytes of emulated EEPROM is provided:
|
||||
|
||||
MCU | EEPROM Provided | Flash Used
|
||||
----------|-----------------|--------------
|
||||
STM32F042 | `1024` bytes | `2048` bytes
|
||||
STM32F070 | `1024` bytes | `2048` bytes
|
||||
STM32F072 | `1024` bytes | `2048` bytes
|
||||
STM32F401 | `1024` bytes | `16384` bytes
|
||||
STM32F411 | `1024` bytes | `16384` bytes
|
||||
|
||||
Under normal circumstances configuration of this driver requires intimate knowledge of the MCU's flash structure -- reconfiguration is at your own risk and will require referring to the code.
|
26
docs/drivers/flash.md
Normal file
26
docs/drivers/flash.md
Normal file
@ -0,0 +1,26 @@
|
||||
# FLASH Driver Configuration {#flash-driver-configuration}
|
||||
|
||||
The FLASH driver can be swapped out depending on the needs of the keyboard, or whether extra hardware is present.
|
||||
|
||||
Driver | Description
|
||||
-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
`FLASH_DRIVER = spi` | Supports writing to almost all NOR Flash chips. See the driver section below.
|
||||
|
||||
|
||||
## SPI FLASH Driver Configuration {#spi-flash-driver-configuration}
|
||||
|
||||
Currently QMK supports almost all NOR Flash chips over SPI. As such, requires a working spi_master driver configuration. You can override the driver configuration via your config.h:
|
||||
|
||||
`config.h` override | Description | Default Value
|
||||
-----------------------------------------------|--------------------------------------------------------------------------------------|-----------------
|
||||
`#define EXTERNAL_FLASH_SPI_SLAVE_SELECT_PIN` | SPI Slave select pin in order to inform that the FLASH is currently being addressed | _none_
|
||||
`#define EXTERNAL_FLASH_SPI_CLOCK_DIVISOR` | Clock divisor used to divide the peripheral clock to derive the SPI frequency | `8`
|
||||
`#define EXTERNAL_FLASH_PAGE_SIZE` | The Page size of the FLASH in bytes, as specified in the datasheet | `256`
|
||||
`#define EXTERNAL_FLASH_SECTOR_SIZE` | The sector size of the FLASH in bytes, as specified in the datasheet | `(4 * 1024)`
|
||||
`#define EXTERNAL_FLASH_BLOCK_SIZE` | The block size of the FLASH in bytes, as specified in the datasheet | `(64 * 1024)`
|
||||
`#define EXTERNAL_FLASH_SIZE` | The total size of the FLASH in bytes, as specified in the datasheet | `(512 * 1024)`
|
||||
`#define EXTERNAL_FLASH_ADDRESS_SIZE` | The Flash address size in bytes, as specified in datasheet | `3`
|
||||
|
||||
::: warning
|
||||
All the above default configurations are based on MX25L4006E NOR Flash.
|
||||
:::
|
44
docs/drivers/gpio.md
Normal file
44
docs/drivers/gpio.md
Normal file
@ -0,0 +1,44 @@
|
||||
# GPIO Control {#gpio-control}
|
||||
|
||||
QMK has a GPIO control abstraction layer which is microcontroller agnostic. This is done to allow easy access to pin control across different platforms.
|
||||
|
||||
## Macros {#macros}
|
||||
|
||||
The following macros provide basic control of GPIOs and are found in `platforms/<platform>/gpio.h`.
|
||||
|
||||
|Macro |Description |
|
||||
|-------------------------------------|---------------------------------------------------------------------|
|
||||
|`gpio_set_pin_input(pin)` |Set pin as input with high impedance (High-Z) |
|
||||
|`gpio_set_pin_input_high(pin)` |Set pin as input with builtin pull-up resistor |
|
||||
|`gpio_set_pin_input_low(pin)` |Set pin as input with builtin pull-down resistor (unavailable on AVR)|
|
||||
|`gpio_set_pin_output(pin)` |Set pin as output (alias of `gpio_set_pin_output_push_pull`) |
|
||||
|`gpio_set_pin_output_push_pull(pin)` |Set pin as output, push/pull mode |
|
||||
|`gpio_set_pin_output_open_drain(pin)`|Set pin as output, open-drain mode (unavailable on AVR and ATSAM) |
|
||||
|`gpio_write_pin_high(pin)` |Set pin level as high, assuming it is an output |
|
||||
|`gpio_write_pin_low(pin)` |Set pin level as low, assuming it is an output |
|
||||
|`gpio_write_pin(pin, level)` |Set pin level, assuming it is an output |
|
||||
|`gpio_read_pin(pin)` |Returns the level of the pin |
|
||||
|`gpio_toggle_pin(pin)` |Invert pin level, assuming it is an output |
|
||||
|
||||
## Advanced Settings {#advanced-settings}
|
||||
|
||||
Each microcontroller can have multiple advanced settings regarding its GPIO. This abstraction layer does not limit the use of architecture-specific functions. Advanced users should consult the datasheet of their desired device. For AVR, the standard `avr/io.h` library is used; for STM32, the ChibiOS [PAL library](https://chibios.sourceforge.net/docs3/hal/group___p_a_l.html) is used.
|
||||
|
||||
## Atomic Operation {#atomic-operation}
|
||||
|
||||
The above functions are not always guaranteed to work atomically. Therefore, if you want to prevent interruptions in the middle of operations when using multiple combinations of the above functions, use the following `ATOMIC_BLOCK_FORCEON` macro.
|
||||
|
||||
eg.
|
||||
```c
|
||||
void some_function(void) {
|
||||
// some process
|
||||
ATOMIC_BLOCK_FORCEON {
|
||||
// Atomic Processing
|
||||
}
|
||||
// some process
|
||||
}
|
||||
```
|
||||
|
||||
`ATOMIC_BLOCK_FORCEON` forces interrupts to be disabled before the block is executed, without regard to whether they are enabled or disabled. Then, after the block is executed, the interrupt is enabled.
|
||||
|
||||
Note that `ATOMIC_BLOCK_FORCEON` can therefore be used if you know that interrupts are enabled before the execution of the block, or if you know that it is OK to enable interrupts at the completion of the block.
|
290
docs/drivers/i2c.md
Normal file
290
docs/drivers/i2c.md
Normal file
@ -0,0 +1,290 @@
|
||||
# I2C Master Driver {#i2c-master-driver}
|
||||
|
||||
The I2C Master drivers used in QMK have a set of common functions to allow portability between MCUs.
|
||||
|
||||
## Usage {#usage}
|
||||
|
||||
In most cases, the I2C Master driver code is automatically included if you are using a feature or driver which requires it, such as [OLED](../features/oled_driver).
|
||||
|
||||
However, if you need to use the driver standalone, add the following to your `rules.mk`:
|
||||
|
||||
```make
|
||||
I2C_DRIVER_REQUIRED = yes
|
||||
```
|
||||
|
||||
You can then call the I2C API by including `i2c_master.h` in your code.
|
||||
|
||||
## I2C Addressing {#note-on-i2c-addresses}
|
||||
|
||||
All of the addresses expected by this driver should be pushed to the upper 7 bits of the address byte. Setting
|
||||
the lower bit (indicating read/write) will be done by the respective functions. Almost all I2C addresses listed
|
||||
on datasheets and the internet will be represented as 7 bits occupying the lower 7 bits and will need to be
|
||||
shifted to the left (more significant) by one bit. This is easy to do via the bitwise shift operator `<< 1`.
|
||||
|
||||
You can either do this on each call to the functions below, or once in your definition of the address. For example, if your device has an address of `0x18`:
|
||||
|
||||
```c
|
||||
#define MY_I2C_ADDRESS (0x18 << 1)
|
||||
```
|
||||
|
||||
See https://www.robot-electronics.co.uk/i2c-tutorial for more information about I2C addressing and other technical details.
|
||||
|
||||
## AVR Configuration {#avr-configuration}
|
||||
|
||||
The following defines can be used to configure the I2C master driver:
|
||||
|
||||
|`config.h` Override|Description |Default |
|
||||
|-------------------|---------------------|--------|
|
||||
|`F_SCL` |Clock frequency in Hz|`400000`|
|
||||
|
||||
No further setup is required - just connect the `SDA` and `SCL` pins of your I2C devices to the matching pins on the MCU:
|
||||
|
||||
|MCU |`SCL`|`SDA`|
|
||||
|------------------|-----|-----|
|
||||
|ATmega16/32U4 |`D0` |`D1` |
|
||||
|AT90USB64/128 |`D0` |`D1` |
|
||||
|ATmega32A |`C0` |`C1` |
|
||||
|ATmega328/P |`C5` |`C4` |
|
||||
|
||||
::: tip
|
||||
The ATmega16/32U2 does not possess I2C functionality, and so cannot use this driver.
|
||||
:::
|
||||
|
||||
## ChibiOS/ARM Configuration {#arm-configuration}
|
||||
|
||||
You'll need to determine which pins can be used for I2C -- a an example, STM32 parts generally have multiple I2C peripherals, labeled I2C1, I2C2, I2C3 etc.
|
||||
|
||||
To enable I2C, modify your board's `halconf.h` to enable I2C:
|
||||
|
||||
```c
|
||||
#define HAL_USE_I2C TRUE
|
||||
```
|
||||
|
||||
Then, modify your board's `mcuconf.h` to enable the peripheral you've chosen, for example:
|
||||
|
||||
```c
|
||||
#undef STM32_I2C_USE_I2C2
|
||||
#define STM32_I2C_USE_I2C2 TRUE
|
||||
```
|
||||
|
||||
|`mcuconf.h` Setting |Description |Default|
|
||||
|----------------------------|----------------------------------------------------------------------------------|-------|
|
||||
|`STM32_I2C_BUSY_TIMEOUT` |Time in milliseconds until the I2C command is aborted if no response is received |`50` |
|
||||
|`STM32_I2C_XXX_IRQ_PRIORITY`|Interrupt priority for hardware driver XXX (THIS IS AN EXPERT SETTING) |`10` |
|
||||
|`STM32_I2C_USE_DMA` |Enable/Disable the ability of the MCU to offload the data transfer to the DMA unit|`TRUE` |
|
||||
|`STM32_I2C_XXX_DMA_PRIORITY`|Priority of DMA unit for hardware driver XXX (THIS IS AN EXPERT SETTING) |`1` |
|
||||
|
||||
Configuration-wise, you'll need to set up the peripheral as per your MCU's datasheet -- the defaults match the pins for a Proton-C, i.e. STM32F303.
|
||||
|
||||
|`config.h` Overrride |Description |Default|
|
||||
|------------------------|--------------------------------------------------------------|-------|
|
||||
|`I2C_DRIVER` |I2C peripheral to use - I2C1 -> `I2CD1`, I2C2 -> `I2CD2` etc. |`I2CD1`|
|
||||
|`I2C1_SCL_PIN` |The pin definition for SCL |`B6` |
|
||||
|`I2C1_SCL_PAL_MODE` |The alternate function mode for SCL |`4` |
|
||||
|`I2C1_SDA_PIN` |The pin definition for SDA |`B7` |
|
||||
|`I2C1_SDA_PAL_MODE` |The alternate function mode for SDA |`4` |
|
||||
|
||||
The following configuration values depend on the specific MCU in use.
|
||||
|
||||
### I2Cv1 {#arm-configuration-i2cv1}
|
||||
|
||||
* STM32F1xx
|
||||
* STM32F2xx
|
||||
* STM32F4xx
|
||||
* STM32L0xx
|
||||
* STM32L1xx
|
||||
|
||||
See [this page](https://www.playembedded.org/blog/stm32-i2c-chibios/#7_I2Cv1_configuration_structure) for the I2Cv1 configuration structure.
|
||||
|
||||
|`config.h` Override|Default |
|
||||
|-------------------|----------------|
|
||||
|`I2C1_OPMODE` |`OPMODE_I2C` |
|
||||
|`I2C1_CLOCK_SPEED` |`100000` |
|
||||
|`I2C1_DUTY_CYCLE` |`STD_DUTY_CYCLE`|
|
||||
|
||||
### I2Cv2 {#arm-configuration-i2cv2}
|
||||
|
||||
* STM32F0xx
|
||||
* STM32F3xx
|
||||
* STM32F7xx
|
||||
* STM32L4xx
|
||||
|
||||
See [this page](https://www.playembedded.org/blog/stm32-i2c-chibios/#8_I2Cv2_I2Cv3_configuration_structure) for the I2Cv2 configuration structure.
|
||||
|
||||
|`config.h` Override |Default|
|
||||
|---------------------|-------|
|
||||
|`I2C1_TIMINGR_PRESC` |`0U` |
|
||||
|`I2C1_TIMINGR_SCLDEL`|`7U` |
|
||||
|`I2C1_TIMINGR_SDADEL`|`0U` |
|
||||
|`I2C1_TIMINGR_SCLH` |`38U` |
|
||||
|`I2C1_TIMINGR_SCLL` |`129U` |
|
||||
|
||||
## API {#api}
|
||||
|
||||
### `void i2c_init(void)` {#api-i2c-init}
|
||||
|
||||
Initialize the I2C driver. This function must be called only once, before any of the below functions can be called.
|
||||
|
||||
This function is weakly defined, meaning it can be overridden if necessary for your particular use case:
|
||||
|
||||
```c
|
||||
void i2c_init(void) {
|
||||
gpio_set_pin_input(B6); // Try releasing special pins for a short time
|
||||
gpio_set_pin_input(B7);
|
||||
wait_ms(10); // Wait for the release to happen
|
||||
|
||||
palSetPadMode(GPIOB, 6, PAL_MODE_ALTERNATE(4) | PAL_STM32_OTYPE_OPENDRAIN | PAL_STM32_PUPDR_PULLUP); // Set B6 to I2C function
|
||||
palSetPadMode(GPIOB, 7, PAL_MODE_ALTERNATE(4) | PAL_STM32_OTYPE_OPENDRAIN | PAL_STM32_PUPDR_PULLUP); // Set B7 to I2C function
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### `i2c_status_t i2c_transmit(uint8_t address, uint8_t *data, uint16_t length, uint16_t timeout)` {#api-i2c-transmit}
|
||||
|
||||
Send multiple bytes to the selected I2C device.
|
||||
|
||||
#### Arguments {#api-i2c-transmit-arguments}
|
||||
|
||||
- `uint8_t address`
|
||||
The 7-bit I2C address of the device.
|
||||
- `uint8_t *data`
|
||||
A pointer to the data to transmit.
|
||||
- `uint16_t length`
|
||||
The number of bytes to write. Take care not to overrun the length of `data`.
|
||||
- `uint16_t timeout`
|
||||
The time in milliseconds to wait for a response from the target device.
|
||||
|
||||
#### Return Value {#api-i2c-transmit-return}
|
||||
|
||||
`I2C_STATUS_TIMEOUT` if the timeout period elapses, `I2C_STATUS_ERROR` if some other error occurs, otherwise `I2C_STATUS_SUCCESS`.
|
||||
|
||||
---
|
||||
|
||||
### `i2c_status_t i2c_receive(uint8_t address, uint8_t* data, uint16_t length, uint16_t timeout)` {#api-i2c-receive}
|
||||
|
||||
Receive multiple bytes from the selected I2C device.
|
||||
|
||||
#### Arguments {#api-i2c-receive-arguments}
|
||||
|
||||
- `uint8_t address`
|
||||
The 7-bit I2C address of the device.
|
||||
- `uint8_t *data`
|
||||
A pointer to the buffer to read into.
|
||||
- `uint16_t length`
|
||||
The number of bytes to read. Take care not to overrun the length of `data`.
|
||||
- `uint16_t timeout`
|
||||
The time in milliseconds to wait for a response from the target device.
|
||||
|
||||
#### Return Value {#api-i2c-receive-return}
|
||||
|
||||
`I2C_STATUS_TIMEOUT` if the timeout period elapses, `I2C_STATUS_ERROR` if some other error occurs, otherwise `I2C_STATUS_SUCCESS`.
|
||||
|
||||
---
|
||||
|
||||
### `i2c_status_t i2c_write_register(uint8_t devaddr, uint8_t regaddr, uint8_t* data, uint16_t length, uint16_t timeout)` {#api-i2c-write-register}
|
||||
|
||||
Writes to a register with an 8-bit address on the I2C device.
|
||||
|
||||
#### Arguments {#api-i2c-write-register-arguments}
|
||||
|
||||
- `uint8_t devaddr`
|
||||
The 7-bit I2C address of the device.
|
||||
- `uint8_t regaddr`
|
||||
The register address to write to.
|
||||
- `uint8_t *data`
|
||||
A pointer to the data to transmit.
|
||||
- `uint16_t length`
|
||||
The number of bytes to write. Take care not to overrun the length of `data`.
|
||||
- `uint16_t timeout`
|
||||
The time in milliseconds to wait for a response from the target device.
|
||||
|
||||
#### Return Value {#api-i2c-write-register-return}
|
||||
|
||||
`I2C_STATUS_TIMEOUT` if the timeout period elapses, `I2C_STATUS_ERROR` if some other error occurs, otherwise `I2C_STATUS_SUCCESS`.
|
||||
|
||||
---
|
||||
|
||||
### `i2c_status_t i2c_write_register16(uint8_t devaddr, uint16_t regaddr, uint8_t* data, uint16_t length, uint16_t timeout)` {#api-i2c-write-register16}
|
||||
|
||||
Writes to a register with a 16-bit address (big endian) on the I2C device.
|
||||
|
||||
#### Arguments {#api-i2c-write-register16-arguments}
|
||||
|
||||
- `uint8_t devaddr`
|
||||
The 7-bit I2C address of the device.
|
||||
- `uint16_t regaddr`
|
||||
The register address to write to.
|
||||
- `uint8_t *data`
|
||||
A pointer to the data to transmit.
|
||||
- `uint16_t length`
|
||||
The number of bytes to write. Take care not to overrun the length of `data`.
|
||||
- `uint16_t timeout`
|
||||
The time in milliseconds to wait for a response from the target device.
|
||||
|
||||
#### Return Value {#api-i2c-write-register16-return}
|
||||
|
||||
`I2C_STATUS_TIMEOUT` if the timeout period elapses, `I2C_STATUS_ERROR` if some other error occurs, otherwise `I2C_STATUS_SUCCESS`.
|
||||
|
||||
---
|
||||
|
||||
### `i2c_status_t i2c_read_register(uint8_t devaddr, uint8_t regaddr, uint8_t* data, uint16_t length, uint16_t timeout)` {#api-i2c-read-register}
|
||||
|
||||
Reads from a register with an 8-bit address on the I2C device.
|
||||
|
||||
#### Arguments {#api-i2c-read-register-arguments}
|
||||
|
||||
- `uint8_t devaddr`
|
||||
The 7-bit I2C address of the device.
|
||||
- `uint8_t regaddr`
|
||||
The register address to read from.
|
||||
- `uint16_t length`
|
||||
The number of bytes to read. Take care not to overrun the length of `data`.
|
||||
- `uint16_t timeout`
|
||||
The time in milliseconds to wait for a response from the target device.
|
||||
|
||||
#### Return Value {#api-i2c-read-register-return}
|
||||
|
||||
`I2C_STATUS_TIMEOUT` if the timeout period elapses, `I2C_STATUS_ERROR` if some other error occurs, otherwise `I2C_STATUS_SUCCESS`.
|
||||
|
||||
---
|
||||
|
||||
### `i2c_status_t i2c_read_register16(uint8_t devaddr, uint16_t regaddr, uint8_t* data, uint16_t length, uint16_t timeout)` {#api-i2c-read-register16}
|
||||
|
||||
Reads from a register with a 16-bit address (big endian) on the I2C device.
|
||||
|
||||
#### Arguments {#api-i2c-read-register16-arguments}
|
||||
|
||||
- `uint8_t devaddr`
|
||||
The 7-bit I2C address of the device.
|
||||
- `uint16_t regaddr`
|
||||
The register address to read from.
|
||||
- `uint16_t length`
|
||||
The number of bytes to read. Take care not to overrun the length of `data`.
|
||||
- `uint16_t timeout`
|
||||
The time in milliseconds to wait for a response from the target device.
|
||||
|
||||
#### Return Value {#api-i2c-read-register16-return}
|
||||
|
||||
`I2C_STATUS_TIMEOUT` if the timeout period elapses, `I2C_STATUS_ERROR` if some other error occurs, otherwise `I2C_STATUS_SUCCESS`.
|
||||
|
||||
---
|
||||
|
||||
### `i2c_status_t i2c_ping_address(uint8_t address, uint16_t timeout)` {#api-i2c-ping-address}
|
||||
|
||||
Pings the I2C bus for a specific address.
|
||||
|
||||
On ChibiOS a "best effort" attempt is made by reading a single byte from register 0 at the requested address. This should generally work except for I2C devices that do not not respond to a register 0 read request, which will result in a false negative result (unsucessful response to ping attempt).
|
||||
|
||||
This function is weakly defined, meaning it can be overridden if necessary for your particular use case:
|
||||
|
||||
#### Arguments
|
||||
|
||||
- `uint8_t address`
|
||||
The 7-bit I2C address of the device (ie. without the read/write bit - this will be set automatically).
|
||||
- `uint16_t timeout`
|
||||
The time in milliseconds to wait for a response from the target device.
|
||||
|
||||
#### Return Value
|
||||
|
||||
`I2C_STATUS_TIMEOUT` if the timeout period elapses, `I2C_STATUS_ERROR` if some other error occurs, otherwise `I2C_STATUS_SUCCESS`.
|
397
docs/drivers/serial.md
Normal file
397
docs/drivers/serial.md
Normal file
@ -0,0 +1,397 @@
|
||||
# 'serial' Driver
|
||||
|
||||
The Serial driver powers the [Split Keyboard](../features/split_keyboard) feature. Several implementations are available that cater to the platform and capabilites of MCU in use. Note that none of the drivers support split keyboards with more than two halves.
|
||||
|
||||
| Driver | AVR | ARM | Connection between halves |
|
||||
| --------------------------------------- | ------------------ | ------------------ | --------------------------------------------------------------------------------------------- |
|
||||
| [Bitbang](#bitbang) | :heavy_check_mark: | :heavy_check_mark: | Single wire communication. One wire is used for reception and transmission. |
|
||||
| [USART Half-duplex](#usart-half-duplex) | | :heavy_check_mark: | Efficient single wire communication. One wire is used for reception and transmission. |
|
||||
| [USART Full-duplex](#usart-full-duplex) | | :heavy_check_mark: | Efficient two wire communication. Two distinct wires are used for reception and transmission. |
|
||||
|
||||
::: tip
|
||||
Serial in this context should be read as **sending information one bit at a time**, rather than implementing UART/USART/RS485/RS232 standards.
|
||||
:::
|
||||
|
||||
<hr>
|
||||
|
||||
## Bitbang
|
||||
|
||||
This is the Default driver, absence of configuration assumes this driver. It works by [bit banging](https://en.wikipedia.org/wiki/Bit_banging) a GPIO pin using the CPU. It is therefore not as efficient as a dedicated hardware peripheral, which the Half-duplex and Full-duplex drivers use.
|
||||
|
||||
::: warning
|
||||
On ARM platforms the bitbang driver causes connection issues when using it together with the bitbang WS2812 driver. Choosing alternate drivers for both serial and WS2812 (instead of bitbang) is strongly recommended.
|
||||
:::
|
||||
|
||||
### Pin configuration
|
||||
|
||||
```
|
||||
LEFT RIGHT
|
||||
+-------+ SERIAL +-------+
|
||||
| SSP |-----------------| SSP |
|
||||
| | VDD | |
|
||||
| |-----------------| |
|
||||
| | GND | |
|
||||
| |-----------------| |
|
||||
+-------+ +-------+
|
||||
```
|
||||
|
||||
One GPIO pin is needed for the bitbang driver, as only one wire is used for receiving and transmitting data. This pin is referred to as the `SOFT_SERIAL_PIN` (SSP) in the configuration. A TRS or USB cable provides enough conductors for this driver to function.
|
||||
|
||||
### Setup
|
||||
|
||||
To use the bitbang driver follow these steps to activate it.
|
||||
|
||||
1. Change the `SERIAL_DRIVER` to `bitbang` in your keyboards `rules.mk` file:
|
||||
|
||||
```make
|
||||
SERIAL_DRIVER = bitbang
|
||||
```
|
||||
|
||||
2. Configure the GPIO pin of your keyboard via the `config.h` file:
|
||||
|
||||
```c
|
||||
#define SOFT_SERIAL_PIN D0 // or D1, D2, D3, E6
|
||||
```
|
||||
|
||||
3. On ARM platforms you must turn on ChibiOS `PAL_USE_CALLBACKS` feature:
|
||||
|
||||
* In `halconf.h` add the line `#define PAL_USE_CALLBACKS TRUE`.
|
||||
|
||||
<hr>
|
||||
|
||||
## USART Half-duplex
|
||||
|
||||
Targeting ARM boards based on ChibiOS, where communication is offloaded to a USART hardware device that supports Half-duplex operation. The advantages over bitbanging are fast, accurate timings and reduced CPU usage. Therefore it is advised to choose Half-duplex over Bitbang if MCU is capable of utilising Half-duplex, and Full-duplex can't be used instead (e.g. lack of available GPIO pins, or imcompatible PCB design).
|
||||
|
||||
### Pin configuration
|
||||
|
||||
```
|
||||
LEFT RIGHT
|
||||
+-------+ | | +-------+
|
||||
| | R R | |
|
||||
| | | SERIAL | | |
|
||||
| TX |-----------------| TX |
|
||||
| | VDD | |
|
||||
| |-----------------| |
|
||||
| | GND | |
|
||||
| |-----------------| |
|
||||
+-------+ +-------+
|
||||
```
|
||||
|
||||
Only one GPIO pin is needed for the Half-duplex driver, as only one wire is used for receiving and transmitting data. This pin is referred to as the `SERIAL_USART_TX_PIN` in the configuration. Ensure that the pin chosen for split communication can operate as the TX pin of the contoller's USART peripheral. A TRS or USB cable provides enough conductors for this driver to function. As the split connection is configured to operate in open-drain mode, an **external pull-up resistor is needed to keep the line high**. Resistor values of 1.5kΩ to 8.2kΩ are known to work.
|
||||
|
||||
::: warning
|
||||
***Note:*** A pull-up resistor isn't required for RP2040 controllers configured with PIO subsystem.
|
||||
:::
|
||||
|
||||
### Setup
|
||||
|
||||
To use the Half-duplex driver follow these steps to activate it. If you target the Raspberry Pi RP2040 PIO implementation, start at step 2.
|
||||
|
||||
1. Change the `SERIAL_DRIVER` to `usart` in your keyboards `rules.mk` file:
|
||||
|
||||
```make
|
||||
SERIAL_DRIVER = usart
|
||||
```
|
||||
|
||||
Skip to step 3.
|
||||
|
||||
2. (RP2040 + PIO only!) Change the `SERIAL_DRIVER` to `vendor` in your keyboards `rules.mk` file:
|
||||
|
||||
```make
|
||||
SERIAL_DRIVER = vendor
|
||||
```
|
||||
|
||||
3. Configure the hardware of your keyboard via the `config.h` file:
|
||||
|
||||
```c
|
||||
#define SERIAL_USART_TX_PIN B6 // The GPIO pin that is used split communication.
|
||||
```
|
||||
|
||||
For STM32 MCUs several GPIO configuration options can be changed as well. See the section ["Alternate Functions for selected STM32 MCUs"](#alternate-functions-for-selected-stm32-mcus).
|
||||
|
||||
```c
|
||||
#define USART1_REMAP // Remap USART TX and RX pins on STM32F103 MCUs, see table below.
|
||||
#define SERIAL_USART_TX_PAL_MODE 7 // Pin "alternate function", see the respective datasheet for the appropriate values for your MCU. default: 7
|
||||
```
|
||||
|
||||
4. Decide either for `SERIAL`, `SIO`, or `PIO` subsystem. See section ["Choosing a driver subsystem"](#choosing-a-driver-subsystem).
|
||||
|
||||
<hr>
|
||||
|
||||
## USART Full-duplex
|
||||
|
||||
Targeting ARM boards based on ChibiOS where communication is offloaded to an USART hardware device. The advantages over bitbanging are fast, accurate timings and reduced CPU usage; therefore it is advised to choose this driver over all others where possible. Due to its internal design Full-duplex is slightly more efficient than the Half-duplex driver, but Full-duplex should be primarily chosen if Half-duplex operation is not supported by the controller's USART peripheral.
|
||||
|
||||
### Pin configuration
|
||||
|
||||
```
|
||||
LEFT RIGHT
|
||||
+-------+ +-------+
|
||||
| | SERIAL | |
|
||||
| TX |-----------------| RX |
|
||||
| | SERIAL | |
|
||||
| RX |-----------------| TX |
|
||||
| | VDD | |
|
||||
| |-----------------| |
|
||||
| | GND | |
|
||||
| |-----------------| |
|
||||
+-------+ +-------+
|
||||
```
|
||||
|
||||
Two GPIO pins are needed for the Full-duplex driver, as two distinct wires are used for receiving and transmitting data. The pin transmitting data is the `TX` pin and refereed to as the `SERIAL_USART_TX_PIN`, the pin receiving data is the `RX` pin and refereed to as the `SERIAL_USART_RX_PIN` in this configuration. Please note that `TX` pin of the master half has to be connected with the `RX` pin of the slave half and the `RX` pin of the master half has to be connected with the `TX` pin of the slave half! Usually this pin swap has to be done outside of the MCU e.g. with cables or on the PCB. Some MCUs like the STM32F303 used on the Proton-C allow this pin swap directly inside the MCU. A TRRS or USB cable provides enough conductors for this driver to function.
|
||||
|
||||
To use this driver the USART peripherals `TX` and `RX` pins must be configured with the correct Alternate-functions. If you are using a Proton-C development board everything is already setup, same is true for STM32F103 MCUs. For MCUs which are using a modern flexible GPIO configuration you have to specify these by setting `SERIAL_USART_TX_PAL_MODE` and `SERIAL_USART_RX_PAL_MODE`. Refer to the corresponding datasheets of your MCU or find those settings in the section ["Alternate Functions for selected STM32 MCUs"](#alternate-functions-for-selected-stm32-mcus).
|
||||
|
||||
### Setup
|
||||
|
||||
To use the Full-duplex driver follow these steps to activate it. If you target the Raspberry Pi RP2040 PIO implementation, start at step 2
|
||||
|
||||
1. Change the `SERIAL_DRIVER` to `usart` in your keyboards `rules.mk` file:
|
||||
|
||||
```make
|
||||
SERIAL_DRIVER = usart
|
||||
```
|
||||
|
||||
Skip to step 3
|
||||
|
||||
2. (RP2040 + PIO only!) Change the `SERIAL_DRIVER` to `vendor` in your keyboards `rules.mk` file:
|
||||
|
||||
```make
|
||||
SERIAL_DRIVER = vendor
|
||||
```
|
||||
|
||||
3. Configure the hardware of your keyboard via the `config.h` file:
|
||||
|
||||
```c
|
||||
#define SERIAL_USART_FULL_DUPLEX // Enable full duplex operation mode.
|
||||
#define SERIAL_USART_TX_PIN B6 // USART TX pin
|
||||
#define SERIAL_USART_RX_PIN B7 // USART RX pin
|
||||
```
|
||||
|
||||
For STM32 MCUs several GPIO configuration options, including the ability for `TX` to `RX` pin swapping, can be changed as well. See the section ["Alternate Functions for selected STM32 MCUs"](#alternate-functions-for-selected-stm32-mcus).
|
||||
|
||||
```c
|
||||
#define SERIAL_USART_PIN_SWAP // Swap TX and RX pins if keyboard is master halve. (Only available on some MCUs)
|
||||
#define USART1_REMAP // Remap USART TX and RX pins on STM32F103 MCUs, see table below.
|
||||
#define SERIAL_USART_TX_PAL_MODE 7 // Pin "alternate function", see the respective datasheet for the appropriate values for your MCU. default: 7
|
||||
```
|
||||
|
||||
4. Decide either for `SERIAL`, `SIO`, or `PIO` subsystem. See section ["Choosing a driver subsystem"](#choosing-a-driver-subsystem).
|
||||
|
||||
<hr>
|
||||
|
||||
## Choosing a driver subsystem
|
||||
|
||||
### The `SERIAL` driver
|
||||
|
||||
The `SERIAL` Subsystem is supported for the majority of ChibiOS MCUs and should be used whenever supported. Follow these steps in order to activate it:
|
||||
|
||||
1. In your keyboards `halconf.h` add:
|
||||
|
||||
```c
|
||||
#define HAL_USE_SERIAL TRUE
|
||||
```
|
||||
|
||||
2. In your keyboards `mcuconf.h`: activate the USART peripheral that is used on your MCU. The shown example is for an STM32 MCU, so this will not work on MCUs by other manufacturers. You can find the correct names in the `mcuconf.h` files of your MCU that ship with ChibiOS.
|
||||
|
||||
Just below `#include_next <mcuconf.h>` add:
|
||||
|
||||
```c
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
#undef STM32_SERIAL_USE_USARTn
|
||||
#define STM32_SERIAL_USE_USARTn TRUE
|
||||
```
|
||||
|
||||
Where 'n' matches the peripheral number of your selected USART on the MCU.
|
||||
|
||||
3. In you keyboards `config.h`: override the default USART `SERIAL` driver if you use a USART peripheral that does not belong to the default selected `SD1` driver. For instance, if you selected `STM32_SERIAL_USE_USART3` the matching driver would be `SD3`.
|
||||
|
||||
```c
|
||||
#define SERIAL_USART_DRIVER SD3
|
||||
```
|
||||
|
||||
### The `SIO` driver
|
||||
|
||||
The `SIO` Subsystem was added to ChibiOS with the 21.11 release and is only supported on selected MCUs. It should only be chosen when the `SERIAL` subsystem is not supported by your MCU.
|
||||
|
||||
Follow these steps in order to activate it:
|
||||
|
||||
1. In your keyboards `halconf.h` add:
|
||||
|
||||
```c
|
||||
#define HAL_USE_SIO TRUE
|
||||
```
|
||||
|
||||
2. In your keyboards `mcuconf.h:` activate the USART peripheral that is used on your MCU. The shown example is for an STM32 MCU, so this will not work on MCUs by other manufacturers. You can find the correct names in the `mcuconf.h` files of your MCU that ship with ChibiOS.
|
||||
|
||||
Just below `#include_next <mcuconf.h>` add:
|
||||
|
||||
```c
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
#undef STM32_SIO_USE_USARTn
|
||||
#define STM32_SIO_USE_USARTn TRUE
|
||||
```
|
||||
|
||||
Where 'n' matches the peripheral number of your selected USART on the MCU.
|
||||
|
||||
3. In the keyboard's `config.h` file: override the default USART `SIO` driver if you use a USART peripheral that does not belong to the default selected `SIOD1` driver. For instance, if you selected `STM32_SERIAL_USE_USART3` the matching driver would be `SIOD3`.
|
||||
|
||||
```c
|
||||
#define SERIAL_USART_DRIVER SIOD3
|
||||
```
|
||||
|
||||
### The `PIO` driver
|
||||
|
||||
The `PIO` subsystem is a Raspberry Pi RP2040 specific implementation, using an integrated PIO peripheral and is therefore only available on this MCU. Because of the flexible nature of PIO peripherals, **any** GPIO pin can be used as a `TX` or `RX` pin. Half-duplex and Full-duplex operation modes are fully supported with this driver. Half-duplex uses the built-in pull-ups and GPIO manipulation of the RP2040 to drive the line high by default, thus an external pull-up resistor **is not required**.
|
||||
|
||||
Optionally, the PIO peripheral utilized for split communication can be changed with the following define in config.h:
|
||||
```c
|
||||
#define SERIAL_PIO_USE_PIO1 // Force the usage of PIO1 peripheral, by default the Serial implementation uses the PIO0 peripheral
|
||||
```
|
||||
|
||||
The Serial PIO program uses 2 state machines, 13 instructions and the complete interrupt handler of the PIO peripheral it is running on.
|
||||
|
||||
<hr>
|
||||
|
||||
## Advanced Configuration
|
||||
|
||||
There are several advanced configuration options that can be defined in your keyboards `config.h` file:
|
||||
|
||||
### Baudrate
|
||||
|
||||
If you're having issues or need a higher baudrate with serial communication, you can change the baudrate which in turn controls the communication speed for serial. You want to lower the baudrate if you experience failed transactions.
|
||||
|
||||
```c
|
||||
#define SELECT_SOFT_SERIAL_SPEED {#}
|
||||
```
|
||||
|
||||
| Speed | Bitbang | Half-duplex and Full-duplex |
|
||||
| ----- | -------------------------- | --------------------------- |
|
||||
| `0` | 189000 baud (experimental) | 460800 baud |
|
||||
| `1` | 137000 baud (default) | 230400 baud (default) |
|
||||
| `2` | 75000 baud | 115200 baud |
|
||||
| `3` | 39000 baud | 57600 baud |
|
||||
| `4` | 26000 baud | 38400 baud |
|
||||
| `5` | 20000 baud | 19200 baud |
|
||||
|
||||
Alternatively you can specify the baudrate directly by defining `SERIAL_USART_SPEED`.
|
||||
|
||||
### Timeout
|
||||
|
||||
This is the default time window in milliseconds in which a successful communication has to complete. Usually you don't want to change this value. But you can do so anyways by defining an alternate one in your keyboards `config.h` file:
|
||||
|
||||
```c
|
||||
#define SERIAL_USART_TIMEOUT 20 // USART driver timeout. default 20
|
||||
```
|
||||
|
||||
<hr>
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If you're having issues withe serial communication, you can enable debug messages that will give you insights which part of the communication failed. The enable these messages add to your keyboards `config.h` file:
|
||||
|
||||
```c
|
||||
#define SERIAL_DEBUG
|
||||
```
|
||||
|
||||
::: tip
|
||||
The messages will be printed out to the `CONSOLE` output. For additional information, refer to [Debugging/Troubleshooting QMK](../faq_debug).
|
||||
:::
|
||||
|
||||
## Alternate Functions for selected STM32 MCUs
|
||||
|
||||
Pins for USART Peripherals with
|
||||
|
||||
### STM32F303 / Proton-C [Datasheet](https://www.st.com/resource/en/datasheet/stm32f303cc.pdf)
|
||||
|
||||
Pin Swap available: :heavy_check_mark:
|
||||
|
||||
| Pin | Function | Mode |
|
||||
| ---------- | -------- | ---- |
|
||||
| **USART1** | | |
|
||||
| PA9 | TX | AF7 |
|
||||
| PA10 | RX | AF7 |
|
||||
| PB6 | TX | AF7 |
|
||||
| PB7 | RX | AF7 |
|
||||
| PC4 | TX | AF7 |
|
||||
| PC5 | RX | AF7 |
|
||||
| PE0 | TX | AF7 |
|
||||
| PE1 | RX | AF7 |
|
||||
| **USART2** | | |
|
||||
| PA2 | TX | AF7 |
|
||||
| PA3 | RX | AF7 |
|
||||
| PA14 | TX | AF7 |
|
||||
| PA15 | RX | AF7 |
|
||||
| PB3 | TX | AF7 |
|
||||
| PB4 | RX | AF7 |
|
||||
| PD5 | TX | AF7 |
|
||||
| PD6 | RX | AF7 |
|
||||
| **USART3** | | |
|
||||
| PB10 | TX | AF7 |
|
||||
| PB11 | RX | AF7 |
|
||||
| PC10 | TX | AF7 |
|
||||
| PC11 | RX | AF7 |
|
||||
| PD8 | TX | AF7 |
|
||||
| PD9 | RX | AF7 |
|
||||
|
||||
### STM32F072 [Datasheet](https://www.st.com/resource/en/datasheet/stm32f072c8.pdf)
|
||||
|
||||
Pin Swap available: :heavy_check_mark:
|
||||
|
||||
| Pin | Function | Mode |
|
||||
| ------ | -------- | ---- |
|
||||
| USART1 | | |
|
||||
| PA9 | TX | AF1 |
|
||||
| PA10 | RX | AF1 |
|
||||
| PB6 | TX | AF0 |
|
||||
| PB7 | RX | AF0 |
|
||||
| USART2 | | |
|
||||
| PA2 | TX | AF1 |
|
||||
| PA3 | RX | AF1 |
|
||||
| PA14 | TX | AF1 |
|
||||
| PA15 | RX | AF1 |
|
||||
| USART3 | | |
|
||||
| PB10 | TX | AF4 |
|
||||
| PB11 | RX | AF4 |
|
||||
| PC4 | TX | AF1 |
|
||||
| PC5 | RX | AF1 |
|
||||
| PC10 | TX | AF1 |
|
||||
| PC11 | RX | AF1 |
|
||||
| PD8 | TX | AF0 |
|
||||
| PD9 | RX | AF0 |
|
||||
| USART4 | | |
|
||||
| PA0 | TX | AF4 |
|
||||
| PA1 | RX | AF4 |
|
||||
|
||||
### STM32F103 Medium Density (C8-CB) [Datasheet](https://www.st.com/resource/en/datasheet/stm32f103c8.pdf)
|
||||
|
||||
Pin Swap available: N/A
|
||||
|
||||
TX Pin is always Alternate Function Push-Pull, RX Pin is always regular input pin for any USART peripheral. **For STM32F103 no additional Alternate Function configuration is necessary. QMK is already configured.**
|
||||
|
||||
Pin remapping:
|
||||
|
||||
The pins of USART Peripherals use default Pins that can be remapped to use other pins using the AFIO registers. Default pins are marked **bold**. Add the appropriate defines to your config.h file.
|
||||
|
||||
| Pin | Function | Mode | USART_REMAP |
|
||||
| ---------- | -------- | ---- | ------------------- |
|
||||
| **USART1** | | | |
|
||||
| **PA9** | TX | AFPP | |
|
||||
| **PA10** | RX | IN | |
|
||||
| PB6 | TX | AFPP | USART1_REMAP |
|
||||
| PB7 | RX | IN | USART1_REMAP |
|
||||
| **USART2** | | | |
|
||||
| **PA2** | TX | AFPP | |
|
||||
| **PA3** | RX | IN | |
|
||||
| PD5 | TX | AFPP | USART2_REMAP |
|
||||
| PD6 | RX | IN | USART2_REMAP |
|
||||
| **USART3** | | | |
|
||||
| **PB10** | TX | AFPP | |
|
||||
| **PB11** | RX | IN | |
|
||||
| PC10 | TX | AFPP | USART3_PARTIALREMAP |
|
||||
| PC11 | RX | IN | USART3_PARTIALREMAP |
|
||||
| PD8 | TX | AFPP | USART3_FULLREMAP |
|
||||
| PD9 | RX | IN | USART3_FULLREMAP |
|
167
docs/drivers/spi.md
Normal file
167
docs/drivers/spi.md
Normal file
@ -0,0 +1,167 @@
|
||||
# SPI Master Driver {#spi-master-driver}
|
||||
|
||||
The SPI Master drivers used in QMK have a set of common functions to allow portability between MCUs.
|
||||
|
||||
## Usage {#usage}
|
||||
|
||||
In most cases, the SPI Master driver code is automatically included if you are using a feature or driver which requires it, such as [OLED](../features/oled_driver).
|
||||
|
||||
However, if you need to use the driver standalone, add the following to your `rules.mk`:
|
||||
|
||||
```make
|
||||
SPI_DRIVER_REQUIRED = yes
|
||||
```
|
||||
|
||||
You can then call the SPI API by including `spi_master.h` in your code.
|
||||
|
||||
## AVR Configuration {#avr-configuration}
|
||||
|
||||
No special setup is required - just connect the `SS`, `SCK`, `MOSI` and `MISO` pins of your SPI devices to the matching pins on the MCU:
|
||||
|
||||
|MCU |`SS`|`SCK`|`MOSI`|`MISO`|
|
||||
|-----------------|----|-----|------|------|
|
||||
|ATmega16/32U2/4 |`B0`|`B1` |`B2` |`B3` |
|
||||
|AT90USB64/128/162|`B0`|`B1` |`B2` |`B3` |
|
||||
|ATmega32A |`B4`|`B7` |`B5` |`B6` |
|
||||
|ATmega328/P |`B2`|`B5` |`B3` |`B4` |
|
||||
|
||||
You may use more than one slave select pin, not just the `SS` pin. This is useful when you have multiple devices connected and need to communicate with them individually.
|
||||
`SPI_SS_PIN` can be passed to `spi_start()` to refer to `SS`.
|
||||
|
||||
## ChibiOS/ARM Configuration {#arm-configuration}
|
||||
|
||||
You'll need to determine which pins can be used for SPI -- as an example, STM32 parts generally have multiple SPI peripherals, labeled SPI1, SPI2, SPI3 etc.
|
||||
|
||||
To enable SPI, modify your board's `halconf.h` to enable SPI:
|
||||
|
||||
```c
|
||||
#define HAL_USE_SPI TRUE
|
||||
#define SPI_USE_WAIT TRUE
|
||||
#define SPI_SELECT_MODE SPI_SELECT_MODE_PAD
|
||||
```
|
||||
|
||||
Then, modify your board's `mcuconf.h` to enable the peripheral you've chosen, for example:
|
||||
|
||||
```c
|
||||
#undef STM32_SPI_USE_SPI2
|
||||
#define STM32_SPI_USE_SPI2 TRUE
|
||||
```
|
||||
|
||||
Configuration-wise, you'll need to set up the peripheral as per your MCU's datasheet -- the defaults match the pins for a Proton-C, i.e. STM32F303.
|
||||
|
||||
|`config.h` Override|Description |Default|
|
||||
|-------------------|-------------------------------------------------------------|-------|
|
||||
|`SPI_DRIVER` |SPI peripheral to use - SPI1 -> `SPID1`, SPI2 -> `SPID2` etc.|`SPID2`|
|
||||
|`SPI_SCK_PIN` |The pin to use for SCK |`B13` |
|
||||
|`SPI_SCK_PAL_MODE` |The alternate function mode for SCK |`5` |
|
||||
|`SPI_MOSI_PIN` |The pin to use for MOSI |`B15` |
|
||||
|`SPI_MOSI_PAL_MODE`|The alternate function mode for MOSI |`5` |
|
||||
|`SPI_MISO_PIN` |The pin to use for MISO |`B14` |
|
||||
|`SPI_MISO_PAL_MODE`|The alternate function mode for MISO |`5` |
|
||||
|
||||
As per the AVR configuration, you may choose any other standard GPIO as a slave select pin, which should be supplied to `spi_start()`.
|
||||
|
||||
If a complete SPI interface is not required, then the following can be done to disable certain SPI pins, so they don't occupy a GPIO unnecessarily:
|
||||
- in `config.h`: `#define SPI_MISO_PIN NO_PIN`
|
||||
- in `config.h`: `#define SPI_MOSI_PIN NO_PIN`
|
||||
- in `mcuconf.h`: `#define SPI_SELECT_MODE SPI_SELECT_MODE_NONE`, in this case the `slavePin` argument passed to `spi_start()` may be `NO_PIN` if the slave select pin is not used.
|
||||
|
||||
## API {#api}
|
||||
|
||||
### `void spi_init(void)` {#api-spi-init}
|
||||
|
||||
Initialize the SPI driver. This function must be called only once, before any of the below functions can be called.
|
||||
|
||||
---
|
||||
|
||||
### `bool spi_start(pin_t slavePin, bool lsbFirst, uint8_t mode, uint16_t divisor)` {#api-spi-start}
|
||||
|
||||
Start an SPI transaction.
|
||||
|
||||
#### Arguments {#api-spi-start-arguments}
|
||||
|
||||
- `pin_t slavePin`
|
||||
The QMK pin to assert as the slave select pin, eg. `B4`.
|
||||
- `bool lsbFirst`
|
||||
Determines the endianness of the transmission. If `true`, the least significant bit of each byte is sent first.
|
||||
- `uint8_t mode`
|
||||
The SPI mode to use:
|
||||
|
||||
|Mode|Clock Polarity |Clock Phase |
|
||||
|----|--------------------|-----------------------|
|
||||
|`0` |Leading edge rising |Sample on leading edge |
|
||||
|`1` |Leading edge rising |Sample on trailing edge|
|
||||
|`2` |Leading edge falling|Sample on leading edge |
|
||||
|`3` |Leading edge falling|Sample on trailing edge|
|
||||
|
||||
- `uint16_t divisor`
|
||||
The SPI clock divisor, will be rounded up to the nearest power of two. This number can be calculated by dividing the MCU's clock speed by the desired SPI clock speed. For example, an MCU running at 8 MHz wanting to talk to an SPI device at 4 MHz would set the divisor to `2`.
|
||||
|
||||
#### Return Value {#api-spi-start-return}
|
||||
|
||||
`false` if the supplied parameters are invalid or the SPI peripheral is already in use, or `true`.
|
||||
|
||||
---
|
||||
|
||||
### `spi_status_t spi_write(uint8_t data)` {#api-spi-write}
|
||||
|
||||
Write a byte to the selected SPI device.
|
||||
|
||||
#### Arguments {#api-spi-write-arguments}
|
||||
|
||||
- `uint8_t data`
|
||||
The byte to write.
|
||||
|
||||
#### Return Value {#api-spi-write-return}
|
||||
|
||||
`SPI_STATUS_TIMEOUT` if the timeout period elapses, or `SPI_STATUS_SUCCESS`.
|
||||
|
||||
---
|
||||
|
||||
### `spi_status_t spi_read(void)` {#api-spi-read}
|
||||
|
||||
Read a byte from the selected SPI device.
|
||||
|
||||
#### Return Value {#api-spi-read-return}
|
||||
|
||||
`SPI_STATUS_TIMEOUT` if the timeout period elapses, or the byte read from the device.
|
||||
|
||||
---
|
||||
|
||||
### `spi_status_t spi_transmit(const uint8_t *data, uint16_t length)` {#api-spi-transmit}
|
||||
|
||||
Send multiple bytes to the selected SPI device.
|
||||
|
||||
#### Arguments {#api-spi-transmit-arguments}
|
||||
|
||||
- `const uint8_t *data`
|
||||
A pointer to the data to write from.
|
||||
- `uint16_t length`
|
||||
The number of bytes to write. Take care not to overrun the length of `data`.
|
||||
|
||||
#### Return Value {#api-spi-transmit-return}
|
||||
|
||||
`SPI_STATUS_TIMEOUT` if the timeout period elapses, `SPI_STATUS_ERROR` if some other error occurs, otherwise `SPI_STATUS_SUCCESS`.
|
||||
|
||||
---
|
||||
|
||||
### `spi_status_t spi_receive(uint8_t *data, uint16_t length)` {#api-spi-receive}
|
||||
|
||||
Receive multiple bytes from the selected SPI device.
|
||||
|
||||
#### Arguments {#api-spi-receive-arguments}
|
||||
|
||||
- `uint8_t *data`
|
||||
A pointer to the buffer to read into.
|
||||
- `uint16_t length`
|
||||
The number of bytes to read. Take care not to overrun the length of `data`.
|
||||
|
||||
#### Return Value {#api-spi-receive-return}
|
||||
|
||||
`SPI_STATUS_TIMEOUT` if the timeout period elapses, `SPI_STATUS_ERROR` if some other error occurs, otherwise `SPI_STATUS_SUCCESS`.
|
||||
|
||||
---
|
||||
|
||||
### `void spi_stop(void)` {#api-spi-stop}
|
||||
|
||||
End the current SPI transaction. This will deassert the slave select pin and reset the endianness, mode and divisor configured by `spi_start()`.
|
122
docs/drivers/uart.md
Normal file
122
docs/drivers/uart.md
Normal file
@ -0,0 +1,122 @@
|
||||
# UART Driver {#uart-driver}
|
||||
|
||||
The UART drivers used in QMK have a set of common functions to allow portability between MCUs.
|
||||
|
||||
Currently, this driver does not support enabling hardware flow control (the `RTS` and `CTS` pins) if available, but may do so in future.
|
||||
|
||||
## Usage {#usage}
|
||||
|
||||
In most cases, the UART driver code is automatically included if you are using a feature or driver which requires it.
|
||||
|
||||
However, if you need to use the driver standalone, add the following to your `rules.mk`:
|
||||
|
||||
```make
|
||||
UART_DRIVER_REQUIRED = yes
|
||||
```
|
||||
|
||||
You can then call the UART API by including `uart.h` in your code.
|
||||
|
||||
## AVR Configuration {#avr-configuration}
|
||||
|
||||
No special setup is required - just connect the `RX` and `TX` pins of your UART device to the opposite pins on the MCU:
|
||||
|
||||
|MCU |`TX`|`RX`|`CTS`|`RTS`|
|
||||
|-------------|----|----|-----|-----|
|
||||
|ATmega16/32U2|`D3`|`D2`|`D7` |`D6` |
|
||||
|ATmega16/32U4|`D3`|`D2`|`D5` |`B7` |
|
||||
|AT90USB64/128|`D3`|`D2`|*n/a*|*n/a*|
|
||||
|ATmega32A |`D1`|`D0`|*n/a*|*n/a*|
|
||||
|ATmega328/P |`D1`|`D0`|*n/a*|*n/a*|
|
||||
|
||||
## ChibiOS/ARM Configuration {#arm-configuration}
|
||||
|
||||
You'll need to determine which pins can be used for UART -- as an example, STM32 parts generally have multiple UART peripherals, labeled USART1, USART2, USART3 etc.
|
||||
|
||||
To enable UART, modify your board's `mcuconf.h` to enable the peripheral you've chosen, for example:
|
||||
|
||||
```c
|
||||
#undef STM32_SERIAL_USE_USART2
|
||||
#define STM32_SERIAL_USE_USART2 TRUE
|
||||
```
|
||||
|
||||
Configuration-wise, you'll need to set up the peripheral as per your MCU's datasheet -- the defaults match the pins for a Proton-C, i.e. STM32F303.
|
||||
|
||||
| `config.h` override | Description | Default Value |
|
||||
| --------------------------- | --------------------------------------------------------------- | ------------- |
|
||||
| `#define UART_DRIVER` | USART peripheral to use - USART1 -> `SD1`, USART2 -> `SD2` etc. | `SD1` |
|
||||
| `#define UART_TX_PIN` | The pin to use for TX | `A9` |
|
||||
| `#define UART_TX_PAL_MODE` | The alternate function mode for TX | `7` |
|
||||
| `#define UART_RX_PIN` | The pin to use for RX | `A10` |
|
||||
| `#define UART_RX_PAL_MODE` | The alternate function mode for RX | `7` |
|
||||
| `#define UART_CTS_PIN` | The pin to use for CTS | `A11` |
|
||||
| `#define UART_CTS_PAL_MODE` | The alternate function mode for CTS | `7` |
|
||||
| `#define UART_RTS_PIN` | The pin to use for RTS | `A12` |
|
||||
| `#define UART_RTS_PAL_MODE` | The alternate function mode for RTS | `7` |
|
||||
|
||||
## API {#api}
|
||||
|
||||
### `void uart_init(uint32_t baud)` {#api-uart-init}
|
||||
|
||||
Initialize the UART driver. This function must be called only once, before any of the below functions can be called.
|
||||
|
||||
#### Arguments {#api-uart-init-arguments}
|
||||
|
||||
- `uint32_t baud`
|
||||
The baud rate to transmit and receive at. This may depend on the device you are communicating with. Common values are 1200, 2400, 4800, 9600, 19200, 38400, 57600, and 115200.
|
||||
|
||||
---
|
||||
|
||||
### `void uart_write(uint8_t data)` {#api-uart-write}
|
||||
|
||||
Transmit a single byte.
|
||||
|
||||
#### Arguments {#api-uart-write-arguments}
|
||||
|
||||
- `uint8_t data`
|
||||
The byte to write.
|
||||
|
||||
---
|
||||
|
||||
### `uint8_t uart_read(void)` {#api-uart-read}
|
||||
|
||||
Receive a single byte.
|
||||
|
||||
#### Return Value {#api-uart-read-return}
|
||||
|
||||
The byte read from the receive buffer. This function will block if the buffer is empty (ie. no data to read).
|
||||
|
||||
---
|
||||
|
||||
### `void uart_transmit(const uint8_t *data, uint16_t length)` {#api-uart-transmit}
|
||||
|
||||
Transmit multiple bytes.
|
||||
|
||||
#### Arguments {#api-uart-transmit-arguments}
|
||||
|
||||
- `const uint8_t *data`
|
||||
A pointer to the data to write from.
|
||||
- `uint16_t length`
|
||||
The number of bytes to write. Take care not to overrun the length of `data`.
|
||||
|
||||
---
|
||||
|
||||
### `void uart_receive(char *data, uint16_t length)` {#api-uart-receive}
|
||||
|
||||
Receive multiple bytes.
|
||||
|
||||
#### Arguments {#api-uart-receive-arguments}
|
||||
|
||||
- `uint8_t *data`
|
||||
A pointer to the buffer to read into.
|
||||
- `uint16_t length`
|
||||
The number of bytes to read. Take care not to overrun the length of `data`.
|
||||
|
||||
---
|
||||
|
||||
### `bool uart_available(void)` {#api-uart-available}
|
||||
|
||||
Return whether the receive buffer contains data. Call this function to determine if `uart_read()` will return data immediately.
|
||||
|
||||
#### Return Value {#api-uart-available-return}
|
||||
|
||||
`true` if the receive buffer length is non-zero.
|
253
docs/drivers/ws2812.md
Normal file
253
docs/drivers/ws2812.md
Normal file
@ -0,0 +1,253 @@
|
||||
# WS2812 Driver {#ws2812-driver}
|
||||
|
||||
This driver provides support for WorldSemi addressable RGB(W) LEDs, and compatible equivalents:
|
||||
|
||||
* WS2811, WS2812, WS2812B, WS2812C, etc.
|
||||
* SK6812, SK6812MINI, SK6805
|
||||
|
||||
These LEDs are often called "addressable" because instead of using a wire per color (and per LED), each LED contains a small microchip that understands a special protocol sent over a single wire.
|
||||
The LEDs can be chained together, and the remaining data is passed on to the next. In this way, you can easily control the color of many LEDs using a single GPIO.
|
||||
|
||||
## Usage {#usage}
|
||||
|
||||
In most cases, the WS2812 driver code is automatically included if you are using either the [RGBLight](../features/rgblight) or [RGB Matrix](../features/rgb_matrix) feature with the `ws2812` driver set, and you would use those APIs instead.
|
||||
|
||||
However, if you need to use the driver standalone, add the following to your `rules.mk`:
|
||||
|
||||
```make
|
||||
WS2812_DRIVER_REQUIRED = yes
|
||||
```
|
||||
|
||||
You can then call the WS2812 API by including `ws2812.h` in your code.
|
||||
|
||||
## Basic Configuration {#basic-configuration}
|
||||
|
||||
Add the following to your `config.h`:
|
||||
|
||||
|Define |Default |Description |
|
||||
|-------------------|-----------------------|------------------------------------------------------------------------------------------------|
|
||||
|`WS2812_DI_PIN` |*Not defined* |The GPIO pin connected to the DI pin of the first LED in the chain |
|
||||
|`WS2812_LED_COUNT` |*Not defined* |Number of LEDs in the WS2812 chain - automatically set when RGBLight or RGB Matrix is configured|
|
||||
|`WS2812_TIMING` |`1250` |The total length of a bit (TH+TL) in nanoseconds |
|
||||
|`WS2812_T1H` |`900` |The length of a "1" bit's high phase in nanoseconds |
|
||||
|`WS2812_T0H` |`350` |The length of a "0" bit's high phase in nanoseconds |
|
||||
|`WS2812_TRST_US` |`280` |The length of the reset phase in microseconds |
|
||||
|`WS2812_BYTE_ORDER`|`WS2812_BYTE_ORDER_GRB`|The byte order of the RGB data |
|
||||
|`WS2812_RGBW` |*Not defined* |Enables RGBW support (except `i2c` driver) |
|
||||
|
||||
### Timing Adjustment {#timing-adjustment}
|
||||
|
||||
The WS2812 LED communication protocol works by encoding a "1" bit with a long high pulse (T<sub>1</sub>H), and a "0" bit with a shorter pulse (T<sub>0</sub>H). The total cycle length of a bit is the same.
|
||||
The "reset" pulse (T<sub>RST</sub>) latches the sent RGB data to all of the LEDs and denotes a completed "frame".
|
||||
|
||||
Some WS2812 variants have slightly different timing parameter requirements, which can be accounted for if necessary using the above `#define`s in your `config.h`.
|
||||
|
||||
### Byte Order {#byte-order}
|
||||
|
||||
Some WS2812 variants may have their color components in a different physical or logical order. For example, the WS2812B-2020 has physically swapped red and green LEDs, which causes the wrong color to be displayed, because the default order of the bytes sent over the wire is defined as GRB.
|
||||
If you find your LED colors are consistently swapped, you may need to change the byte order by adding the following to your `config.h`:
|
||||
|
||||
```c
|
||||
#define WS2812_BYTE_ORDER WS2812_BYTE_ORDER_GRB
|
||||
```
|
||||
|
||||
Where the byte order may be one of:
|
||||
|
||||
|Byte Order|Known Devices |
|
||||
|----------|----------------------------|
|
||||
|`GRB` |Most WS2812s, SK6812, SK6805|
|
||||
|`RGB` |WS2812B-2020 |
|
||||
|`BGR` |TM1812 |
|
||||
|
||||
### RGBW Support {#rgbw-support}
|
||||
|
||||
Rendering the color white with RGB LEDs is typically inconsistent due to inherent variations between each individual LED die. However, some WS2812 variants (such as SK6812RGBW) also possess a white LED along with the red, green, and blue channels, which allows for a more accurate white to be displayed.
|
||||
|
||||
QMK can automatically convert the RGB data to be sent to the LEDs to mix in the white channel:
|
||||
|
||||
```
|
||||
w = min(r, g, b)
|
||||
r -= w
|
||||
g -= w
|
||||
b -= w
|
||||
```
|
||||
|
||||
Thus, an RGB triplet of `255,255,255` will simply turn on the white LED fully (`0,0,0,255`).
|
||||
|
||||
To enable RGBW conversion, add the following to your `config.h`:
|
||||
|
||||
```c
|
||||
#define WS2812_RGBW
|
||||
```
|
||||
|
||||
## Driver Configuration {#driver-configuration}
|
||||
|
||||
Driver selection can be configured in `rules.mk` as `WS2812_DRIVER`, or in `info.json` as `ws2812.driver`. Valid values are `bitbang` (default), `i2c`, `spi`, `pwm`, `vendor`, or `custom`. See below for information on individual drivers.
|
||||
|
||||
### Bitbang Driver {#bitbang-driver}
|
||||
|
||||
This is the default WS2812 driver. It operates by "bit-banging" ie. directly toggling the GPIO.
|
||||
|
||||
Please note that on AVR devices, due to the tight timing requirements longer chains and/or heavy CPU loads may cause visible lag. Unfortunately this driver is usually the only option for AVR.
|
||||
|
||||
```make
|
||||
WS2812_DRIVER = bitbang
|
||||
```
|
||||
|
||||
### I2C Driver {#i2c-driver}
|
||||
|
||||
A specialized driver mainly used for PS2AVRGB (Bootmapper Client) boards, which possess an ATtiny85 that handles the WS2812 LEDs.
|
||||
|
||||
```make
|
||||
WS2812_DRIVER = i2c
|
||||
```
|
||||
|
||||
The following `#define`s apply only to the `i2c` driver:
|
||||
|
||||
|Define |Default|Description |
|
||||
|--------------------|-------|---------------------------------|
|
||||
|`WS2812_I2C_ADDRESS`|`0xB0` |The I2C address of the ATtiny85. |
|
||||
|`WS2812_I2C_TIMEOUT`|`100` |The I2C timeout, in milliseconds.|
|
||||
|
||||
### PIO Driver {#pio-driver}
|
||||
|
||||
This driver is RP2040-only, and leverages the onboard PIO (programmable I/O) system and DMA to offload processing from the CPU.
|
||||
|
||||
The WS2812 PIO program uses one state machine, six instructions and one DMA interrupt handler callback. Due to the implementation the time resolution for this driver is 50 ns - any value not specified in this interval will be rounded to the next matching interval.
|
||||
|
||||
```make
|
||||
WS2812_DRIVER = vendor
|
||||
```
|
||||
|
||||
### PWM Driver {#pwm-driver}
|
||||
|
||||
This driver is ARM-only, and leverages the onboard PWM peripheral and DMA to offload processing from the CPU.
|
||||
|
||||
```make
|
||||
WS2812_DRIVER = pwm
|
||||
```
|
||||
|
||||
### SPI Driver {#spi-driver}
|
||||
|
||||
This driver is ARM-only, and leverages the onboard SPI peripheral and DMA to offload processing from the CPU. The DI pin **must** be connected to the MOSI pin on the MCU, and all other SPI pins **must** be left unused. This is also very dependent on your MCU's SPI peripheral clock speed, and may or may not be possible depending on the MCU selected.
|
||||
|
||||
```make
|
||||
WS2812_DRIVER = spi
|
||||
```
|
||||
|
||||
## ChibiOS/ARM Configuration {#arm-configuration}
|
||||
|
||||
The following defines apply only to ARM devices:
|
||||
|
||||
|Define |Default |Description |
|
||||
|------------|------------------------------|---------------------------------------------------------------------------------|
|
||||
|`WS2812_T1L`|`(WS2812_TIMING - WS2812_T1H)`|The length of a "1" bit's low phase in nanoseconds (bitbang and PIO drivers only)|
|
||||
|`WS2812_T0L`|`(WS2812_TIMING - WS2812_T0H)`|The length of a "0" bit's low phase in nanoseconds (bitbang and PIO drivers only)|
|
||||
|
||||
### Push-Pull and Open Drain {#push-pull-open-drain}
|
||||
|
||||
By default, the GPIO used for data transmission is configured as a *push-pull* output, meaning the pin is effectively always driven either to VCC or to ground.
|
||||
|
||||
For situations where the logic level voltage is lower than the power supply voltage, however, this can pose an issue. The solution is to configure the pin for *open drain* mode instead, and use a pullup resistor between the DI pin and VCC. In this mode, the MCU can only pull the GPIO *low*, or leave it floating. The pullup resistor is then responsible for pulling the line high, when the MCU is not driving the GPIO.
|
||||
|
||||
To configure the DI pin for open drain configuration, add the following to your `config.h`:
|
||||
|
||||
```c
|
||||
#define WS2812_EXTERNAL_PULLUP
|
||||
```
|
||||
|
||||
### SPI Driver {#arm-spi-driver}
|
||||
|
||||
Depending on the ChibiOS board configuration, you may need to enable SPI at the keyboard level. For STM32, this would look like:
|
||||
|
||||
`halconf.h`:
|
||||
```c
|
||||
#define HAL_USE_SPI TRUE
|
||||
```
|
||||
`mcuconf.h`:
|
||||
```c
|
||||
#undef STM32_SPI_USE_SPI1
|
||||
#define STM32_SPI_USE_SPI1 TRUE
|
||||
```
|
||||
|
||||
The following `define`s apply only to the `spi` driver:
|
||||
|
||||
|Define |Default |Description |
|
||||
|--------------------------------|-------------|-------------------------------------------------------------------------------|
|
||||
|`WS2812_SPI_DRIVER` |`SPID1` |The SPI driver to use |
|
||||
|`WS2812_SPI_MOSI_PAL_MODE` |`5` |The MOSI pin alternative function to use |
|
||||
|`WS2812_SPI_SCK_PIN` |*Not defined*|The SCK pin - required for F072 and possibly others |
|
||||
|`WS2812_SPI_SCK_PAL_MODE` |`5` |The SCK pin alternative function to use - required for F072 and possibly others|
|
||||
|`WS2812_SPI_DIVISOR` |`16` |The divisor used to adjust the baudrate |
|
||||
|`WS2812_SPI_USE_CIRCULAR_BUFFER`|*Not defined*|Enable a circular buffer for improved rendering |
|
||||
|
||||
#### Setting the Baudrate {#arm-spi-baudrate}
|
||||
|
||||
To adjust the SPI baudrate, you will need to derive the target baudrate from the clock tree provided by STM32CubeMX, and add the following to your `config.h`:
|
||||
|
||||
```c
|
||||
#define WS2812_SPI_DIVISOR 16
|
||||
```
|
||||
|
||||
Only divisors of 2, 4, 8, 16, 32, 64, 128 and 256 are supported on STM32 devices. Other MCUs may have similar constraints -- check the reference manual for your respective MCU for specifics.
|
||||
|
||||
#### Circular Buffer {#arm-spi-circular-buffer}
|
||||
|
||||
A circular buffer can be enabled if you experience flickering.
|
||||
|
||||
To enable the circular buffer, add the following to your `config.h`:
|
||||
|
||||
```c
|
||||
#define WS2812_SPI_USE_CIRCULAR_BUFFER
|
||||
```
|
||||
|
||||
### PIO Driver {#arm-pio-driver}
|
||||
|
||||
The following `#define`s apply only to the PIO driver:
|
||||
|
||||
|Define |Default |Description |
|
||||
|---------------------|-------------|---------------------------------------|
|
||||
|`WS2812_PIO_USE_PIO1`|*Not defined*|Use the PIO1 peripheral instead of PIO0|
|
||||
|
||||
### PWM Driver {#arm-pwm-driver}
|
||||
|
||||
Depending on the ChibiOS board configuration, you may need to enable PWM at the keyboard level. For STM32, this would look like:
|
||||
|
||||
`halconf.h`:
|
||||
```c
|
||||
#define HAL_USE_PWM TRUE
|
||||
```
|
||||
`mcuconf.h`:
|
||||
```c
|
||||
#undef STM32_PWM_USE_TIM2
|
||||
#define STM32_PWM_USE_TIM2 TRUE
|
||||
```
|
||||
|
||||
The following `#define`s apply only to the `pwm` driver:
|
||||
|
||||
|Define |Default |Description |
|
||||
|---------------------------------|--------------------|------------------------------------------------------------------------------------------|
|
||||
|`WS2812_PWM_DRIVER` |`PWMD2` |The PWM driver to use |
|
||||
|`WS2812_PWM_CHANNEL` |`2` |The PWM channel to use |
|
||||
|`WS2812_PWM_PAL_MODE` |`2` |The pin alternative function to use |
|
||||
|`WS2812_PWM_DMA_STREAM` |`STM32_DMA1_STREAM2`|The DMA Stream for `TIMx_UP` |
|
||||
|`WS2812_PWM_DMA_CHANNEL` |`2` |The DMA Channel for `TIMx_UP` |
|
||||
|`WS2812_PWM_DMAMUX_ID` |*Not defined* |The DMAMUX configuration for `TIMx_UP` - only required if your MCU has a DMAMUX peripheral|
|
||||
|`WS2812_PWM_COMPLEMENTARY_OUTPUT`|*Not defined* |Whether the PWM output is complementary (`TIMx_CHyN`) |
|
||||
|
||||
::: tip
|
||||
Using a complementary timer output (`TIMx_CHyN`) is possible only for advanced-control timers (1, 8 and 20 on STM32), and the `STM32_PWM_USE_ADVANCED` option in `mcuconf.h` must be set to `TRUE`. Complementary outputs of general-purpose timers are not supported due to ChibiOS limitations.
|
||||
:::
|
||||
|
||||
## API {#api}
|
||||
|
||||
### `void ws2812_setleds(rgb_led_t *ledarray, uint16_t number_of_leds)` {#api-ws2812-setleds}
|
||||
|
||||
Send RGB data to the WS2812 LED chain.
|
||||
|
||||
#### Arguments {#api-ws2812-setleds-arguments}
|
||||
|
||||
- `rgb_led_t *ledarray`
|
||||
A pointer to the LED array.
|
||||
- `uint16_t number_of_leds`
|
||||
The length of the LED array.
|
@ -5,7 +5,7 @@ Have you ever needed an easy way to program a controller, such as a Proton C or
|
||||
There are different styles of Easy Maker available depending on your needs:
|
||||
|
||||
* [Direct Pin](https://config.qmk.fm/#/?filter=ez_maker/direct) - Connect a single switch to a single pin
|
||||
* Direct Pin + Backlight (Coming Soon) - Like Direct Pin but dedicates a single pin to [Backlight](feature_backlight.md) control
|
||||
* Direct Pin + Backlight (Coming Soon) - Like Direct Pin but dedicates a single pin to [Backlight](features/backlight) control
|
||||
* Direct Pin + Numlock (Coming Soon) - Like Direct Pin but dedicates a single pin to the Numlock LED
|
||||
* Direct Pin + Capslock (Coming Soon) - Like Direct Pin but dedicates a single pin to the Capslock LED
|
||||
* Direct Pin + Encoder (Coming Soon) - Like Direct Pin but uses 2 pins to add a single rotary encoder
|
||||
|
@ -1,168 +0,0 @@
|
||||
# EEPROM Driver Configuration :id=eeprom-driver-configuration
|
||||
|
||||
The EEPROM driver can be swapped out depending on the needs of the keyboard, or whether extra hardware is present.
|
||||
|
||||
Selecting the EEPROM driver is done in your keyboard's `rules.mk`:
|
||||
|
||||
Driver | Description
|
||||
-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
`EEPROM_DRIVER = vendor` (default) | Uses the on-chip driver provided by the chip manufacturer. For AVR, this is provided by avr-libc. This is supported on ARM for a subset of chips -- STM32F3xx, STM32F1xx, and STM32F072xB will be emulated by writing to flash. STM32L0xx and STM32L1xx will use the onboard dedicated true EEPROM. Other chips will generally act as "transient" below.
|
||||
`EEPROM_DRIVER = i2c` | Supports writing to I2C-based 24xx EEPROM chips. See the driver section below.
|
||||
`EEPROM_DRIVER = spi` | Supports writing to SPI-based 25xx EEPROM chips. See the driver section below.
|
||||
`EEPROM_DRIVER = transient` | Fake EEPROM driver -- supports reading/writing to RAM, and will be discarded when power is lost.
|
||||
`EEPROM_DRIVER = wear_leveling` | Frontend driver for the wear_leveling system, allowing for EEPROM emulation on top of flash -- both in-MCU and external SPI NOR flash.
|
||||
|
||||
## Vendor Driver Configuration :id=vendor-eeprom-driver-configuration
|
||||
|
||||
#### STM32 L0/L1 Configuration :id=stm32l0l1-eeprom-driver-configuration
|
||||
|
||||
!> Resetting EEPROM using an STM32L0/L1 device takes up to 1 second for every 1kB of internal EEPROM used.
|
||||
|
||||
`config.h` override | Description | Default Value
|
||||
------------------------------------|--------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------
|
||||
`#define STM32_ONBOARD_EEPROM_SIZE` | The size of the EEPROM to use, in bytes. Erase times can be high, so it's configurable here, if not using the default value. | Minimum required to cover base _eeconfig_ data, or `1024` if VIA is enabled.
|
||||
|
||||
## I2C Driver Configuration :id=i2c-eeprom-driver-configuration
|
||||
|
||||
Currently QMK supports 24xx-series chips over I2C. As such, requires a working i2c_master driver configuration. You can override the driver configuration via your config.h:
|
||||
|
||||
`config.h` override | Description | Default Value
|
||||
------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------
|
||||
`#define EXTERNAL_EEPROM_I2C_BASE_ADDRESS` | Base I2C address for the EEPROM -- shifted left by 1 as per i2c_master requirements | 0b10100000
|
||||
`#define EXTERNAL_EEPROM_I2C_ADDRESS(addr)` | Calculated I2C address for the EEPROM | `(EXTERNAL_EEPROM_I2C_BASE_ADDRESS)`
|
||||
`#define EXTERNAL_EEPROM_BYTE_COUNT` | Total size of the EEPROM in bytes | 8192
|
||||
`#define EXTERNAL_EEPROM_PAGE_SIZE` | Page size of the EEPROM in bytes, as specified in the datasheet | 32
|
||||
`#define EXTERNAL_EEPROM_ADDRESS_SIZE` | The number of bytes to transmit for the memory location within the EEPROM | 2
|
||||
`#define EXTERNAL_EEPROM_WRITE_TIME` | Write cycle time of the EEPROM, as specified in the datasheet | 5
|
||||
`#define EXTERNAL_EEPROM_WP_PIN` | If defined the WP pin will be toggled appropriately when writing to the EEPROM. | _none_
|
||||
|
||||
Some I2C EEPROM manufacturers explicitly recommend against hardcoding the WP pin to ground. This is in order to protect the eeprom memory content during power-up/power-down/brown-out conditions at low voltage where the eeprom is still operational, but the i2c master output might be unpredictable. If a WP pin is configured, then having an external pull-up on the WP pin is recommended.
|
||||
|
||||
Default values and extended descriptions can be found in `drivers/eeprom/eeprom_i2c.h`.
|
||||
|
||||
Alternatively, there are pre-defined hardware configurations for available chips/modules:
|
||||
|
||||
Module | Equivalent `#define` | Source
|
||||
-----------------|---------------------------------|------------------------------------------
|
||||
CAT24C512 EEPROM | `#define EEPROM_I2C_CAT24C512` | <https://www.sparkfun.com/products/14764>
|
||||
RM24C512C EEPROM | `#define EEPROM_I2C_RM24C512C` | <https://www.sparkfun.com/products/14764>
|
||||
24LC32A EEPROM | `#define EEPROM_I2C_24LC32A` | <https://www.microchip.com/en-us/product/24LC32A>
|
||||
24LC64 EEPROM | `#define EEPROM_I2C_24LC64` | <https://www.microchip.com/en-us/product/24LC64>
|
||||
24LC128 EEPROM | `#define EEPROM_I2C_24LC128` | <https://www.microchip.com/en-us/product/24LC128>
|
||||
24LC256 EEPROM | `#define EEPROM_I2C_24LC256` | <https://www.sparkfun.com/products/525>
|
||||
MB85RC256V FRAM | `#define EEPROM_I2C_MB85RC256V` | <https://www.adafruit.com/product/1895>
|
||||
|
||||
?> If you find that the EEPROM is not cooperating, ensure you've correctly shifted up your EEPROM address by 1. For example, the datasheet might state the address as `0b01010000` -- the correct value of `EXTERNAL_EEPROM_I2C_BASE_ADDRESS` needs to be `0b10100000`.
|
||||
|
||||
## SPI Driver Configuration :id=spi-eeprom-driver-configuration
|
||||
|
||||
Currently QMK supports 25xx-series chips over SPI. As such, requires a working spi_master driver configuration. You can override the driver configuration via your config.h:
|
||||
|
||||
`config.h` override | Default Value | Description
|
||||
-----------------------------------------------|---------------|-------------------------------------------------------------------------------------
|
||||
`#define EXTERNAL_EEPROM_SPI_SLAVE_SELECT_PIN` | _none_ | SPI Slave select pin in order to inform that the EEPROM is currently being addressed
|
||||
`#define EXTERNAL_EEPROM_SPI_CLOCK_DIVISOR` | `64` | Clock divisor used to divide the peripheral clock to derive the SPI frequency
|
||||
`#define EXTERNAL_EEPROM_BYTE_COUNT` | `8192` | Total size of the EEPROM in bytes
|
||||
`#define EXTERNAL_EEPROM_PAGE_SIZE` | `32` | Page size of the EEPROM in bytes, as specified in the datasheet
|
||||
`#define EXTERNAL_EEPROM_ADDRESS_SIZE` | `2` | The number of bytes to transmit for the memory location within the EEPROM
|
||||
|
||||
Default values and extended descriptions can be found in `drivers/eeprom/eeprom_spi.h`.
|
||||
|
||||
Alternatively, there are pre-defined hardware configurations for available chips/modules:
|
||||
|
||||
Module | Equivalent `#define` | Source
|
||||
-----------------|---------------------------------|------------------------------------------
|
||||
MB85RS64V FRAM | `define EEPROM_SPI_MB85RS64V` | <https://www.adafruit.com/product/1897>
|
||||
|
||||
!> There's no way to determine if there is an SPI EEPROM actually responding. Generally, this will result in reads of nothing but zero.
|
||||
|
||||
## Transient Driver configuration :id=transient-eeprom-driver-configuration
|
||||
|
||||
The only configurable item for the transient EEPROM driver is its size:
|
||||
|
||||
`config.h` override | Description | Default Value
|
||||
------------------------------- | ----------------------------------------- | -------------
|
||||
`#define TRANSIENT_EEPROM_SIZE` | Total size of the EEPROM storage in bytes | 64
|
||||
|
||||
Default values and extended descriptions can be found in `drivers/eeprom/eeprom_transient.h`.
|
||||
|
||||
## Wear-leveling Driver Configuration :id=wear_leveling-eeprom-driver-configuration
|
||||
|
||||
The wear-leveling driver uses an algorithm to minimise the number of erase cycles on the underlying MCU flash memory.
|
||||
|
||||
There is no specific configuration for this driver, but the wear-leveling system used by this driver may need configuration. See the [wear-leveling configuration](#wear_leveling-configuration) section for more information.
|
||||
|
||||
# Wear-leveling Configuration :id=wear_leveling-configuration
|
||||
|
||||
The wear-leveling driver has a few possible _backing stores_ that may be used by adding to your keyboard's `rules.mk` file:
|
||||
|
||||
Driver | Description
|
||||
----------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
`WEAR_LEVELING_DRIVER = embedded_flash` | This driver is used for emulating EEPROM by writing to embedded flash on the MCU.
|
||||
`WEAR_LEVELING_DRIVER = spi_flash` | This driver is used to address external SPI NOR Flash peripherals.
|
||||
`WEAR_LEVELING_DRIVER = rp2040_flash` | This driver is used to write to the same storage the RP2040 executes code from.
|
||||
`WEAR_LEVELING_DRIVER = legacy` | This driver is the "legacy" emulated EEPROM provided in historical revisions of QMK. Currently used for STM32F0xx and STM32F4x1, but slated for deprecation and removal once `embedded_flash` support for those MCU families is complete.
|
||||
|
||||
!> All wear-leveling drivers require an amount of RAM equivalent to the selected logical EEPROM size. Increasing the size to 32kB of EEPROM requires 32kB of RAM, which a significant number of MCUs simply do not have.
|
||||
|
||||
## Wear-leveling Embedded Flash Driver Configuration :id=wear_leveling-efl-driver-configuration
|
||||
|
||||
This driver performs writes to the embedded flash storage embedded in the MCU. In most circumstances, the last few of sectors of flash are used in order to minimise the likelihood of collision with program code.
|
||||
|
||||
Configurable options in your keyboard's `config.h`:
|
||||
|
||||
`config.h` override | Default | Description
|
||||
-----------------------------------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
`#define WEAR_LEVELING_EFL_FIRST_SECTOR` | _unset_ | The first sector on the MCU to use. By default this is not defined and calculated at runtime based on the MCU. However, different flash sizes on MCUs may require custom configuration.
|
||||
`#define WEAR_LEVELING_EFL_FLASH_SIZE` | _unset_ | Allows overriding the flash size available for use for wear-leveling. Under normal circumstances this is automatically calculated and should not need to be overridden. Specifying a size larger than the amount actually available in flash will usually prevent the MCU from booting.
|
||||
`#define WEAR_LEVELING_LOGICAL_SIZE` | `(backing_size/2)` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM.
|
||||
`#define WEAR_LEVELING_BACKING_SIZE` | `2048` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size.
|
||||
`#define BACKING_STORE_WRITE_SIZE` | _automatic_ | The byte width of the underlying write used on the MCU, and is usually automatically determined from the selected MCU family. If an error occurs in the auto-detection, you'll need to consult the MCU's datasheet and determine this value, specifying it directly.
|
||||
|
||||
!> If your MCU does not boot after swapping to the EFL wear-leveling driver, it's likely that the flash size is incorrectly detected, usually as an MCU with larger flash and may require overriding.
|
||||
|
||||
## Wear-leveling SPI Flash Driver Configuration :id=wear_leveling-flash_spi-driver-configuration
|
||||
|
||||
This driver performs writes to an external SPI NOR Flash peripheral. It also requires a working configuration for the SPI NOR Flash peripheral -- see the [flash driver](flash_driver.md) documentation for more information.
|
||||
|
||||
Configurable options in your keyboard's `config.h`:
|
||||
|
||||
`config.h` override | Default | Description
|
||||
----------------------------------------------------|--------------------------------|--------------------------------------------------------------------------------------------------------------------------------
|
||||
`#define WEAR_LEVELING_EXTERNAL_FLASH_BLOCK_COUNT` | `1` | Number of blocks in the external flash used by the wear-leveling algorithm.
|
||||
`#define WEAR_LEVELING_EXTERNAL_FLASH_BLOCK_OFFSET` | `0` | The index first block in the external flash used by the wear-leveling algorithm.
|
||||
`#define WEAR_LEVELING_LOGICAL_SIZE` | `((block_count*block_size)/2)` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM. Result must be <= 64kB.
|
||||
`#define WEAR_LEVELING_BACKING_SIZE` | `(block_count*block_size)` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size.
|
||||
`#define BACKING_STORE_WRITE_SIZE` | `8` | The write width used whenever a write is performed on the external flash peripheral.
|
||||
|
||||
!> There is currently a limit of 64kB for the EEPROM subsystem within QMK, so using a larger flash is not going to be beneficial as the logical size cannot be increased beyond 65536. The backing size may be increased to a larger value, but erase timing may suffer as a result.
|
||||
|
||||
## Wear-leveling RP2040 Driver Configuration :id=wear_leveling-rp2040-driver-configuration
|
||||
|
||||
This driver performs writes to the same underlying storage that the RP2040 executes its code.
|
||||
|
||||
Configurable options in your keyboard's `config.h`:
|
||||
|
||||
`config.h` override | Default | Description
|
||||
------------------------------------------|----------------------------|--------------------------------------------------------------------------------------------------------------------------------
|
||||
`#define WEAR_LEVELING_RP2040_FLASH_SIZE` | `PICO_FLASH_SIZE_BYTES` | Number of bytes of flash on the board.
|
||||
`#define WEAR_LEVELING_RP2040_FLASH_BASE` | `(flash_size-sector_size)` | The byte-wise location that the backing storage should be located.
|
||||
`#define WEAR_LEVELING_LOGICAL_SIZE` | `(backing_size/2)` | Number of bytes "exposed" to the rest of QMK and denotes the size of the usable EEPROM.
|
||||
`#define WEAR_LEVELING_BACKING_SIZE` | `8192` | Number of bytes used by the wear-leveling algorithm for its underlying storage, and needs to be a multiple of the logical size as well as the sector size.
|
||||
`#define BACKING_STORE_WRITE_SIZE` | `2` | The write width used whenever a write is performed on the external flash peripheral.
|
||||
|
||||
## Wear-leveling Legacy EEPROM Emulation Driver Configuration :id=wear_leveling-legacy-driver-configuration
|
||||
|
||||
This driver performs writes to the embedded flash storage embedded in the MCU much like the normal Embedded Flash Driver, and is only for use with STM32F0xx and STM32F4x1 devices. This flash implementation is still currently provided as the EFL driver is currently non-functional for the previously mentioned families.
|
||||
|
||||
By default, `1024` bytes of emulated EEPROM is provided:
|
||||
|
||||
MCU | EEPROM Provided | Flash Used
|
||||
----------|-----------------|--------------
|
||||
STM32F042 | `1024` bytes | `2048` bytes
|
||||
STM32F070 | `1024` bytes | `2048` bytes
|
||||
STM32F072 | `1024` bytes | `2048` bytes
|
||||
STM32F401 | `1024` bytes | `16384` bytes
|
||||
STM32F411 | `1024` bytes | `16384` bytes
|
||||
|
||||
Under normal circumstances configuration of this driver requires intimate knowledge of the MCU's flash structure -- reconfiguration is at your own risk and will require referring to the code.
|
@ -1,6 +1,6 @@
|
||||
# Frequently Asked Build Questions
|
||||
|
||||
This page covers questions about building QMK. If you haven't yet done so, you should read the [Build Environment Setup](getting_started_build_tools.md) and [Make Instructions](getting_started_make_guide.md) guides.
|
||||
This page covers questions about building QMK. If you haven't yet done so, you should read the [Build Environment Setup](newbs_getting_started) and [Make Instructions](getting_started_make_guide) guides.
|
||||
|
||||
## Can't Program on Linux
|
||||
You will need proper permissions to operate a device. For Linux users, see the instructions regarding `udev` rules, below. If you have issues with `udev`, a work-around is to use the `sudo` command. If you are not familiar with this command, check its manual with `man sudo` or [see this webpage](https://linux.die.net/man/8/sudo).
|
||||
@ -17,7 +17,7 @@ or just:
|
||||
|
||||
Note that running `make` with `sudo` is generally ***not*** a good idea, and you should use one of the former methods, if possible.
|
||||
|
||||
### Linux `udev` Rules :id=linux-udev-rules
|
||||
### Linux `udev` Rules {#linux-udev-rules}
|
||||
|
||||
On Linux, you'll need proper privileges to communicate with the bootloader device. You can either use `sudo` when flashing firmware (not recommended), or place [this file](https://github.com/qmk/qmk_firmware/tree/master/util/udev/50-qmk.rules) into `/etc/udev/rules.d/`.
|
||||
|
||||
@ -46,7 +46,7 @@ Issues encountered when flashing keyboards on Windows are most often due to havi
|
||||
|
||||
Re-running the QMK installation script (`./util/qmk_install.sh` from the `qmk_firmware` directory in MSYS2 or WSL) or reinstalling the QMK Toolbox may fix the issue. Alternatively, you can download and run the [`qmk_driver_installer`](https://github.com/qmk/qmk_driver_installer) package manually.
|
||||
|
||||
If that doesn't work, then you may need to download and run Zadig. See [Bootloader Driver Installation with Zadig](driver_installation_zadig.md) for more detailed information.
|
||||
If that doesn't work, then you may need to download and run Zadig. See [Bootloader Driver Installation with Zadig](driver_installation_zadig) for more detailed information.
|
||||
|
||||
## USB VID and PID
|
||||
You can use any ID you want with editing `config.h`. Using any presumably unused ID will be no problem in fact except for very low chance of collision with other product.
|
||||
@ -66,4 +66,4 @@ Due to how EEPROM works on ARM based chips, saved settings may no longer be vali
|
||||
[Planck rev6 reset EEPROM](https://cdn.discordapp.com/attachments/473506116718952450/539284620861243409/planck_rev6_default.bin) can be used to force an eeprom reset. After flashing this image, flash your normal firmware again which should restore your keyboard to _normal_ working order.
|
||||
[Preonic rev3 reset EEPROM](https://cdn.discordapp.com/attachments/473506116718952450/537849497313738762/preonic_rev3_default.bin)
|
||||
|
||||
If bootmagic is enabled in any form, you should be able to do this too (see [Bootmagic docs](feature_bootmagic.md) and keyboard info for specifics on how to do this).
|
||||
If bootmagic is enabled in any form, you should be able to do this too (see [Bootmagic docs](features/bootmagic) and keyboard info for specifics on how to do this).
|
||||
|
@ -2,9 +2,9 @@
|
||||
|
||||
This page details various common questions people have about troubleshooting their keyboards.
|
||||
|
||||
## Debugging :id=debugging
|
||||
## Debugging {#debugging}
|
||||
|
||||
Your keyboard will output debug information if you have `CONSOLE_ENABLE = yes` in your `rules.mk`. By default the output is very limited, but you can turn on debug mode to increase the amount of debug output. Use the `DB_TOGG` keycode in your keymap, use the [Command](feature_command.md) feature to enable debug mode, or add the following code to your keymap.
|
||||
Your keyboard will output debug information if you have `CONSOLE_ENABLE = yes` in your `rules.mk`. By default the output is very limited, but you can turn on debug mode to increase the amount of debug output. Use the `DB_TOGG` keycode in your keymap, use the [Command](features/command) feature to enable debug mode, or add the following code to your keymap.
|
||||
|
||||
```c
|
||||
void keyboard_post_init_user(void) {
|
||||
@ -26,15 +26,15 @@ For compatible platforms, [QMK Toolbox](https://github.com/qmk/qmk_toolbox) can
|
||||
|
||||
### Debugging with QMK CLI
|
||||
|
||||
Prefer a terminal based solution? The [QMK CLI console command](cli_commands.md#qmk-console) can be used to display debug messages from your keyboard.
|
||||
Prefer a terminal based solution? The [QMK CLI console command](cli_commands#qmk-console) can be used to display debug messages from your keyboard.
|
||||
|
||||
### Debugging With hid_listen
|
||||
|
||||
Something stand-alone? [hid_listen](https://www.pjrc.com/teensy/hid_listen.html), provided by PJRC, can also be used to display debug messages. Prebuilt binaries for Windows,Linux,and MacOS are available.
|
||||
|
||||
## Sending Your Own Debug Messages :id=debug-api
|
||||
## Sending Your Own Debug Messages {#debug-api}
|
||||
|
||||
Sometimes it's useful to print debug messages from within your [custom code](custom_quantum_functions.md). Doing so is pretty simple. Start by including `print.h` at the top of your file:
|
||||
Sometimes it's useful to print debug messages from within your [custom code](custom_quantum_functions). Doing so is pretty simple. Start by including `print.h` at the top of your file:
|
||||
|
||||
```c
|
||||
#include "print.h"
|
||||
@ -49,7 +49,7 @@ After that you can use a few different print functions:
|
||||
|
||||
## Debug Examples
|
||||
|
||||
Below is a collection of real world debugging examples. For additional information, refer to [Debugging/Troubleshooting QMK](faq_debug.md).
|
||||
Below is a collection of real world debugging examples. For additional information, refer to [Debugging/Troubleshooting QMK](faq_debug).
|
||||
|
||||
### Which matrix position is this keypress?
|
||||
|
||||
|
@ -6,13 +6,13 @@
|
||||
|
||||
## I don't know where to start!
|
||||
|
||||
If this is the case, then you should start with our [Newbs Guide](newbs.md). There is a lot of great info there, and that should cover everything you need to get started.
|
||||
If this is the case, then you should start with our [Newbs Guide](newbs). There is a lot of great info there, and that should cover everything you need to get started.
|
||||
|
||||
If that's an issue, hop onto the [QMK Configurator](https://config.qmk.fm), as that will handle a majority of what you need there.
|
||||
|
||||
## How can I flash the firmware I built?
|
||||
|
||||
First, head to the [Compiling/Flashing FAQ Page](faq_build.md). There is a good deal of info there, and you'll find a bunch of solutions to common issues there.
|
||||
First, head to the [Compiling/Flashing FAQ Page](faq_build). There is a good deal of info there, and you'll find a bunch of solutions to common issues there.
|
||||
|
||||
## What if I have an issue that isn't covered here?
|
||||
|
||||
@ -26,9 +26,9 @@ Then please open an [issue](https://github.com/qmk/qmk_firmware/issues/new), and
|
||||
|
||||
## But `git` and `GitHub` are intimidating!
|
||||
|
||||
Don't worry, we have some pretty nice [Guidelines](newbs_git_best_practices.md) on how to start using `git` and GitHub to make things easier to develop.
|
||||
Don't worry, we have some pretty nice [Guidelines](newbs_git_best_practices) on how to start using `git` and GitHub to make things easier to develop.
|
||||
|
||||
Additionally, you can find additional `git` and GitHub related links [here](newbs_learn_more_resources.md).
|
||||
Additionally, you can find additional `git` and GitHub related links [here](newbs_learn_more_resources).
|
||||
|
||||
## I have a Keyboard that I want to add support for
|
||||
|
||||
@ -46,7 +46,7 @@ If you have any questions about this, open an issue or head to [Discord](https:/
|
||||
|
||||
TMK was originally designed and implemented by [Jun Wako](https://github.com/tmk). QMK started as [Jack Humbert](https://github.com/jackhumbert)'s 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 [Keycodes](keycodes.md).
|
||||
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 [Keycodes](keycodes).
|
||||
|
||||
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 follow the quality standards. These are mostly community maintained, but the QMK team also helps when necessary.
|
||||
|
||||
|
@ -1,10 +1,10 @@
|
||||
# Keymap FAQ
|
||||
|
||||
This page covers questions people often have about keymaps. If you haven't you should read [Keymap Overview](keymap.md) first.
|
||||
This page covers questions people often have about keymaps. If you haven't you should read [Keymap Overview](keymap) first.
|
||||
|
||||
## What Keycodes Can I Use?
|
||||
|
||||
See [Keycodes](keycodes.md) for an index of keycodes available to you. These link to more extensive documentation when available.
|
||||
See [Keycodes](keycodes) for an index of keycodes available to you. These link to more extensive documentation when available.
|
||||
|
||||
Keycodes are actually defined in [quantum/keycode.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/keycode.h).
|
||||
|
||||
@ -44,8 +44,8 @@ QMK has a couple of features which allow you to change the behavior of your keyb
|
||||
|
||||
Refer to the EEPROM clearing methods above, which should return those keys to normal operation. If that doesn't work, look here:
|
||||
|
||||
* [Magic Keycodes](keycodes_magic.md)
|
||||
* [Command](feature_command.md)
|
||||
* [Magic Keycodes](keycodes_magic)
|
||||
* [Command](features/command)
|
||||
|
||||
## The Menu Key Isn't Working
|
||||
|
||||
@ -86,7 +86,7 @@ Old vintage mechanical keyboards occasionally have lock switches but modern ones
|
||||
|
||||
## Input Special Characters Other Than ASCII like Cédille 'Ç'
|
||||
|
||||
See the [Unicode](feature_unicode.md) feature.
|
||||
See the [Unicode](features/unicode) feature.
|
||||
|
||||
## `Fn` Key on macOS
|
||||
|
||||
@ -130,7 +130,7 @@ https://github.com/tekezo/Karabiner/issues/403
|
||||
|
||||
## Esc and <code>`</code> on a Single Key
|
||||
|
||||
See the [Grave Escape](feature_grave_esc.md) feature.
|
||||
See the [Grave Escape](features/grave_esc) feature.
|
||||
|
||||
## Eject on Mac OSX
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Miscellaneous FAQ
|
||||
|
||||
## How do I test my keyboard? :id=testing
|
||||
## How do I test my keyboard? {#testing}
|
||||
|
||||
Testing your keyboard is usually pretty straightforward. Press every single key and make sure it sends the keys you expect. You can use [QMK Configurator](https://config.qmk.fm/#/test/)'s test mode to check your keyboard, even if it doesn't run QMK.
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Modifier Keys :id=modifier-keys
|
||||
# Modifier Keys {#modifier-keys}
|
||||
|
||||
These allow you to combine a modifier with a keycode. When pressed, the keydown event for the modifier, then `kc` will be sent. On release, the keyup event for `kc`, then the modifier will be sent.
|
||||
|
||||
@ -26,7 +26,7 @@ These allow you to combine a modifier with a keycode. When pressed, the keydown
|
||||
|
||||
You can also chain them, for example `LCTL(LALT(KC_DEL))` or `C(A(KC_DEL))` makes a key that sends Control+Alt+Delete with a single keypress.
|
||||
|
||||
# Checking Modifier State :id=checking-modifier-state
|
||||
# Checking Modifier State {#checking-modifier-state}
|
||||
|
||||
The current modifier state can mainly be accessed with two functions: `get_mods()` for normal modifiers and modtaps and `get_oneshot_mods()` for one-shot modifiers (unless they're held, in which case they act like normal modifier keys).
|
||||
|
||||
@ -35,7 +35,7 @@ The presence of one or more specific modifiers in the current modifier state can
|
||||
Thus, to give an example, `01000010` would be the internal representation of LShift+RAlt.
|
||||
For more information on bitwise operators in C, click [here](https://en.wikipedia.org/wiki/Bitwise_operations_in_C) to open the Wikipedia page on the topic.
|
||||
|
||||
In practice, this means that you can check whether a given modifier is active with `get_mods() & MOD_BIT(KC_<modifier>)` (see the [list of modifier keycodes](keycodes_basic.md#modifiers)) or with `get_mods() & MOD_MASK_<modifier>` if the difference between left and right hand modifiers is not important and you want to match both. Same thing can be done for one-shot modifiers if you replace `get_mods()` with `get_oneshot_mods()`.
|
||||
In practice, this means that you can check whether a given modifier is active with `get_mods() & MOD_BIT(KC_<modifier>)` (see the [list of modifier keycodes](keycodes_basic#modifiers)) or with `get_mods() & MOD_MASK_<modifier>` if the difference between left and right hand modifiers is not important and you want to match both. Same thing can be done for one-shot modifiers if you replace `get_mods()` with `get_oneshot_mods()`.
|
||||
|
||||
To check that *only* a specific set of mods is active at a time, use a simple equality operator: `get_mods() == <mod mask>`.
|
||||
|
||||
@ -77,11 +77,11 @@ Similarly, in addition to `get_oneshot_mods()`, there also exists these function
|
||||
* `set_oneshot_mods(mods)`: Overwrite current one-shot modifier state with `mods`
|
||||
* `clear_oneshot_mods()`: Reset the one-shot modifier state by disabling all one-shot modifiers
|
||||
|
||||
## Examples :id=examples
|
||||
## Examples {#examples}
|
||||
|
||||
The following examples use [advanced macro functions](feature_macros.md#advanced-macro-functions) which you can read more about in the [documentation page on macros](feature_macros.md).
|
||||
The following examples use [advanced macro functions](feature_macros#advanced-macro-functions) which you can read more about in the [documentation page on macros](feature_macros).
|
||||
|
||||
### Alt + Escape for Alt + Tab :id=alt-escape-for-alt-tab
|
||||
### Alt + Escape for Alt + Tab {#alt-escape-for-alt-tab}
|
||||
|
||||
Simple example where chording Left Alt with `KC_ESC` makes it behave like `KC_TAB` for alt-tabbing between applications. This example strictly checks if only Left Alt is active, meaning you can't do Alt+Shift+Esc to switch between applications in reverse order. Also keep in mind that this removes the ability to trigger the actual Alt+Escape keyboard shortcut, though it keeps the ability to do AltGr+Escape.
|
||||
|
||||
@ -110,7 +110,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
|
||||
};
|
||||
```
|
||||
|
||||
### Shift + Backspace for Delete :id=shift-backspace-for-delete
|
||||
### Shift + Backspace for Delete {#shift-backspace-for-delete}
|
||||
|
||||
Advanced example where the original behaviour of shift is cancelled when chorded with `KC_BSPC` and is instead fully replaced by `KC_DEL`. Two main variables are created to make this work well: `mod_state` and `delkey_registered`. The first one stores the modifier state and is used to restore it after registering `KC_DEL`. The second variable is a boolean variable (true or false) which keeps track of the status of `KC_DEL` to manage the release of the whole Backspace/Delete key correctly.
|
||||
|
||||
@ -160,28 +160,28 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
|
||||
return true;
|
||||
};
|
||||
```
|
||||
Alternatively, this can be done with [Key Overrides](feature_key_overrides?id=simple-example).
|
||||
Alternatively, this can be done with [Key Overrides](features/key_overrides#simple-example).
|
||||
|
||||
# Advanced topics :id=advanced-topics
|
||||
# Advanced topics {#advanced-topics}
|
||||
|
||||
This page used to encompass a large set of features. We have moved many sections that used to be part of this page to their own pages. Everything below this point is simply a redirect so that people following old links on the web find what they're looking for.
|
||||
|
||||
## Layers :id=switching-and-toggling-layers
|
||||
## Layers {#switching-and-toggling-layers}
|
||||
|
||||
* [Layers](feature_layers.md)
|
||||
* [Layers](feature_layers)
|
||||
|
||||
## Mod-Tap :id=mod-tap
|
||||
## Mod-Tap {#mod-tap}
|
||||
|
||||
* [Mod-Tap](mod_tap.md)
|
||||
* [Mod-Tap](mod_tap)
|
||||
|
||||
## One Shot Keys :id=one-shot-keys
|
||||
## One Shot Keys {#one-shot-keys}
|
||||
|
||||
* [One Shot Keys](one_shot_keys.md)
|
||||
* [One Shot Keys](one_shot_keys)
|
||||
|
||||
## Tap-Hold Configuration Options :id=tap-hold-configuration-options
|
||||
## Tap-Hold Configuration Options {#tap-hold-configuration-options}
|
||||
|
||||
* [Tap-Hold Configuration Options](tap_hold.md)
|
||||
* [Tap-Hold Configuration Options](tap_hold)
|
||||
|
||||
## Key Overrides :id=key-overrides
|
||||
## Key Overrides {#key-overrides}
|
||||
|
||||
* [Key Overrides](feature_key_overrides.md)
|
||||
* [Key Overrides](features/key_overrides)
|
||||
|
@ -1,367 +0,0 @@
|
||||
# Audio
|
||||
|
||||
Your keyboard can make sounds! If you've got a spare pin you can hook up a simple speaker and make it beep. You can use those beeps to indicate layer transitions, modifiers, special keys, or just to play some funky 8bit tunes.
|
||||
|
||||
To activate this feature, add `AUDIO_ENABLE = yes` to your `rules.mk`.
|
||||
|
||||
## AVR based boards
|
||||
On Atmega32U4 based boards, up to two simultaneous tones can be rendered.
|
||||
With one speaker connected to a PWM capable pin on PORTC driven by timer 3 and the other on one of the PWM pins on PORTB driven by timer 1.
|
||||
|
||||
The following pins can be configured as audio outputs in `config.h` - for one speaker set either one out of:
|
||||
|
||||
* `#define AUDIO_PIN C4`
|
||||
* `#define AUDIO_PIN C5`
|
||||
* `#define AUDIO_PIN C6`
|
||||
* `#define AUDIO_PIN B5`
|
||||
* `#define AUDIO_PIN B6`
|
||||
* `#define AUDIO_PIN B7`
|
||||
|
||||
and *optionally*, for a second speaker, one of:
|
||||
* `#define AUDIO_PIN_ALT B5`
|
||||
* `#define AUDIO_PIN_ALT B6`
|
||||
* `#define AUDIO_PIN_ALT B7`
|
||||
|
||||
### Wiring
|
||||
per speaker is - for example with a piezo buzzer - the black lead to Ground, and the red lead connected to the selected AUDIO_PIN for the primary; and similarly with AUDIO_PIN_ALT for the secondary.
|
||||
|
||||
|
||||
## ARM based boards
|
||||
for more technical details, see the notes on [Audio driver](audio_driver.md).
|
||||
|
||||
<!-- because I'm not sure where to fit this in: https://waveeditonline.com/ -->
|
||||
### DAC (basic)
|
||||
Most STM32 MCUs have DAC peripherals, with a notable exception of the STM32F1xx series. Generally, the DAC peripheral drives pins A4 or A5. To enable DAC-based audio output on STM32 devices, add `AUDIO_DRIVER = dac_basic` to `rules.mk` and set in `config.h` either:
|
||||
|
||||
`#define AUDIO_PIN A4` or `#define AUDIO_PIN A5`
|
||||
|
||||
the other DAC channel can optionally be used with a secondary speaker, just set:
|
||||
|
||||
`#define AUDIO_PIN_ALT A4` or `#define AUDIO_PIN_ALT A5`
|
||||
|
||||
Do note though that the dac_basic driver is only capable of reproducing one tone per speaker/channel at a time, for more tones simultaneously, try the dac_additive driver.
|
||||
|
||||
#### Wiring:
|
||||
for two piezos, for example configured as `AUDIO_PIN A4` and `AUDIO_PIN_ALT A5` would be: red lead to A4 and black to Ground, and similarly with the second one: A5 = red, and Ground = black
|
||||
|
||||
another alternative is to drive *one* piezo with both DAC pins - for an extra "push".
|
||||
wiring red to A4 and black to A5 (or the other way round) and add `#define AUDIO_PIN_ALT_AS_NEGATIVE` to `config.h`
|
||||
|
||||
##### Proton-C Example:
|
||||
The Proton-C comes (optionally) with one 'builtin' piezo, which is wired to A4+A5.
|
||||
For this board `config.h` would include these defines:
|
||||
|
||||
```c
|
||||
#define AUDIO_PIN A5
|
||||
#define AUDIO_PIN_ALT A4
|
||||
#define AUDIO_PIN_ALT_AS_NEGATIVE
|
||||
```
|
||||
|
||||
### DAC (additive)
|
||||
Another option, besides dac_basic (which produces sound through a square-wave), is to use the DAC to do additive wave synthesis.
|
||||
With a number of predefined wave-forms or by providing your own implementation to generate samples on the fly.
|
||||
To use this feature set `AUDIO_DRIVER = dac_additive` in your `rules.mk`, and select in `config.h` EITHER `#define AUDIO_PIN A4` or `#define AUDIO_PIN A5`.
|
||||
|
||||
The used waveform *defaults* to sine, but others can be selected by adding one of the following defines to `config.h`:
|
||||
|
||||
* `#define AUDIO_DAC_SAMPLE_WAVEFORM_SINE`
|
||||
* `#define AUDIO_DAC_SAMPLE_WAVEFORM_TRIANGLE`
|
||||
* `#define AUDIO_DAC_SAMPLE_WAVEFORM_TRAPEZOID`
|
||||
* `#define AUDIO_DAC_SAMPLE_WAVEFORM_SQUARE`
|
||||
|
||||
Should you rather choose to generate and use your own sample-table with the DAC unit, implement `uint16_t dac_value_generate(void)` with your keyboard - for an example implementation see keyboards/planck/keymaps/synth_sample or keyboards/planck/keymaps/synth_wavetable
|
||||
|
||||
|
||||
### PWM (software)
|
||||
if the DAC pins are unavailable (or the MCU has no usable DAC at all, like STM32F1xx); PWM can be an alternative.
|
||||
Note that there is currently only one speaker/pin supported.
|
||||
|
||||
set in `rules.mk`:
|
||||
|
||||
`AUDIO_DRIVER = pwm_software` and in `config.h`:
|
||||
`#define AUDIO_PIN C13` (can be any pin) to have the selected pin output a pwm signal, generated from a timer callback which toggles the pin in software.
|
||||
|
||||
#### Wiring
|
||||
the usual piezo wiring: red goes to the selected AUDIO_PIN, black goes to ground.
|
||||
|
||||
OR if you can chose to drive one piezo with two pins, for example `#define AUDIO_PIN B1`, `#define AUDIO_PIN_ALT B2` in `config.h`, with `#define AUDIO_PIN_ALT_AS_NEGATIVE` - then the red lead could go to B1, the black to B2.
|
||||
|
||||
### PWM (hardware)
|
||||
STM32F1xx have to fall back to using PWM, but can do so in hardware; but again on currently only one speaker/pin.
|
||||
|
||||
`AUDIO_DRIVER = pwm_hardware` in `rules.mk`, and in `config.h`:
|
||||
`#define AUDIO_PIN A8`
|
||||
`#define AUDIO_PWM_DRIVER PWMD1`
|
||||
`#define AUDIO_PWM_CHANNEL 1`
|
||||
(as well as `#define AUDIO_PWM_PAL_MODE 42` if you are on STM32F2 or larger)
|
||||
which will use Timer 1 to directly drive pin PA8 through the PWM hardware (TIM1_CH1 = PA8).
|
||||
Should you want to use the pwm-hardware on another pin and timer - be ready to dig into the STM32 data-sheet to pick the right TIMx_CHy and pin-alternate function.
|
||||
|
||||
|
||||
## Tone Multiplexing
|
||||
Since most drivers can only render one tone per speaker at a time (with the one exception: arm dac-additive) there also exists a "workaround-feature" that does time-slicing/multiplexing - which does what the name implies: cycle through a set of active tones (e.g. when playing chords in Music Mode) at a given rate, and put one tone at a time out through the one/few speakers that are available.
|
||||
|
||||
To enable this feature, and configure a starting-rate, add the following defines to `config.h`:
|
||||
```c
|
||||
#define AUDIO_ENABLE_TONE_MULTIPLEXING
|
||||
#define AUDIO_TONE_MULTIPLEXING_RATE_DEFAULT 10
|
||||
```
|
||||
|
||||
The audio core offers interface functions to get/set/change the tone multiplexing rate from within `keymap.c`.
|
||||
|
||||
|
||||
## Songs
|
||||
There's a couple of different sounds that will automatically be enabled without any other configuration:
|
||||
```
|
||||
STARTUP_SONG // plays when the keyboard starts up (audio.c)
|
||||
GOODBYE_SONG // plays when you press the QK_BOOT key (quantum.c)
|
||||
AG_NORM_SONG // plays when you press AG_NORM (quantum.c)
|
||||
AG_SWAP_SONG // plays when you press AG_SWAP (quantum.c)
|
||||
CG_NORM_SONG // plays when you press CG_NORM (quantum.c)
|
||||
CG_SWAP_SONG // plays when you press CG_SWAP (quantum.c)
|
||||
MUSIC_ON_SONG // plays when music mode is activated (process_music.c)
|
||||
MUSIC_OFF_SONG // plays when music mode is deactivated (process_music.c)
|
||||
CHROMATIC_SONG // plays when the chromatic music mode is selected (process_music.c)
|
||||
GUITAR_SONG // plays when the guitar music mode is selected (process_music.c)
|
||||
VIOLIN_SONG // plays when the violin music mode is selected (process_music.c)
|
||||
MAJOR_SONG // plays when the major music mode is selected (process_music.c)
|
||||
```
|
||||
|
||||
You can override the default songs by doing something like this in your `config.h`:
|
||||
|
||||
```c
|
||||
#ifdef AUDIO_ENABLE
|
||||
# define STARTUP_SONG SONG(STARTUP_SOUND)
|
||||
#endif
|
||||
```
|
||||
|
||||
A full list of sounds can be found in [quantum/audio/song_list.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/song_list.h) - feel free to add your own to this list! All available notes can be seen in [quantum/audio/musical_notes.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/musical_notes.h).
|
||||
|
||||
Additionally, if you with to maintain your own list of songs (such as ones that may be copyrighted) and not have them added to the repo, you can create a `user_song_list.h` file and place it in your keymap (or userspace) folder. This file will be automatically included, it just needs to exist.
|
||||
|
||||
To play a custom sound at a particular time, you can define a song like this (near the top of the file):
|
||||
|
||||
```c
|
||||
float my_song[][2] = SONG(QWERTY_SOUND);
|
||||
```
|
||||
|
||||
And then play your song like this:
|
||||
|
||||
```c
|
||||
PLAY_SONG(my_song);
|
||||
```
|
||||
|
||||
Alternatively, you can play it in a loop like this:
|
||||
|
||||
```c
|
||||
PLAY_LOOP(my_song);
|
||||
```
|
||||
|
||||
It's advised that you wrap all audio features in `#ifdef AUDIO_ENABLE` / `#endif` to avoid causing problems when audio isn't built into the keyboard.
|
||||
|
||||
The available keycodes for audio are:
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|-------------------------|---------|-------------------------------------------|
|
||||
|`QK_AUDIO_ON` |`AU_ON` |Turns on Audio Feature |
|
||||
|`QK_AUDIO_OFF` |`AU_OFF` |Turns off Audio Feature |
|
||||
|`QK_AUDIO_TOGGLE` |`AU_TOGG`|Toggles Audio state |
|
||||
|
||||
!> These keycodes turn all of the audio functionality on and off. Turning it off means that audio feedback, audio clicky, music mode, etc. are disabled, completely.
|
||||
|
||||
## Audio Config
|
||||
|
||||
| Settings | Default | Description |
|
||||
|---------------------------------|----------------------|-------------------------------------------------------------------------------|
|
||||
|`AUDIO_PIN` | *Not defined* |Configures the pin that the speaker is connected to. |
|
||||
|`AUDIO_PIN_ALT` | *Not defined* |Configures the pin for a second speaker or second pin connected to one speaker.|
|
||||
|`AUDIO_PIN_ALT_AS_NEGATIVE` | *Not defined* |Enables support for one speaker connected to two pins. |
|
||||
|`AUDIO_INIT_DELAY` | *Not defined* |Enables delay during startup song to accomidate for USB startup issues. |
|
||||
|`AUDIO_ENABLE_TONE_MULTIPLEXING` | *Not defined* |Enables time splicing/multiplexing to create multiple tones simutaneously. |
|
||||
|`STARTUP_SONG` | `STARTUP_SOUND` |Plays when the keyboard starts up (audio.c) |
|
||||
|`GOODBYE_SONG` | `GOODBYE_SOUND` |Plays when you press the QK_BOOT key (quantum.c) |
|
||||
|`AG_NORM_SONG` | `AG_NORM_SOUND` |Plays when you press AG_NORM (process_magic.c) |
|
||||
|`AG_SWAP_SONG` | `AG_SWAP_SOUND` |Plays when you press AG_SWAP (process_magic.c) |
|
||||
|`CG_NORM_SONG` | `AG_NORM_SOUND` |Plays when you press CG_NORM (process_magic.c) |
|
||||
|`CG_SWAP_SONG` | `AG_SWAP_SOUND` |Plays when you press CG_SWAP (process_magic.c) |
|
||||
|`MUSIC_ON_SONG` | `MUSIC_ON_SOUND` |Plays when music mode is activated (process_music.c) |
|
||||
|`MUSIC_OFF_SONG` | `MUSIC_OFF_SOUND` |Plays when music mode is deactivated (process_music.c) |
|
||||
|`MIDI_ON_SONG` | `MUSIC_ON_SOUND` |Plays when midi mode is activated (process_music.c) |
|
||||
|`MIDI_OFF_SONG` | `MUSIC_OFF_SOUND` |Plays when midi mode is deactivated (process_music.c) |
|
||||
|`CHROMATIC_SONG` | `CHROMATIC_SOUND` |Plays when the chromatic music mode is selected (process_music.c) |
|
||||
|`GUITAR_SONG` | `GUITAR_SOUND` |Plays when the guitar music mode is selected (process_music.c) |
|
||||
|`VIOLIN_SONG` | `VIOLIN_SOUND` |Plays when the violin music mode is selected (process_music.c) |
|
||||
|`MAJOR_SONG` | `MAJOR_SOUND` |Plays when the major music mode is selected (process_music.c) |
|
||||
|`DEFAULT_LAYER_SONGS` | *Not defined* |Plays song when switched default layers with [`set_single_persistent_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer)(quantum.c) |
|
||||
|`SENDSTRING_BELL` | *Not defined* |Plays chime when the "enter" ("\a") character is sent (send_string.c) |
|
||||
|
||||
## Tempo
|
||||
the 'speed' at which SONGs are played is dictated by the set Tempo, which is measured in beats-per-minute. Note lengths are defined relative to that.
|
||||
The initial/default tempo is set to 120 bpm, but can be configured by setting `TEMPO_DEFAULT` in `config.c`.
|
||||
There is also a set of functions to modify the tempo from within the user/keymap code:
|
||||
```c
|
||||
void audio_set_tempo(uint8_t tempo);
|
||||
void audio_increase_tempo(uint8_t tempo_change);
|
||||
void audio_decrease_tempo(uint8_t tempo_change);
|
||||
```
|
||||
|
||||
## ARM Audio Volume
|
||||
|
||||
For ARM devices, you can adjust the DAC sample values. If your board is too loud for you or your coworkers, you can set the max using `AUDIO_DAC_SAMPLE_MAX` in your `config.h`:
|
||||
|
||||
```c
|
||||
#define AUDIO_DAC_SAMPLE_MAX 4095U
|
||||
```
|
||||
the DAC usually runs in 12Bit mode, hence a volume of 100% = 4095U
|
||||
|
||||
Note: this only adjusts the volume aka 'works' if you stick to WAVEFORM_SQUARE, since its samples are generated on the fly - any other waveform uses a hardcoded/precomputed sample-buffer.
|
||||
|
||||
## Voices
|
||||
Aka "audio effects", different ones can be enabled by setting in `config.h` these defines:
|
||||
`#define AUDIO_VOICES` to enable the feature, and `#define AUDIO_VOICE_DEFAULT something` to select a specific effect
|
||||
for details see quantum/audio/voices.h and .c
|
||||
|
||||
Keycodes available:
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|-------------------------|---------|-------------------------------------------|
|
||||
|`QK_AUDIO_VOICE_NEXT` |`AU_NEXT`|Cycles through the audio voices |
|
||||
|`QK_AUDIO_VOICE_PREVIOUS`|`AU_PREV`|Cycles through the audio voices in reverse |
|
||||
|
||||
## Music Mode
|
||||
|
||||
The music mode maps your columns to a chromatic scale, and your rows to octaves. This works best with ortholinear keyboards, but can be made to work with others. All keycodes less than `0xFF` get blocked, so you won't type while playing notes - if you have special keys/mods, those will still work. A work-around for this is to jump to a different layer with KC_NOs before (or after) enabling music mode.
|
||||
|
||||
Recording is experimental due to some memory issues - if you experience some weird behavior, unplugging/replugging your keyboard will fix things.
|
||||
|
||||
Keycodes available:
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|-------------------------|---------|-------------------------------------------|
|
||||
|`QK_MUSIC_ON` |`MU_ON` |Turns on Music Mode |
|
||||
|`QK_MUSIC_OFF` |`MU_OFF` |Turns off Music Mode |
|
||||
|`QK_MUSIC_TOGGLE` |`MU_TOGG`|Toggles Music Mode |
|
||||
|`QK_MUSIC_MODE_NEXT` |`MU_NEXT`|Cycles through the music modes |
|
||||
|
||||
Available Modes:
|
||||
* `CHROMATIC_MODE` - Chromatic scale, row changes the octave
|
||||
* `GUITAR_MODE` - Chromatic scale, but the row changes the string (+5 st)
|
||||
* `VIOLIN_MODE` - Chromatic scale, but the row changes the string (+7 st)
|
||||
* `MAJOR_MODE` - Major scale
|
||||
|
||||
In music mode, the following keycodes work differently, and don't pass through:
|
||||
|
||||
* `LCTL` - start a recording
|
||||
* `LALT` - stop recording/stop playing
|
||||
* `LGUI` - play recording
|
||||
* `KC_UP` - speed-up playback
|
||||
* `KC_DOWN` - slow-down playback
|
||||
|
||||
The pitch standard (`PITCH_STANDARD_A`) is 440.0f by default - to change this, add something like this to your `config.h`:
|
||||
|
||||
#define PITCH_STANDARD_A 432.0f
|
||||
|
||||
You can completely disable Music Mode as well. This is useful, if you're pressed for space on your controller. To disable it, add this to your `config.h`:
|
||||
|
||||
#define NO_MUSIC_MODE
|
||||
|
||||
### Music Mask
|
||||
|
||||
By default, `MUSIC_MASK` is set to `keycode < 0xFF` which means keycodes less than `0xFF` are turned into notes, and don't output anything. You can change this by defining this in your `config.h` like this:
|
||||
|
||||
#define MUSIC_MASK keycode != KC_NO
|
||||
|
||||
Which will capture all keycodes - be careful, this will get you stuck in music mode until you restart your keyboard!
|
||||
|
||||
For a more advanced way to control which keycodes should still be processed, you can use `music_mask_kb(keycode)` in `<keyboard>.c` and `music_mask_user(keycode)` in your `keymap.c`:
|
||||
|
||||
bool music_mask_user(uint16_t keycode) {
|
||||
switch (keycode) {
|
||||
case RAISE:
|
||||
case LOWER:
|
||||
return false;
|
||||
default:
|
||||
return true;
|
||||
}
|
||||
}
|
||||
|
||||
Things that return false are not part of the mask, and are always processed.
|
||||
|
||||
### Music Map
|
||||
|
||||
By default, the Music Mode uses the columns and row to determine the scale for the keys. For a board that uses a rectangular matrix that matches the keyboard layout, this is just fine. However, for boards that use a more complicated matrix (such as the Planck Rev6, or many split keyboards) this would result in a very skewed experience.
|
||||
|
||||
However, the Music Map option allows you to remap the scaling for the music mode, so it fits the layout, and is more natural.
|
||||
|
||||
To enable this feature, add `#define MUSIC_MAP` to your `config.h` file, and then you will want to add a `uint8_t music_map` to your keyboard's `c` file, or your `keymap.c`.
|
||||
|
||||
```c
|
||||
const uint8_t music_map[MATRIX_ROWS][MATRIX_COLS] = LAYOUT_ortho_4x12(
|
||||
36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
|
||||
24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35,
|
||||
12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23,
|
||||
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
|
||||
);
|
||||
```
|
||||
|
||||
You will want to use whichever `LAYOUT` macro that your keyboard uses here. This maps it to the correct key location. Start in the bottom left of the keyboard layout, and move to the right, and then upwards. Fill in all the entries until you have a complete matrix.
|
||||
|
||||
You can look at the [Planck Keyboard](https://github.com/qmk/qmk_firmware/blob/e9ace1487887c1f8b4a7e8e6d87c322988bec9ce/keyboards/planck/planck.c#L24-L29) as an example of how to implement this.
|
||||
|
||||
## Audio Click
|
||||
|
||||
This adds a click sound each time you hit a button, to simulate click sounds from the keyboard. And the sounds are slightly different for each keypress, so it doesn't sound like a single long note, if you type rapidly.
|
||||
|
||||
Keycodes available:
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|-------------------------|---------|-------------------------------------------|
|
||||
|`QK_AUDIO_CLICKY_TOGGLE` |`CK_TOGG`|Toggles Audio clicky mode |
|
||||
|`QK_AUDIO_CLICKY_ON` |`CK_ON` |Turns on Audio clicky mode |
|
||||
|`QK_AUDIO_CLICKY_OFF` |`CK_OFF` |Turns on Audio clicky mode |
|
||||
|`QK_AUDIO_CLICKY_UP` |`CK_UP` |Increases frequency of the clicks |
|
||||
|`QK_AUDIO_CLICKY_DOWN` |`CK_DOWN`|Decreases frequency of the clicks |
|
||||
|`QK_AUDIO_CLICKY_RESET` |`CK_RST` |Resets frequency to default |
|
||||
|
||||
The feature is disabled by default, to save space. To enable it, add this to your `config.h`:
|
||||
|
||||
#define AUDIO_CLICKY
|
||||
|
||||
|
||||
You can configure the default, min and max frequencies, the stepping and built in randomness by defining these values:
|
||||
|
||||
| Option | Default Value | Description |
|
||||
|--------|---------------|-------------|
|
||||
| `AUDIO_CLICKY_FREQ_DEFAULT` | 440.0f | Sets the default/starting audio frequency for the clicky sounds. |
|
||||
| `AUDIO_CLICKY_FREQ_MIN` | 65.0f | Sets the lowest frequency (under 60f are a bit buggy). |
|
||||
| `AUDIO_CLICKY_FREQ_MAX` | 1500.0f | Sets the highest frequency. Too high may result in coworkers attacking you. |
|
||||
| `AUDIO_CLICKY_FREQ_FACTOR` | 1.18921f| Sets the stepping of UP/DOWN key codes. This is a multiplicative factor. The default steps the frequency up/down by a musical minor third. |
|
||||
| `AUDIO_CLICKY_FREQ_RANDOMNESS` | 0.05f | Sets a factor of randomness for the clicks, Setting this to `0f` will make each click identical, and `1.0f` will make this sound much like the 90's computer screen scrolling/typing effect. |
|
||||
| `AUDIO_CLICKY_DELAY_DURATION` | 1 | An integer note duration where 1 is 1/16th of the tempo, or a sixty-fourth note (see `quantum/audio/musical_notes.h` for implementation details). The main clicky effect will be delayed by this duration. Adjusting this to values around 6-12 will help compensate for loud switches. |
|
||||
|
||||
|
||||
|
||||
|
||||
## MIDI Functionality
|
||||
|
||||
See [MIDI](feature_midi.md)
|
||||
|
||||
## Audio Keycodes
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|-------------------------|---------|-------------------------------------------|
|
||||
|`QK_AUDIO_ON` |`AU_ON` |Turns on Audio Feature |
|
||||
|`QK_AUDIO_OFF` |`AU_OFF` |Turns off Audio Feature |
|
||||
|`QK_AUDIO_TOGGLE` |`AU_TOGG`|Toggles Audio state |
|
||||
|`QK_AUDIO_CLICKY_TOGGLE` |`CK_TOGG`|Toggles Audio clicky mode |
|
||||
|`QK_AUDIO_CLICKY_ON` |`CK_ON` |Turns on Audio clicky mode |
|
||||
|`QK_AUDIO_CLICKY_OFF` |`CK_OFF` |Turns on Audio clicky mode |
|
||||
|`QK_AUDIO_CLICKY_UP` |`CK_UP` |Increases frequency of the clicks |
|
||||
|`QK_AUDIO_CLICKY_DOWN` |`CK_DOWN`|Decreases frequency of the clicks |
|
||||
|`QK_AUDIO_CLICKY_RESET` |`CK_RST` |Resets frequency to default |
|
||||
|`QK_MUSIC_ON` |`MU_ON` |Turns on Music Mode |
|
||||
|`QK_MUSIC_OFF` |`MU_OFF` |Turns off Music Mode |
|
||||
|`QK_MUSIC_TOGGLE` |`MU_TOGG`|Toggles Music Mode |
|
||||
|`QK_MUSIC_MODE_NEXT` |`MU_NEXT`|Cycles through the music modes |
|
||||
|`QK_AUDIO_VOICE_NEXT` |`AU_NEXT`|Cycles through the audio voices |
|
||||
|`QK_AUDIO_VOICE_PREVIOUS`|`AU_PREV`|Cycles through the audio voices in reverse |
|
@ -1,392 +0,0 @@
|
||||
# Auto Shift: Why Do We Need a Shift Key?
|
||||
|
||||
Tap a key and you get its character. Tap a key, but hold it *slightly* longer
|
||||
and you get its shifted state. Voilà! No shift key needed!
|
||||
|
||||
## Why Auto Shift?
|
||||
|
||||
Many people suffer from various forms of RSI. A common cause is stretching your
|
||||
fingers repetitively long distances. For us on the keyboard, the pinky does that
|
||||
all too often when reaching for the shift key. Auto Shift looks to alleviate that
|
||||
problem.
|
||||
|
||||
## How Does It Work?
|
||||
|
||||
When you tap a key, it stays depressed for a short period of time before it is
|
||||
then released. This depressed time is a different length for everyone. Auto Shift
|
||||
defines a constant `AUTO_SHIFT_TIMEOUT` which is typically set to twice your
|
||||
normal pressed state time. When you press a key, a timer starts, and if you
|
||||
have not released the key after the `AUTO_SHIFT_TIMEOUT` period, then a shifted
|
||||
version of the key is emitted. If the time is less than the `AUTO_SHIFT_TIMEOUT`
|
||||
time, or you press another key, then the normal state is emitted.
|
||||
|
||||
If `AUTO_SHIFT_REPEAT` is defined, there is keyrepeat support. Holding the key
|
||||
down will repeat the shifted key, though this can be disabled with
|
||||
`AUTO_SHIFT_NO_AUTO_REPEAT`. If you want to repeat the normal key, then tap it
|
||||
once then immediately (within `TAPPING_TERM`) hold it down again (this works
|
||||
with the shifted value as well if auto-repeat is disabled).
|
||||
|
||||
There are also the `get_auto_shift_repeat` and `get_auto_shift_no_auto_repeat`
|
||||
functions for more granular control. Neither will have an effect unless
|
||||
`AUTO_SHIFT_REPEAT_PER_KEY` or `AUTO_SHIFT_NO_AUTO_REPEAT_PER_KEY` respectively
|
||||
are defined.
|
||||
|
||||
## Are There Limitations to Auto Shift?
|
||||
|
||||
Yes, unfortunately.
|
||||
|
||||
1. You will have characters that are shifted when you did not intend on shifting, and
|
||||
other characters you wanted shifted, but were not. This simply comes down to
|
||||
practice. As we get in a hurry, we think we have hit the key long enough for a
|
||||
shifted version, but we did not. On the other hand, we may think we are tapping
|
||||
the keys, but really we have held it for a little longer than anticipated.
|
||||
2. Additionally, with keyrepeat the desired shift state can get mixed up. It will
|
||||
always 'belong' to the last key pressed. For example, keyrepeating a capital
|
||||
and then tapping something lowercase (whether or not it's an Auto Shift key)
|
||||
will result in the capital's *key* still being held, but shift not.
|
||||
3. Auto Shift does not apply to Tap Hold keys. For automatic shifting of Tap Hold
|
||||
keys see [Retro Shift](#retro-shift).
|
||||
|
||||
## How Do I Enable Auto Shift?
|
||||
|
||||
Add to your `rules.mk` in the keymap folder:
|
||||
|
||||
AUTO_SHIFT_ENABLE = yes
|
||||
|
||||
If no `rules.mk` exists, you can create one.
|
||||
|
||||
Then compile and install your new firmware with Auto Key enabled! That's it!
|
||||
|
||||
## Modifiers
|
||||
|
||||
By default, Auto Shift is disabled for any key press that is accompanied by one or more
|
||||
modifiers. Thus, Ctrl+A that you hold for a really long time is not the same
|
||||
as Ctrl+Shift+A.
|
||||
|
||||
You can re-enable Auto Shift for modifiers by adding a define to your `config.h`
|
||||
|
||||
```c
|
||||
#define AUTO_SHIFT_MODIFIERS
|
||||
```
|
||||
|
||||
In which case, Ctrl+A held past the `AUTO_SHIFT_TIMEOUT` will be sent as Ctrl+Shift+A
|
||||
|
||||
|
||||
## Configuring Auto Shift
|
||||
|
||||
If desired, there is some configuration that can be done to change the
|
||||
behavior of Auto Shift. This is done by setting various variables the
|
||||
`config.h` file located in your keymap folder. If no `config.h` file exists, you can create one.
|
||||
|
||||
A sample is
|
||||
|
||||
```c
|
||||
#pragma once
|
||||
|
||||
#define AUTO_SHIFT_TIMEOUT 150
|
||||
#define NO_AUTO_SHIFT_SPECIAL
|
||||
```
|
||||
|
||||
### AUTO_SHIFT_TIMEOUT (Value in ms)
|
||||
|
||||
This controls how long you have to hold a key before you get the shifted state.
|
||||
Obviously, this is different for everyone. For the common person, a setting of
|
||||
135 to 150 works great. However, one should start with a value of at least 175, which
|
||||
is the default value. Then work down from there. The idea is to have the shortest time required to get the shifted state without having false positives.
|
||||
|
||||
Play with this value until things are perfect. Many find that all will work well
|
||||
at a given value, but one or two keys will still emit the shifted state on
|
||||
occasion. This is simply due to habit and holding some keys a little longer
|
||||
than others. Once you find this value, work on tapping your problem keys a little
|
||||
quicker than normal and you will be set.
|
||||
|
||||
?> Auto Shift has three special keys that can help you get this value right very quick. See "Auto Shift Setup" for more details!
|
||||
|
||||
For more granular control of this feature, you can add the following to your `config.h`:
|
||||
|
||||
```c
|
||||
#define AUTO_SHIFT_TIMEOUT_PER_KEY
|
||||
```
|
||||
|
||||
You can then add the following function to your keymap:
|
||||
|
||||
```c
|
||||
uint16_t get_autoshift_timeout(uint16_t keycode, keyrecord_t *record) {
|
||||
switch(keycode) {
|
||||
case AUTO_SHIFT_NUMERIC:
|
||||
return 2 * get_generic_autoshift_timeout();
|
||||
case AUTO_SHIFT_SPECIAL:
|
||||
return get_generic_autoshift_timeout() + 50;
|
||||
case AUTO_SHIFT_ALPHA:
|
||||
default:
|
||||
return get_generic_autoshift_timeout();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Note that you cannot override individual keys that are in one of those groups
|
||||
if you are using them; trying to add a case for `KC_A` in the above example will
|
||||
not compile as `AUTO_SHIFT_ALPHA` is there. A possible solution is a second switch
|
||||
above to handle individual keys with no default case and only referencing the
|
||||
groups in the below fallback switch.
|
||||
|
||||
### NO_AUTO_SHIFT_SPECIAL (simple define)
|
||||
|
||||
Do not Auto Shift special keys, which include -\_, =+, [{, ]}, ;:, '", ,<, .>,
|
||||
/?, and the KC_TAB.
|
||||
|
||||
### NO_AUTO_SHIFT_TAB (simple define)
|
||||
|
||||
Do not Auto Shift KC_TAB but leave Auto Shift enabled for the other special
|
||||
characters.
|
||||
|
||||
### NO_AUTO_SHIFT_SYMBOLS (simple define)
|
||||
|
||||
Do not Auto Shift symbol keys, which include -\_, =+, [{, ]}, ;:, '", ,<, .>,
|
||||
and /?.
|
||||
|
||||
### NO_AUTO_SHIFT_NUMERIC (simple define)
|
||||
|
||||
Do not Auto Shift numeric keys, zero through nine.
|
||||
|
||||
### NO_AUTO_SHIFT_ALPHA (simple define)
|
||||
|
||||
Do not Auto Shift alpha characters, which include A through Z.
|
||||
|
||||
### AUTO_SHIFT_ENTER (simple define)
|
||||
|
||||
Auto Shift the enter key.
|
||||
|
||||
### Auto Shift Per Key
|
||||
|
||||
There are functions that allows you to determine which keys should be autoshifted, much like the tap-hold keys.
|
||||
|
||||
The first of these, used to simply add a key to Auto Shift, is `get_custom_auto_shifted_key`:
|
||||
|
||||
```c
|
||||
bool get_custom_auto_shifted_key(uint16_t keycode, keyrecord_t *record) {
|
||||
switch(keycode) {
|
||||
case KC_DOT:
|
||||
return true;
|
||||
default:
|
||||
return false;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
For more granular control, there is `get_auto_shifted_key`. The default function looks like this:
|
||||
|
||||
```c
|
||||
bool get_auto_shifted_key(uint16_t keycode, keyrecord_t *record) {
|
||||
switch (keycode) {
|
||||
# ifndef NO_AUTO_SHIFT_ALPHA
|
||||
case AUTO_SHIFT_ALPHA:
|
||||
# endif
|
||||
# ifndef NO_AUTO_SHIFT_NUMERIC
|
||||
case AUTO_SHIFT_NUMERIC:
|
||||
# endif
|
||||
# ifndef NO_AUTO_SHIFT_SPECIAL
|
||||
# ifndef NO_AUTO_SHIFT_TAB
|
||||
case KC_TAB:
|
||||
# endif
|
||||
# ifndef NO_AUTO_SHIFT_SYMBOLS
|
||||
case AUTO_SHIFT_SYMBOLS:
|
||||
# endif
|
||||
# endif
|
||||
# ifdef AUTO_SHIFT_ENTER
|
||||
case KC_ENT:
|
||||
# endif
|
||||
return true;
|
||||
}
|
||||
return get_custom_auto_shifted_key(keycode, record);
|
||||
}
|
||||
```
|
||||
|
||||
This functionality is enabled by default, and does not need a define.
|
||||
|
||||
### AUTO_SHIFT_REPEAT (simple define)
|
||||
|
||||
Enables keyrepeat.
|
||||
|
||||
### AUTO_SHIFT_NO_AUTO_REPEAT (simple define)
|
||||
|
||||
Disables automatically keyrepeating when `AUTO_SHIFT_TIMEOUT` is exceeded.
|
||||
|
||||
|
||||
### AUTO_SHIFT_ALPHA (predefined key group)
|
||||
|
||||
A predefined group of keys representing A through Z.
|
||||
|
||||
### AUTO_SHIFT_NUMERIC (predefined key group)
|
||||
|
||||
A predefined group of keys representing 0 through 9. Note, these are defined as
|
||||
1 through 0 since that is the order they normally appear in.
|
||||
|
||||
### AUTO_SHIFT_SYMBOLS (predefined key group)
|
||||
|
||||
A predefined group of keys representing symbolic characters which include -\_, =+, [{, ]}, ;:, '", ,<, .>,
|
||||
and /?.
|
||||
|
||||
### AUTO_SHIFT_SPECIAL (predefined key group)
|
||||
|
||||
A predefined group of keys that combines AUTO_SHIFT_SYMBOLS and KC_TAB.
|
||||
|
||||
## Custom Shifted Values
|
||||
|
||||
Especially on small keyboards, the default shifted value for many keys is not
|
||||
optimal. To provide more customizability, there are two user-definable
|
||||
functions, `autoshift_press/release_user`. These register or unregister the
|
||||
correct value for the passed key. Below is an example adding period to Auto
|
||||
Shift and making its shifted value exclamation point. Make sure to use weak
|
||||
mods - setting real would make any keys following it use their shifted values
|
||||
as if you were holding the key. Clearing of modifiers is handled by Auto Shift,
|
||||
and the OS-sent shift value if keyrepeating multiple keys is always that of
|
||||
the last key pressed (whether or not it's an Auto Shift key).
|
||||
|
||||
You can also have non-shifted keys for the shifted values (or even no shifted
|
||||
value), just don't set a shift modifier!
|
||||
|
||||
```c
|
||||
bool get_custom_auto_shifted_key(uint16_t keycode, keyrecord_t *record) {
|
||||
switch(keycode) {
|
||||
case KC_DOT:
|
||||
return true;
|
||||
default:
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
void autoshift_press_user(uint16_t keycode, bool shifted, keyrecord_t *record) {
|
||||
switch(keycode) {
|
||||
case KC_DOT:
|
||||
register_code16((!shifted) ? KC_DOT : KC_EXLM);
|
||||
break;
|
||||
default:
|
||||
if (shifted) {
|
||||
add_weak_mods(MOD_BIT(KC_LSFT));
|
||||
}
|
||||
// & 0xFF gets the Tap key for Tap Holds, required when using Retro Shift
|
||||
register_code16((IS_RETRO(keycode)) ? keycode & 0xFF : keycode);
|
||||
}
|
||||
}
|
||||
|
||||
void autoshift_release_user(uint16_t keycode, bool shifted, keyrecord_t *record) {
|
||||
switch(keycode) {
|
||||
case KC_DOT:
|
||||
unregister_code16((!shifted) ? KC_DOT : KC_EXLM);
|
||||
break;
|
||||
default:
|
||||
// & 0xFF gets the Tap key for Tap Holds, required when using Retro Shift
|
||||
// The IS_RETRO check isn't really necessary here, always using
|
||||
// keycode & 0xFF would be fine.
|
||||
unregister_code16((IS_RETRO(keycode)) ? keycode & 0xFF : keycode);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Retro Shift
|
||||
|
||||
Holding and releasing a Tap Hold key without pressing another key will ordinarily
|
||||
result in only the hold. With `retro shift` enabled this action will instead
|
||||
produce a shifted version of the tap keycode on release.
|
||||
|
||||
It does not require [Retro Tapping](tap_hold.md#retro-tapping) to be enabled, and
|
||||
if both are enabled the state of `retro tapping` will only apply if the tap keycode
|
||||
is not matched by Auto Shift. `RETRO_TAPPING_PER_KEY` and its corresponding
|
||||
function, however, are checked before `retro shift` is applied.
|
||||
|
||||
To enable `retro shift`, add the following to your `config.h`:
|
||||
|
||||
```c
|
||||
#define RETRO_SHIFT
|
||||
```
|
||||
|
||||
If `RETRO_SHIFT` is defined to a value, hold times greater than that value will
|
||||
not produce a tap on release for Mod Taps, and instead triggers the hold action.
|
||||
This enables modifiers to be held for combining with mouse clicks without
|
||||
generating taps on release. For example:
|
||||
|
||||
```c
|
||||
#define RETRO_SHIFT 500
|
||||
```
|
||||
|
||||
Without a value set, holds of any length without an interrupting key will produce the shifted value.
|
||||
|
||||
This value (if set) must be greater than one's `TAPPING_TERM`, as the key press
|
||||
must be designated as a 'hold' by `process_tapping` before we send the modifier.
|
||||
[Per-key tapping terms](tap_hold.md#tapping-term) can be used as a workaround.
|
||||
There is no such limitation in regards to `AUTO_SHIFT_TIMEOUT` for normal keys.
|
||||
|
||||
**Note:** Tap Holds must be added to Auto Shift, see [here.](feature_auto_shift.md#auto-shift-per-key)
|
||||
`IS_RETRO` may be helpful if one wants all Tap Holds retro shifted.
|
||||
|
||||
### Retro Shift and Tap Hold Configurations
|
||||
|
||||
Tap Hold Configurations work a little differently when using Retro Shift.
|
||||
Referencing `TAPPING_TERM` makes little sense, as holding longer would result in
|
||||
shifting one of the keys.
|
||||
|
||||
`RETRO_SHIFT` enables [`PERMISSIVE_HOLD`-like behaviour](tap_hold.md#permissive-hold) (even if not explicitly enabled) on all mod-taps for which `RETRO_SHIFT` applies.
|
||||
|
||||
## Using Auto Shift Setup
|
||||
|
||||
This will enable you to define three keys temporarily to increase, decrease and report your `AUTO_SHIFT_TIMEOUT`.
|
||||
|
||||
### Setup
|
||||
|
||||
Map three keys temporarily in your keymap:
|
||||
|
||||
|Keycode |Aliases |Description |
|
||||
|----------------------|---------|--------------------------------------------|
|
||||
|`QK_AUTO_SHIFT_DOWN` |`AS_DOWN`|Lower the Auto Shift timeout variable (down)|
|
||||
|`QK_AUTO_SHIFT_UP` |`AS_UP` |Raise the Auto Shift timeout variable (up) |
|
||||
|`QK_AUTO_SHIFT_REPORT`|`AS_RPT` |Report your current Auto Shift timeout value|
|
||||
|`QK_AUTO_SHIFT_ON` |`AS_ON` |Turns on the Auto Shift Function |
|
||||
|`QK_AUTO_SHIFT_OFF` |`AS_OFF` |Turns off the Auto Shift Function |
|
||||
|`QK_AUTO_SHIFT_TOGGLE`|`AS_TOGG`|Toggles the state of the Auto Shift feature |
|
||||
|
||||
Compile and upload your new firmware.
|
||||
|
||||
### Use
|
||||
|
||||
It is important to note that during these tests, you should be typing
|
||||
completely normal and with no intention of shifted keys.
|
||||
|
||||
1. Type multiple sentences of alphabetical letters.
|
||||
2. Observe any upper case letters.
|
||||
3. If there are none, press the key you have mapped to `AS_DOWN` to decrease
|
||||
time Auto Shift timeout value and go back to step 1.
|
||||
4. If there are some upper case letters, decide if you need to work on tapping
|
||||
those keys with less down time, or if you need to increase the timeout.
|
||||
5. If you decide to increase the timeout, press the key you have mapped to
|
||||
`AS_UP` and go back to step 1.
|
||||
6. Once you are happy with your results, press the key you have mapped to
|
||||
`AS_RPT`. The keyboard will type by itself the value of your
|
||||
`AUTO_SHIFT_TIMEOUT`.
|
||||
7. Update `AUTO_SHIFT_TIMEOUT` in your `config.h` with the value reported.
|
||||
8. Add `AUTO_SHIFT_NO_SETUP` to your `config.h`.
|
||||
9. Remove the key bindings `AS_DOWN`, `AS_UP` and `AS_RPT`.
|
||||
10. Compile and upload your new firmware.
|
||||
|
||||
#### An Example Run
|
||||
|
||||
hello world. my name is john doe. i am a computer programmer playing with
|
||||
keyboards right now.
|
||||
|
||||
[PRESS AS_DOWN quite a few times]
|
||||
|
||||
heLLo woRLd. mY nAMe is JOHn dOE. i AM A compUTeR proGRaMMER PlAYiNG witH
|
||||
KEYboArDS RiGHT NOw.
|
||||
|
||||
[PRESS AS_UP a few times]
|
||||
|
||||
hello world. my name is john Doe. i am a computer programmer playing with
|
||||
keyboarDs right now.
|
||||
|
||||
[PRESS AS_RPT]
|
||||
|
||||
115
|
||||
|
||||
The keyboard typed `115` which represents your current `AUTO_SHIFT_TIMEOUT`
|
||||
value. You are now set! Practice on the *D* key a little bit that showed up
|
||||
in the testing and you'll be golden.
|
@ -1,312 +0,0 @@
|
||||
# Autocorrect
|
||||
|
||||
There are a lot of words that are prone to being typed incorrectly, due to habit, sequence or just user error. This feature leverages your firmware to automatically correct these errors, to help reduce typos.
|
||||
|
||||
## How does it work? :id=how-does-it-work
|
||||
|
||||
The feature maintains a small buffer of recent key presses. On each key press, it checks whether the buffer ends in a recognized typo, and if so, automatically sends keystrokes to correct it.
|
||||
|
||||
The tricky part is how to efficiently check the buffer for typos. We don’t want to spend too much memory or time on storing or searching the typos. A good solution is to represent the typos with a trie data structure. A trie is a tree data structure where each node is a letter, and words are formed by following a path to one of the leaves.
|
||||
|
||||
![An example trie](https://i.imgur.com/HL5DP8H.png)
|
||||
|
||||
Since we search whether the buffer ends in a typo, we store the trie writing in reverse. The trie is queried starting from the last letter, then second to last letter, and so on, until either a letter doesn’t match or we reach a leaf, meaning a typo was found.
|
||||
|
||||
## How do I enable Autocorrection :id=how-do-i-enable-autocorrection
|
||||
|
||||
In your `rules.mk`, add this:
|
||||
|
||||
```make
|
||||
AUTOCORRECT_ENABLE = yes
|
||||
```
|
||||
|
||||
Additionally, you will need a library for autocorrection. A small sample library is included by default, so that you can get up and running right away, but you can provide a customized library.
|
||||
|
||||
By default, autocorrect is disabled. To enable it, you need to use the `AC_TOGG` keycode to enable it. The status is stored in persistent memory, so you shouldn't need to enabled it again.
|
||||
|
||||
## Customizing autocorrect library :id=customizing-autocorrect-library
|
||||
|
||||
To provide a custom library, you need to create a text file with the corrections. For instance:
|
||||
|
||||
```text
|
||||
:thier -> their
|
||||
fitler -> filter
|
||||
lenght -> length
|
||||
ouput -> output
|
||||
widht -> width
|
||||
```
|
||||
|
||||
The syntax is `typo -> correction`. Typos and corrections are case insensitive, and any whitespace before or after the typo and correction is ignored. The typo must be only the letters a–z, or the special character : representing a word break. The correction may have any non-unicode characters.
|
||||
|
||||
Then, run:
|
||||
|
||||
```sh
|
||||
qmk generate-autocorrect-data autocorrect_dictionary.txt
|
||||
```
|
||||
|
||||
This will process the file and produce an `autocorrect_data.h` file with the trie library, in the folder that you are at. You can specify the keyboard and keymap (eg `-kb planck/rev6 -km jackhumbert`), and it will place the file in that folder instead. But as long as the file is located in your keymap folder, or user folder, it should be picked up automatically.
|
||||
|
||||
This file will look like this:
|
||||
|
||||
```c
|
||||
// :thier -> their
|
||||
// fitler -> filter
|
||||
// lenght -> length
|
||||
// ouput -> output
|
||||
// widht -> width
|
||||
|
||||
#define AUTOCORRECT_MIN_LENGTH 5 // "ouput"
|
||||
#define AUTOCORRECT_MAX_LENGTH 6 // ":thier"
|
||||
|
||||
#define DICTIONARY_SIZE 74
|
||||
|
||||
static const uint8_t autocorrect_data[DICTIONARY_SIZE] PROGMEM = {85, 7, 0, 23, 35, 0, 0, 8, 0, 76, 16, 0, 15, 25, 0, 0,
|
||||
11, 23, 44, 0, 130, 101, 105, 114, 0, 23, 12, 9, 0, 131, 108, 116, 101, 114, 0, 75, 42, 0, 24, 64, 0, 0, 71, 49, 0,
|
||||
10, 56, 0, 0, 12, 26, 0, 129, 116, 104, 0, 17, 8, 15, 0, 129, 116, 104, 0, 19, 24, 18, 0, 130, 116, 112, 117, 116,
|
||||
0};
|
||||
```
|
||||
|
||||
### Avoiding false triggers :id=avoiding-false-triggers
|
||||
|
||||
By default, typos are searched within words, to find typos within longer identifiers like maxFitlerOuput. While this is useful, a consequence is that autocorrection will falsely trigger when a typo happens to be a substring of a correctly-spelled word. For instance, if we had thier -> their as an entry, it would falsely trigger on (correct, though relatively uncommon) words like “wealthier” and “filthier.”
|
||||
|
||||
The solution is to set a word break : before and/or after the typo to constrain matching. : matches space, period, comma, underscore, digits, and most other non-alpha characters.
|
||||
|
||||
|Text |thier |:thier |thier: |:thier: |
|
||||
|-----------------|:------:|:------:|:------:|:------:|
|
||||
|see `thier` typo |matches |matches |matches |matches |
|
||||
|it’s `thiers` |matches |matches |no |no |
|
||||
|wealthier words |matches |no |matches |no |
|
||||
|
||||
:thier: is most restrictive, matching only when thier is a whole word.
|
||||
|
||||
The `qmk generate-autocorrect-data` commands can make an effort to check for entries that would false trigger as substrings of correct words. It searches each typo against a dictionary of 25K English words from the english_words Python package, provided it’s installed. (run `python3 -m pip install english_words` to install it.)
|
||||
|
||||
?> Unfortunately, this is limited to just english words, at this point.
|
||||
|
||||
## Overriding Autocorrect
|
||||
|
||||
Occasionally you might actually want to type a typo (for instance, while editing autocorrect_dict.txt) without being autocorrected. There are a couple of ways to do this:
|
||||
|
||||
1. Begin typing the typo.
|
||||
2. Before typing the last letter, press and release the Ctrl or Alt key.
|
||||
3. Type the remaining letters.
|
||||
|
||||
This works because the autocorrection implementation doesn’t understand hotkeys, so it resets itself whenever a modifier other than shift is held.
|
||||
|
||||
Additionally, you can use the `AC_TOGG` keycode to toggle the on/off status for Autocorrect.
|
||||
|
||||
### Keycodes :id=keycodes
|
||||
|
||||
|Keycode |Aliases |Description |
|
||||
|-----------------------|---------|----------------------------------------------|
|
||||
|`QK_AUTOCORRECT_ON` |`AC_ON` |Turns on the Autocorrect feature. |
|
||||
|`QK_AUTOCORRECT_OFF` |`AC_OFF` |Turns off the Autocorrect feature. |
|
||||
|`QK_AUTOCORRECT_TOGGLE`|`AC_TOGG`|Toggles the status of the Autocorrect feature.|
|
||||
|
||||
## User Callback Functions
|
||||
|
||||
### Process Autocorrect
|
||||
|
||||
Callback function `bool process_autocorrect_user(uint16_t *keycode, keyrecord_t *record, uint8_t *typo_buffer_size, uint8_t *mods)` is available to customise incoming keycodes and handle exceptions. You can use this function to sanitise input before they are passed onto the autocorrect engine
|
||||
|
||||
?> Sanitisation of input is required because autocorrect will only match 8-bit [basic keycodes](keycodes_basic.md) for typos. If valid modifier keys or 16-bit keycodes that are part of a user's word input (such as Shift + A) is passed through, they will fail typo letter detection. For example a [Mod-Tap](mod_tap.md) key such as `LCTL_T(KC_A)` is 16-bit and should be masked for the 8-bit `KC_A`.
|
||||
|
||||
The default user callback function is found inside `quantum/process_keycode/process_autocorrect.c`. It covers most use-cases for QMK special functions and quantum keycodes, including [overriding autocorrect](#overriding-autocorrect) with a modifier other than shift. The `process_autocorrect_user` function is `weak` defined to allow user's copy inside `keymap.c` (or code files) to overwrite it.
|
||||
|
||||
#### Process Autocorrect Example
|
||||
|
||||
If you have a custom keycode `QMKBEST` that should be ignored as part of a word, and another custom keycode `QMKLAYER` that should override autocorrect, both can be added to the bottom of the `process_autocorrect_user` `switch` statement in your source code:
|
||||
|
||||
```c
|
||||
bool process_autocorrect_user(uint16_t *keycode, keyrecord_t *record, uint8_t *typo_buffer_size, uint8_t *mods) {
|
||||
// See quantum_keycodes.h for reference on these matched ranges.
|
||||
switch (*keycode) {
|
||||
// Exclude these keycodes from processing.
|
||||
case KC_LSFT:
|
||||
case KC_RSFT:
|
||||
case KC_CAPS:
|
||||
case QK_TO ... QK_ONE_SHOT_LAYER_MAX:
|
||||
case QK_LAYER_TAP_TOGGLE ... QK_LAYER_MOD_MAX:
|
||||
case QK_ONE_SHOT_MOD ... QK_ONE_SHOT_MOD_MAX:
|
||||
return false;
|
||||
|
||||
// Mask for base keycode from shifted keys.
|
||||
case QK_LSFT ... QK_LSFT + 255:
|
||||
case QK_RSFT ... QK_RSFT + 255:
|
||||
if (*keycode >= QK_LSFT && *keycode <= (QK_LSFT + 255)) {
|
||||
*mods |= MOD_LSFT;
|
||||
} else {
|
||||
*mods |= MOD_RSFT;
|
||||
}
|
||||
*keycode &= 0xFF; // Get the basic keycode.
|
||||
return true;
|
||||
#ifndef NO_ACTION_TAPPING
|
||||
// Exclude tap-hold keys when they are held down
|
||||
// and mask for base keycode when they are tapped.
|
||||
case QK_LAYER_TAP ... QK_LAYER_TAP_MAX:
|
||||
# ifdef NO_ACTION_LAYER
|
||||
// Exclude Layer Tap, if layers are disabled
|
||||
// but action tapping is still enabled.
|
||||
return false;
|
||||
# endif
|
||||
case QK_MOD_TAP ... QK_MOD_TAP_MAX:
|
||||
// Exclude hold if mods other than Shift is not active
|
||||
if (!record->tap.count) {
|
||||
return false;
|
||||
}
|
||||
*keycode &= 0xFF;
|
||||
break;
|
||||
#else
|
||||
case QK_MOD_TAP ... QK_MOD_TAP_MAX:
|
||||
case QK_LAYER_TAP ... QK_LAYER_TAP_MAX:
|
||||
// Exclude if disabled
|
||||
return false;
|
||||
#endif
|
||||
// Exclude swap hands keys when they are held down
|
||||
// and mask for base keycode when they are tapped.
|
||||
case QK_SWAP_HANDS ... QK_SWAP_HANDS_MAX:
|
||||
#ifdef SWAP_HANDS_ENABLE
|
||||
if (*keycode >= 0x56F0 || !record->tap.count) {
|
||||
return false;
|
||||
}
|
||||
*keycode &= 0xFF;
|
||||
break;
|
||||
#else
|
||||
// Exclude if disabled
|
||||
return false;
|
||||
#endif
|
||||
// Handle custom keycodes
|
||||
case QMKBEST:
|
||||
return false;
|
||||
case QMKLAYER:
|
||||
*typo_buffer_size = 0;
|
||||
return false;
|
||||
}
|
||||
|
||||
// Disable autocorrect while a mod other than shift is active.
|
||||
if ((*mods & ~MOD_MASK_SHIFT) != 0) {
|
||||
*typo_buffer_size = 0;
|
||||
return false;
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
```
|
||||
|
||||
?> In this callback function, `return false` will skip processing of that keycode for autocorrect. Adding `*typo_buffer_size = 0` will also reset the autocorrect buffer at the same time, cancelling any current letters already stored in the buffer.
|
||||
|
||||
### Apply Autocorrect
|
||||
|
||||
Additionally, `apply_autocorrect(uint8_t backspaces, const char *str, char *typo, char *correct)` allows for users to add additional handling to the autocorrection, or replace the functionality entirely. This passes on the number of backspaces needed to replace the words, as well as the replacement string (partial word, not the full word), and the typo and corrected strings (complete words).
|
||||
|
||||
?> Due to the way code works (no notion of words, just a stream of letters), the `typo` and `correct` strings are a best bet and could be "wrong". For example you may get `wordtpyo` & `wordtypo` instead of the expected `tpyo` & `typo`.
|
||||
|
||||
#### Apply Autocorrect Example
|
||||
|
||||
This following example will play a sound when a typo is autocorrected and execute the autocorrection itself:
|
||||
|
||||
```c
|
||||
#ifdef AUDIO_ENABLE
|
||||
float autocorrect_song[][2] = SONG(TERMINAL_SOUND);
|
||||
#endif
|
||||
|
||||
bool apply_autocorrect(uint8_t backspaces, const char *str, char *typo, char *correct) {
|
||||
#ifdef AUDIO_ENABLE
|
||||
PLAY_SONG(autocorrect_song);
|
||||
#endif
|
||||
for (uint8_t i = 0; i < backspaces; ++i) {
|
||||
tap_code(KC_BSPC);
|
||||
}
|
||||
send_string_P(str);
|
||||
return false;
|
||||
}
|
||||
```
|
||||
|
||||
?> In this callback function, `return false` will stop the normal processing of autocorrect, which requires manually handling of removing the "bad" characters and typing the new characters.
|
||||
|
||||
!> ***IMPORTANT***: `str` is a pointer to `PROGMEM` data for the autocorrection. If you return false, and want to send the string, this needs to use `send_string_P` and not `send_string` nor `SEND_STRING`.
|
||||
|
||||
You can also use `apply_autocorrect` to detect and display the event but allow internal code to execute the autocorrection with `return true`:
|
||||
|
||||
```c
|
||||
bool apply_autocorrect(uint8_t backspaces, const char *str, char *typo, char *correct) {
|
||||
#ifdef OLED_ENABLE
|
||||
oled_write_P(PSTR("Auto-corrected"), false);
|
||||
#endif
|
||||
#ifdef CONSOLE_ENABLE
|
||||
printf("'%s' was corrected to '%s'\n", typo, correct);
|
||||
#endif
|
||||
return true;
|
||||
}
|
||||
```
|
||||
|
||||
### Autocorrect Status
|
||||
|
||||
Additional user callback functions to manipulate Autocorrect:
|
||||
|
||||
| Function | Description |
|
||||
|----------------------------|----------------------------------------------|
|
||||
| `autocorrect_enable()` | Turns Autocorrect on. |
|
||||
| `autocorrect_disable()` | Turns Autocorrect off. |
|
||||
| `autocorrect_toggle()` | Toggles Autocorrect. |
|
||||
| `autocorrect_is_enabled()` | Returns true if Autocorrect is currently on. |
|
||||
|
||||
|
||||
## Appendix: Trie binary data format :id=appendix
|
||||
|
||||
This section details how the trie is serialized to byte data in autocorrect_data. You don’t need to care about this to use this autocorrection implementation. But it is documented for the record in case anyone is interested in modifying the implementation, or just curious how it works.
|
||||
|
||||
What I did here is fairly arbitrary, but it is simple to decode and gets the job done.
|
||||
|
||||
### Encoding :id=encoding
|
||||
|
||||
All autocorrection data is stored in a single flat array autocorrect_data. Each trie node is associated with a byte offset into this array, where data for that node is encoded, beginning with root at offset 0. There are three kinds of nodes. The highest two bits of the first byte of the node indicate what kind:
|
||||
|
||||
* 00 ⇒ chain node: a trie node with a single child.
|
||||
* 01 ⇒ branching node: a trie node with multiple children.
|
||||
* 10 ⇒ leaf node: a leaf, corresponding to a typo and storing its correction.
|
||||
|
||||
![An example trie](https://i.imgur.com/HL5DP8H.png)
|
||||
|
||||
**Branching node**. Each branch is encoded with one byte for the keycode (KC_A–KC_Z) followed by a link to the child node. Links between nodes are 16-bit byte offsets relative to the beginning of the array, serialized in little endian order.
|
||||
|
||||
All branches are serialized this way, one after another, and terminated with a zero byte. As described above, the node is identified as a branch by setting the two high bits of the first byte to 01, done by bitwise ORing the first keycode with 64. keycode. The root node for the above figure would be serialized like:
|
||||
|
||||
```
|
||||
+-------+-------+-------+-------+-------+-------+-------+
|
||||
| R|64 | node 2 | T | node 3 | 0 |
|
||||
+-------+-------+-------+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
**Chain node**. Tries tend to have long chains of single-child nodes, as seen in the example above with f-i-t-l in fitler. So to save space, we use a different format to encode chains than branching nodes. A chain is encoded as a string of keycodes, beginning with the node closest to the root, and terminated with a zero byte. The child of the last node in the chain is encoded immediately after. That child could be either a branching node or a leaf.
|
||||
|
||||
In the figure above, the f-i-t-l chain is encoded as
|
||||
|
||||
```
|
||||
+-------+-------+-------+-------+-------+
|
||||
| L | T | I | F | 0 |
|
||||
+-------+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
If we were to encode this chain using the same format used for branching nodes, we would encode a 16-bit node link with every node, costing 8 more bytes in this example. Across the whole trie, this adds up. Conveniently, we can point to intermediate points in the chain and interpret the bytes in the same way as before. E.g. starting at the i instead of the l, and the subchain has the same format.
|
||||
|
||||
**Leaf node**. A leaf node corresponds to a particular typo and stores data to correct the typo. The leaf begins with a byte for the number of backspaces to type, and is followed by a null-terminated ASCII string of the replacement text. The idea is, after tapping backspace the indicated number of times, we can simply pass this string to the `send_string_P` function. For fitler, we need to tap backspace 3 times (not 4, because we catch the typo as the final ‘r’ is pressed) and replace it with lter. To identify the node as a leaf, the two high bits are set to 10 by ORing the backspace count with 128:
|
||||
|
||||
```
|
||||
+-------+-------+-------+-------+-------+-------+
|
||||
| 3|128 | 'l' | 't' | 'e' | 'r' | 0 |
|
||||
+-------+-------+-------+-------+-------+-------+
|
||||
```
|
||||
|
||||
### Decoding :id=decoding
|
||||
|
||||
This format is by design decodable with fairly simple logic. A 16-bit variable state represents our current position in the trie, initialized with 0 to start at the root node. Then, for each keycode, test the highest two bits in the byte at state to identify the kind of node.
|
||||
|
||||
* 00 ⇒ **chain node**: If the node’s byte matches the keycode, increment state by one to go to the next byte. If the next byte is zero, increment again to go to the following node.
|
||||
* 01 ⇒ **branching node**: Search the branches for one that matches the keycode, and follow its node link.
|
||||
* 10 ⇒ **leaf node**: a typo has been found! We read its first byte for the number of backspaces to type, then pass its following bytes to send_string_P to type the correction.
|
||||
|
||||
## Credits
|
||||
|
||||
Credit goes to [getreuer](https://github.com/getreuer) for originally implementing this [here](https://getreuer.info/posts/keyboards/autocorrection/#how-does-it-work). As well as to [filterpaper](https://github.com/filterpaper) for converting the code to use PROGMEM, and additional improvements.
|
@ -1,309 +0,0 @@
|
||||
# Backlighting :id=backlighting
|
||||
|
||||
Many keyboards support backlit keys by way of individual LEDs placed through or underneath the keyswitches. This feature is distinct from both the [RGB Underglow](feature_rgblight.md) and [RGB Matrix](feature_rgb_matrix.md) features as it usually allows for only a single colour per switch, though you can obviously install multiple different single coloured LEDs on a keyboard.
|
||||
|
||||
QMK is able to control the brightness of these LEDs by switching them on and off rapidly in a certain ratio, a technique known as *Pulse Width Modulation*, or PWM. By altering the duty cycle of the PWM signal, it creates the illusion of dimming.
|
||||
|
||||
## Usage :id=usage
|
||||
|
||||
Most keyboards have backlighting enabled by default if they support it, but if it is not working for you (or you have added support), check that your `rules.mk` includes the following:
|
||||
|
||||
```make
|
||||
BACKLIGHT_ENABLE = yes
|
||||
```
|
||||
|
||||
## Keycodes :id=keycodes
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|-------------------------------|---------|-----------------------------------|
|
||||
|`QK_BACKLIGHT_TOGGLE` |`BL_TOGG`|Turn the backlight on or off |
|
||||
|`QK_BACKLIGHT_STEP` |`BL_STEP`|Cycle through backlight levels |
|
||||
|`QK_BACKLIGHT_ON` |`BL_ON` |Set the backlight to max brightness|
|
||||
|`QK_BACKLIGHT_OFF` |`BL_OFF` |Turn the backlight off |
|
||||
|`QK_BACKLIGHT_UP` |`BL_UP` |Increase the backlight level |
|
||||
|`QK_BACKLIGHT_DOWN` |`BL_DOWN`|Decrease the backlight level |
|
||||
|`QK_BACKLIGHT_TOGGLE_BREATHING`|`BL_BRTG`|Toggle backlight breathing |
|
||||
|
||||
## Basic Configuration :id=basic-configuration
|
||||
|
||||
Add the following to your `config.h`:
|
||||
|
||||
|Define |Default |Description |
|
||||
|-----------------------------|------------------|-----------------------------------------------------------------------------------------------------------------|
|
||||
|`BACKLIGHT_PIN` |*Not defined* |The pin that controls the LEDs |
|
||||
|`BACKLIGHT_LEVELS` |`3` |The number of brightness levels (maximum 31 excluding off) |
|
||||
|`BACKLIGHT_CAPS_LOCK` |*Not defined* |Enable Caps Lock indicator using backlight (for keyboards without dedicated LED) |
|
||||
|`BACKLIGHT_BREATHING` |*Not defined* |Enable backlight breathing, if supported |
|
||||
|`BREATHING_PERIOD` |`6` |The length of one backlight "breath" in seconds |
|
||||
|`BACKLIGHT_ON_STATE` |`1` |The state of the backlight pin when the backlight is "on" - `1` for high, `0` for low |
|
||||
|`BACKLIGHT_LIMIT_VAL` |`255` |The maximum duty cycle of the backlight -- `255` allows for full brightness, any lower will decrease the maximum.|
|
||||
|`BACKLIGHT_DEFAULT_ON` |`true` |Enable backlight upon clearing the EEPROM |
|
||||
|`BACKLIGHT_DEFAULT_BREATHING`|`false` |Whether to enable backlight breathing upon clearing the EEPROM |
|
||||
|`BACKLIGHT_DEFAULT_LEVEL` |`BACKLIGHT_LEVELS`|The default backlight level to use upon clearing the EEPROM |
|
||||
|
||||
Unless you are designing your own keyboard, you generally should not need to change the `BACKLIGHT_PIN` or `BACKLIGHT_ON_STATE`.
|
||||
|
||||
### "On" State :id=on-state
|
||||
|
||||
Most backlight circuits are driven by an N-channel MOSFET or NPN transistor. This means that to turn the transistor *on* and light the LEDs, you must drive the backlight pin, connected to the gate or base, *high*.
|
||||
Sometimes, however, a P-channel MOSFET, or a PNP transistor is used. In this case, when the transistor is on, the pin is driven *low* instead.
|
||||
|
||||
To configure the "on" state of the backlight circuit, add the following to your `config.h`:
|
||||
|
||||
```c
|
||||
#define BACKLIGHT_ON_STATE 0
|
||||
```
|
||||
|
||||
### Multiple Backlight Pins :id=multiple-backlight-pins
|
||||
|
||||
Most keyboards have only one backlight pin which controls all backlight LEDs (especially if the backlight is connected to a hardware PWM pin).
|
||||
The `timer` and `software` drivers allow you to define multiple backlight pins, which will be turned on and off at the same time during the PWM duty cycle.
|
||||
|
||||
This feature allows to set, for instance, the Caps Lock LED's (or any other controllable LED) brightness at the same level as the other LEDs of the backlight. This is useful if you have mapped Control in place of Caps Lock and you need the Caps Lock LED to be part of the backlight instead of being activated when Caps Lock is on, as it is usually wired to a separate pin from the backlight.
|
||||
|
||||
To configure multiple backlight pins, add something like this to your `config.h`, instead of `BACKLIGHT_PIN`:
|
||||
|
||||
```c
|
||||
#define BACKLIGHT_PINS { F5, B2 }
|
||||
```
|
||||
|
||||
## Driver Configuration :id=driver-configuration
|
||||
|
||||
Backlight driver selection is configured in `rules.mk`. Valid drivers are `pwm` (default), `timer`, `software`, or `custom`. See below for information on individual drivers.
|
||||
|
||||
### PWM Driver :id=pwm-driver
|
||||
|
||||
This is the default backlight driver, which leverages the hardware PWM output capability of the microcontroller.
|
||||
|
||||
```make
|
||||
BACKLIGHT_DRIVER = pwm
|
||||
```
|
||||
|
||||
### Timer Driver :id=timer-driver
|
||||
|
||||
This driver is similar to the PWM driver, but instead of directly configuring the pin to output a PWM signal, an interrupt handler is attached to the timer to turn the pin on and off as appropriate.
|
||||
|
||||
```make
|
||||
BACKLIGHT_DRIVER = timer
|
||||
```
|
||||
|
||||
### Software Driver :id=software-driver
|
||||
|
||||
In this mode, PWM is "emulated" while running other keyboard tasks. It offers maximum hardware compatibility without extra platform configuration. However, breathing is not supported, and the backlight can flicker when the keyboard is busy.
|
||||
|
||||
```make
|
||||
BACKLIGHT_DRIVER = software
|
||||
```
|
||||
|
||||
### Custom Driver :id=custom-driver
|
||||
|
||||
If none of the above drivers apply to your board (for example, you are using a separate IC to control the backlight), you can implement a custom backlight driver using a simple API.
|
||||
|
||||
```make
|
||||
BACKLIGHT_DRIVER = custom
|
||||
```
|
||||
|
||||
```c
|
||||
void backlight_init_ports(void) {
|
||||
// Optional - runs on startup
|
||||
// Usually you want to configure pins here
|
||||
}
|
||||
void backlight_set(uint8_t level) {
|
||||
// Optional - runs on level change
|
||||
// Usually you want to respond to the new value
|
||||
}
|
||||
|
||||
void backlight_task(void) {
|
||||
// Optional - runs periodically
|
||||
// Note that this is called in the main keyboard loop,
|
||||
// so long running actions here can cause performance issues
|
||||
}
|
||||
```
|
||||
|
||||
## AVR Configuration :id=avr-configuration
|
||||
|
||||
### PWM Driver :id=avr-pwm-driver
|
||||
|
||||
The following table describes the supported pins for the PWM driver. Only cells marked with a timer number are capable of hardware PWM output; any others must use the `timer` driver.
|
||||
|
||||
|Backlight Pin|AT90USB64/128|AT90USB162|ATmega16/32U4|ATmega16/32U2|ATmega32A|ATmega328/P|
|
||||
|-------------|-------------|----------|-------------|-------------|---------|-----------|
|
||||
|`B1` | | | | | |Timer 1 |
|
||||
|`B2` | | | | | |Timer 1 |
|
||||
|`B5` |Timer 1 | |Timer 1 | | | |
|
||||
|`B6` |Timer 1 | |Timer 1 | | | |
|
||||
|`B7` |Timer 1 |Timer 1 |Timer 1 |Timer 1 | | |
|
||||
|`C4` |Timer 3 | | | | | |
|
||||
|`C5` |Timer 3 |Timer 1 | |Timer 1 | | |
|
||||
|`C6` |Timer 3 |Timer 1 |Timer 3 |Timer 1 | | |
|
||||
|`D4` | | | | |Timer 1 | |
|
||||
|`D5` | | | | |Timer 1 | |
|
||||
|
||||
### Timer Driver :id=avr-timer-driver
|
||||
|
||||
Any GPIO pin can be used with this driver. The following table describes the supported timers:
|
||||
|
||||
|AT90USB64/128|AT90USB162|ATmega16/32U4|ATmega16/32U2|ATmega32A|ATmega328/P|
|
||||
|-------------|----------|-------------|-------------|---------|-----------|
|
||||
|Timers 1 & 3 |Timer 1 |Timers 1 & 3 |Timer 1 |Timer 1 |Timer 1 |
|
||||
|
||||
The following `#define`s apply only to the `timer` driver:
|
||||
|
||||
|Define |Default|Description |
|
||||
|-----------------------|-------|----------------|
|
||||
|`BACKLIGHT_PWM_TIMER` |`1` |The timer to use|
|
||||
|
||||
Note that the choice of timer may conflict with the [Audio](feature_audio.md) feature.
|
||||
|
||||
## ChibiOS/ARM Configuration :id=arm-configuration
|
||||
|
||||
### PWM Driver :id=arm-pwm-driver
|
||||
|
||||
Depending on the ChibiOS board configuration, you may need to enable PWM at the keyboard level. For STM32, this would look like:
|
||||
|
||||
`halconf.h`:
|
||||
```c
|
||||
#define HAL_USE_PWM TRUE
|
||||
```
|
||||
`mcuconf.h`:
|
||||
```c
|
||||
#undef STM32_PWM_USE_TIM4
|
||||
#define STM32_PWM_USE_TIM4 TRUE
|
||||
```
|
||||
|
||||
The following `#define`s apply only to the `pwm` driver:
|
||||
|
||||
|Define |Default |Description |
|
||||
|-----------------------|-------------|---------------------------------------------------------------|
|
||||
|`BACKLIGHT_PWM_DRIVER` |`PWMD4` |The PWM driver to use |
|
||||
|`BACKLIGHT_PWM_CHANNEL`|`3` |The PWM channel to use |
|
||||
|`BACKLIGHT_PAL_MODE` |`2` |The pin alternative function to use |
|
||||
|`BACKLIGHT_PWM_PERIOD` |*Not defined*|The PWM period in counter ticks - Default is platform dependent|
|
||||
|
||||
|
||||
Refer to the ST datasheet for your particular MCU to determine these values. For example, these defaults are set up for pin `B8` on a Proton-C (STM32F303) using `TIM4_CH3` on AF2. Unless you are designing your own keyboard, you generally should not need to change them.
|
||||
|
||||
### Timer Driver :id=arm-timer-driver
|
||||
|
||||
Depending on the ChibiOS board configuration, you may need to enable general-purpose timers at the keyboard level. For STM32, this would look like:
|
||||
|
||||
`halconf.h`:
|
||||
```c
|
||||
#define HAL_USE_GPT TRUE
|
||||
```
|
||||
`mcuconf.h`:
|
||||
```c
|
||||
#undef STM32_GPT_USE_TIM15
|
||||
#define STM32_GPT_USE_TIM15 TRUE
|
||||
```
|
||||
|
||||
The following `#define`s apply only to the `timer` driver:
|
||||
|
||||
|Define |Default |Description |
|
||||
|----------------------|--------|----------------|
|
||||
|`BACKLIGHT_GPT_DRIVER`|`GPTD15`|The timer to use|
|
||||
|
||||
## Example Schematic
|
||||
|
||||
Since the MCU can only supply so much current to its GPIO pins, instead of powering the backlight directly from the MCU, the backlight pin is connected to a transistor or MOSFET that switches the power to the LEDs.
|
||||
|
||||
In this typical example, the backlight LEDs are all connected in parallel towards an N-channel MOSFET. Its gate pin is wired to one of the microcontroller's GPIO pins through a 470Ω resistor to avoid ringing.
|
||||
A pulldown resistor is also placed between the gate pin and ground to keep it at a defined state when it is not otherwise being driven by the MCU.
|
||||
The values of these resistors are not critical - see [this Electronics StackExchange question](https://electronics.stackexchange.com/q/68748) for more information.
|
||||
|
||||
![Backlight example circuit](https://i.imgur.com/BmAvoUC.png)
|
||||
|
||||
## API :id=api
|
||||
|
||||
### `void backlight_toggle(void)` :id=api-backlight-toggle
|
||||
|
||||
Toggle the backlight on or off.
|
||||
|
||||
---
|
||||
|
||||
### `void backlight_enable(void)` :id=api-backlight-enable
|
||||
|
||||
Turn the backlight on.
|
||||
|
||||
---
|
||||
|
||||
### `void backlight_disable(void)` :id=api-backlight-disable
|
||||
|
||||
Turn the backlight off.
|
||||
|
||||
---
|
||||
|
||||
### `void backlight_step(void)` :id=api-backlight-step
|
||||
|
||||
Cycle through backlight levels.
|
||||
|
||||
---
|
||||
|
||||
### `void backlight_increase(void)` :id=api-backlight-increase
|
||||
|
||||
Increase the backlight level.
|
||||
|
||||
---
|
||||
|
||||
### `void backlight_decrease(void)` :id=api-backlight-decrease
|
||||
|
||||
Decrease the backlight level.
|
||||
|
||||
---
|
||||
|
||||
### `void backlight_level(uint8_t level)` :id=api-backlight-level
|
||||
|
||||
Set the backlight level.
|
||||
|
||||
#### Arguments :id=api-backlight-level-arguments
|
||||
|
||||
- `uint8_t level`
|
||||
The level to set, from 0 to `BACKLIGHT_LEVELS`.
|
||||
|
||||
---
|
||||
|
||||
### `uint8_t get_backlight_level(void)` :id=api-get-backlight-level
|
||||
|
||||
Get the current backlight level.
|
||||
|
||||
#### Return Value :id=api-get-backlight-level-return
|
||||
|
||||
The current backlight level, from 0 to `BACKLIGHT_LEVELS`.
|
||||
|
||||
---
|
||||
|
||||
### `bool is_backlight_enabled(void)` :id=api-is-backlight-enabled
|
||||
|
||||
Get the current backlight state.
|
||||
|
||||
#### Return Value :id=api-is-backlight-enabled-return
|
||||
|
||||
`true` if the backlight is enabled.
|
||||
|
||||
---
|
||||
|
||||
### `void backlight_toggle_breathing(void)` :id=api-backlight-toggle-breathing
|
||||
|
||||
Toggle backlight breathing on or off.
|
||||
|
||||
---
|
||||
|
||||
### `void backlight_enable_breathing(void)` :id=api-backlight-enable-breathing
|
||||
|
||||
Turn backlight breathing on.
|
||||
|
||||
---
|
||||
|
||||
### `void backlight_disable_breathing(void)` :id=api-backlight-disable-breathing
|
||||
|
||||
Turn backlight breathing off.
|
||||
|
||||
---
|
||||
|
||||
### `bool is_backlight_breathing(void)` :id=api-is-backlight-breathing
|
||||
|
||||
Get the current backlight breathing state.
|
||||
|
||||
#### Return Value :id=api-is-backlight-breathing-return
|
||||
|
||||
`true` if backlight breathing is enabled.
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user