mirror of
https://github.com/qmk/qmk_firmware.git
synced 2025-08-06 06:54:58 +00:00
Compare commits
427 Commits
generate_a
...
0.27.4
Author | SHA1 | Date | |
---|---|---|---|
![]() |
57f89e5388 | ||
![]() |
53680fa6da | ||
![]() |
fe2200f73a | ||
![]() |
fd0a552fc1 | ||
![]() |
f549948bbd | ||
![]() |
5593e73ba7 | ||
![]() |
58323017ff | ||
![]() |
a822545da0 | ||
![]() |
40c93bcdc6 | ||
![]() |
276f84a9a8 | ||
![]() |
0b5e7052f9 | ||
![]() |
18f0d11737 | ||
![]() |
e6fa351d3b | ||
![]() |
18cca2062e | ||
![]() |
58807b0288 | ||
![]() |
9877af9bf8 | ||
![]() |
f3fe59afe2 | ||
![]() |
c988584fc1 | ||
![]() |
a7d12e4e8f | ||
![]() |
767dfbbd3f | ||
![]() |
296e4539f5 | ||
![]() |
2d33a20956 | ||
![]() |
597bbcb567 | ||
![]() |
d589dbb05b | ||
![]() |
d283e27bf8 | ||
![]() |
847257c3c7 | ||
![]() |
388c3c6d12 | ||
![]() |
39958fe854 | ||
![]() |
3c35952944 | ||
![]() |
379bb77005 | ||
![]() |
1c6d3d0cbc | ||
![]() |
782f91a73a | ||
![]() |
a12ff287ee | ||
![]() |
03937e0c86 | ||
![]() |
09fdabf37c | ||
![]() |
d76f7bfac3 | ||
![]() |
3c324cb5e6 | ||
![]() |
d01303c060 | ||
![]() |
5dc92edf11 | ||
![]() |
8094a1d182 | ||
![]() |
88d4462e52 | ||
![]() |
c2bc6e2b3c | ||
![]() |
a794ceeb51 | ||
![]() |
85222dfd8c | ||
![]() |
e7f1388317 | ||
![]() |
f0eb2460d9 | ||
![]() |
93765bb0ef | ||
![]() |
c5eeac9686 | ||
![]() |
191172aa4e | ||
![]() |
c8fe565ee6 | ||
![]() |
50966934b2 | ||
![]() |
09dfbf8efe | ||
![]() |
e4e66c61ad | ||
![]() |
28320f0cb5 | ||
![]() |
cd286e4b9d | ||
![]() |
0ad3ffdfbc | ||
![]() |
fa3be8a3fb | ||
![]() |
e592a7da00 | ||
![]() |
be7786bfc6 | ||
![]() |
39c40f55cb | ||
![]() |
b022d3bc6b | ||
![]() |
5eb53be671 | ||
![]() |
1da8aa8259 | ||
![]() |
97547ac762 | ||
![]() |
66d0d53dc1 | ||
![]() |
9f76541b29 | ||
![]() |
eb04b94eec | ||
![]() |
b7b0eb76a9 | ||
![]() |
36f306b4a5 | ||
![]() |
f3bae56808 | ||
![]() |
7d8f193988 | ||
![]() |
859dab864a | ||
![]() |
1f7d10902a | ||
![]() |
d189de24a0 | ||
![]() |
e4e015c0c8 | ||
![]() |
4a5bae51cd | ||
![]() |
9e9b4acbde | ||
![]() |
57be487161 | ||
![]() |
968a611476 | ||
![]() |
65a8a5ff69 | ||
![]() |
c7a04bd930 | ||
![]() |
36b5559b99 | ||
![]() |
39161b9ee7 | ||
![]() |
074bbbfb21 | ||
![]() |
638b22d057 | ||
![]() |
9bea332a21 | ||
![]() |
8cbcdcac62 | ||
![]() |
88afd53b1f | ||
![]() |
9c86583981 | ||
![]() |
e66fce38b2 | ||
![]() |
c843ad1268 | ||
![]() |
0853a8ea35 | ||
![]() |
0988523851 | ||
![]() |
7936a791ed | ||
![]() |
3a6df60ba5 | ||
![]() |
5ab408aef7 | ||
![]() |
da34d652d4 | ||
![]() |
310c4847d5 | ||
![]() |
f4e58eeff4 | ||
![]() |
79a661fe61 | ||
![]() |
46236ce3de | ||
![]() |
0bda0f4775 | ||
![]() |
f8b4e24d37 | ||
![]() |
a8a47c4011 | ||
![]() |
d04789e9ea | ||
![]() |
4757ef281f | ||
![]() |
4e77ab66e2 | ||
![]() |
3d4da6de29 | ||
![]() |
be7b479c4a | ||
![]() |
9cd7896760 | ||
![]() |
291f1992d3 | ||
![]() |
8cbd631fcb | ||
![]() |
a3cfb1dab7 | ||
![]() |
69093f6de9 | ||
![]() |
3eb172d08e | ||
![]() |
a8fc265bf1 | ||
![]() |
b3f5408e72 | ||
![]() |
b06e9fdd95 | ||
![]() |
f156e57f8e | ||
![]() |
10849dac68 | ||
![]() |
94b6039620 | ||
![]() |
fb3a414a40 | ||
![]() |
fca6ad4ebc | ||
![]() |
e31eeb85db | ||
![]() |
9523ed9e32 | ||
![]() |
b17322b9b8 | ||
![]() |
580d18d2e9 | ||
![]() |
b10fa5032f | ||
![]() |
4f9ef90754 | ||
![]() |
f2a7f4b804 | ||
![]() |
3cda9ffcd6 | ||
![]() |
54860ed238 | ||
![]() |
83950c7dd9 | ||
![]() |
f4e6af2dbe | ||
![]() |
7877023b48 | ||
![]() |
f5f11b7c79 | ||
![]() |
cfb870d219 | ||
![]() |
6fbfd659ff | ||
![]() |
81a6f3e641 | ||
![]() |
c8cdee3e4e | ||
![]() |
292e0af293 | ||
![]() |
f1f875063c | ||
![]() |
465cbc87de | ||
![]() |
834f88b0a3 | ||
![]() |
6693a30671 | ||
![]() |
114b3db96a | ||
![]() |
e6daffce46 | ||
![]() |
b8dd09994a | ||
![]() |
92afc8198a | ||
![]() |
2aa186873e | ||
![]() |
06b7dce565 | ||
![]() |
95406717e7 | ||
![]() |
7c9e650b1c | ||
![]() |
7630a80791 | ||
![]() |
2c0cdcf7b2 | ||
![]() |
25fac5e737 | ||
![]() |
dd7287bf4e | ||
![]() |
d9fedce9b9 | ||
![]() |
01f6fa7cd6 | ||
![]() |
644588baef | ||
![]() |
7005522176 | ||
![]() |
f5b495e06e | ||
![]() |
5c85271e48 | ||
![]() |
f486605bab | ||
![]() |
32b6faaf35 | ||
![]() |
d00df05df1 | ||
![]() |
bf327f7a81 | ||
![]() |
d316331ab1 | ||
![]() |
3b874ee434 | ||
![]() |
bb9625ba55 | ||
![]() |
11db924a31 | ||
![]() |
453ec007c1 | ||
![]() |
b2608e3162 | ||
![]() |
459de98222 | ||
![]() |
c6b2553470 | ||
![]() |
baa29fef9d | ||
![]() |
22e6a8d15e | ||
![]() |
7f22cb52e3 | ||
![]() |
3f9d464412 | ||
![]() |
80f8aae3ec | ||
![]() |
36008922f8 | ||
![]() |
6602ee04af | ||
![]() |
2ad13037ab | ||
![]() |
7e53bb9965 | ||
![]() |
85a7627641 | ||
![]() |
13581820b8 | ||
![]() |
d0d170e6a0 | ||
![]() |
dd0068cfd4 | ||
![]() |
9884e4982b | ||
![]() |
5478051d74 | ||
![]() |
6fa11bf219 | ||
![]() |
5c97a78ce6 | ||
![]() |
11daef82e0 | ||
![]() |
9d17779832 | ||
![]() |
8844fba607 | ||
![]() |
6129af93f4 | ||
![]() |
a10e7cc858 | ||
![]() |
40d49ee487 | ||
![]() |
9246163b77 | ||
![]() |
c95f0fb671 | ||
![]() |
049865c30c | ||
![]() |
f0b5feb858 | ||
![]() |
eac4053a07 | ||
![]() |
f43c9127bf | ||
![]() |
27d68ef8b9 | ||
![]() |
c8a87ff3fe | ||
![]() |
4055798807 | ||
![]() |
29bc842fe2 | ||
![]() |
49a1a12a32 | ||
![]() |
00db6f2397 | ||
![]() |
fb598e7e61 | ||
![]() |
8cc6127668 | ||
![]() |
c0d57a6826 | ||
![]() |
c3ffbe4504 | ||
![]() |
8c27ae8fd7 | ||
![]() |
1a284f2b92 | ||
![]() |
3a5be8bd22 | ||
![]() |
f25624dca4 | ||
![]() |
a428727897 | ||
![]() |
035dcf213c | ||
![]() |
2cb35373c6 | ||
![]() |
bf6de46d7f | ||
![]() |
7446c6ea7d | ||
![]() |
c9cd92ece3 | ||
![]() |
ddfb8765ec | ||
![]() |
ff21363627 | ||
![]() |
d381bb7258 | ||
![]() |
c2dd0c1845 | ||
![]() |
50e54d8e1a | ||
![]() |
13a87ad354 | ||
![]() |
7f475b590a | ||
![]() |
a322107cb7 | ||
![]() |
305e7baa71 | ||
![]() |
65b5dc7e0f | ||
![]() |
c82f675266 | ||
![]() |
3cf94cb308 | ||
![]() |
208ebf54a9 | ||
![]() |
43e82ed5c7 | ||
![]() |
3d8cebb1a0 | ||
![]() |
e12c1fefdf | ||
![]() |
4bb3741288 | ||
![]() |
6a73c8299b | ||
![]() |
04c5deb503 | ||
![]() |
6374bad540 | ||
![]() |
a1597e7292 | ||
![]() |
b78118b2dd | ||
![]() |
62367b2133 | ||
![]() |
015cd23616 | ||
![]() |
e31ef83495 | ||
![]() |
f18a699393 | ||
![]() |
1118821178 | ||
![]() |
4d6337539d | ||
![]() |
c7fec10bd7 | ||
![]() |
17fac880bf | ||
![]() |
928b5fdf50 | ||
![]() |
805cde674d | ||
![]() |
81895940e6 | ||
![]() |
f7393a5ab8 | ||
![]() |
9a8f5a80e4 | ||
![]() |
a7486a8d87 | ||
![]() |
c622e1439c | ||
![]() |
93cc3f58b1 | ||
![]() |
5da5b179d5 | ||
![]() |
6a536d5588 | ||
![]() |
a0bce36aa1 | ||
![]() |
4665d9c405 | ||
![]() |
bda3300bb3 | ||
![]() |
2e86b05cab | ||
![]() |
90b87abb11 | ||
![]() |
9cbb4a2c4c | ||
![]() |
61778f6136 | ||
![]() |
17be3e4a54 | ||
![]() |
1c03574424 | ||
![]() |
49e339ba8d | ||
![]() |
7983f7409b | ||
![]() |
42f1763db9 | ||
![]() |
a93144834c | ||
![]() |
e7c009c142 | ||
![]() |
e84104fe8d | ||
![]() |
d48aac6a2c | ||
![]() |
aa05fa649f | ||
![]() |
64f533fa47 | ||
![]() |
0b3ece1189 | ||
![]() |
ae4ab5ed31 | ||
![]() |
ccae6e596a | ||
![]() |
0c19eae916 | ||
![]() |
12dae4b9b7 | ||
![]() |
b7729fa019 | ||
![]() |
2c7bf34d09 | ||
![]() |
3aaa086ac8 | ||
![]() |
e0788d19d4 | ||
![]() |
a4c286bb34 | ||
![]() |
f043545144 | ||
![]() |
46d2e15b1f | ||
![]() |
c44f5375ab | ||
![]() |
4691b72bd5 | ||
![]() |
6d4f8d8963 | ||
![]() |
a42652f8e7 | ||
![]() |
75848477fb | ||
![]() |
0fd9909657 | ||
![]() |
b5c807fb4a | ||
![]() |
6af8d4210c | ||
![]() |
4a6ba1e808 | ||
![]() |
59ac1a08c8 | ||
![]() |
e83a36dfbf | ||
![]() |
c3632dce99 | ||
![]() |
deb1dcf6c7 | ||
![]() |
2b55e43e54 | ||
![]() |
a7ed82b39b | ||
![]() |
ef3a939880 | ||
![]() |
3bd303f204 | ||
![]() |
096aca63c5 | ||
![]() |
28b6a8841f | ||
![]() |
d210590d4d | ||
![]() |
07535aa2c0 | ||
![]() |
884a808813 | ||
![]() |
784786c00c | ||
![]() |
9985f5950d | ||
![]() |
fba0408cb3 | ||
![]() |
9df36b25da | ||
![]() |
481e6f6440 | ||
![]() |
16a811604b | ||
![]() |
81109100a9 | ||
![]() |
d7e1eb3e48 | ||
![]() |
dae5e9ee06 | ||
![]() |
99e491f8b5 | ||
![]() |
0da9bd2709 | ||
![]() |
0b6b4c23d2 | ||
![]() |
d4811c19b0 | ||
![]() |
6644f41e91 | ||
![]() |
496f448090 | ||
![]() |
141214122d | ||
![]() |
d95690d89c | ||
![]() |
425a4b7c57 | ||
![]() |
fd65bd5ae0 | ||
![]() |
a5d4ed98fd | ||
![]() |
4b1f916b99 | ||
![]() |
60308a2c0f | ||
![]() |
70cbf08b67 | ||
![]() |
ecf725b356 | ||
![]() |
0f43486537 | ||
![]() |
4b7de2ba5d | ||
![]() |
530e044762 | ||
![]() |
cc3bc2af11 | ||
![]() |
df5800b6c4 | ||
![]() |
8b42e5fb8f | ||
![]() |
474cc01d68 | ||
![]() |
c134822486 | ||
![]() |
b481e7a8f0 | ||
![]() |
63206aebcf | ||
![]() |
d5c98d0539 | ||
![]() |
c05cafa3df | ||
![]() |
0c43a15ce6 | ||
![]() |
7a4f21d340 | ||
![]() |
11f2209087 | ||
![]() |
656fea4dab | ||
![]() |
170ed7ba9b | ||
![]() |
5d76c5280d | ||
![]() |
81dcf2b547 | ||
![]() |
5741eb7b10 | ||
![]() |
9976d0f547 | ||
![]() |
acac787842 | ||
![]() |
45dc2499dc | ||
![]() |
8f6d2ac53c | ||
![]() |
fc9d848a77 | ||
![]() |
b3bb19a96d | ||
![]() |
e6a898e3ee | ||
![]() |
048f2ddcbf | ||
![]() |
373364afd1 | ||
![]() |
31b962b339 | ||
![]() |
557e4e7ffc | ||
![]() |
97a0091bbb | ||
![]() |
e910c89e0b | ||
![]() |
21b84596e7 | ||
![]() |
e9cb9f42a5 | ||
![]() |
48d3edd66f | ||
![]() |
1355eb493f | ||
![]() |
ab4c13e835 | ||
![]() |
faf51c7449 | ||
![]() |
072947e573 | ||
![]() |
8db800bfba | ||
![]() |
fe50774cb4 | ||
![]() |
5f8aaf236f | ||
![]() |
39324e642f | ||
![]() |
1f02cd45af | ||
![]() |
b07a68230d | ||
![]() |
2d2eed9594 | ||
![]() |
822a4580f4 | ||
![]() |
91f293d0c7 | ||
![]() |
40f2575b56 | ||
![]() |
45397a44e3 | ||
![]() |
dccada95aa | ||
![]() |
2c6409fdd8 | ||
![]() |
380e0c9cad | ||
![]() |
783f97ff32 | ||
![]() |
ca6ba30a72 | ||
![]() |
158aaef78c | ||
![]() |
019b6f67b2 | ||
![]() |
339b820520 | ||
![]() |
fc209e1c51 | ||
![]() |
5acc3b2b7b | ||
![]() |
c0e2ecb825 | ||
![]() |
78900720fd | ||
![]() |
142128740d | ||
![]() |
c67c3d375b | ||
![]() |
ac1b488170 | ||
![]() |
b5b4e93857 | ||
![]() |
1f942bb17e | ||
![]() |
5c10bd3d8c | ||
![]() |
0fbe150303 | ||
![]() |
0b4065b50c | ||
![]() |
b04fee4ff7 | ||
![]() |
75402109e9 | ||
![]() |
ddc60da839 | ||
![]() |
fa657fef70 | ||
![]() |
eb78ca1c1a | ||
![]() |
bb20093b24 | ||
![]() |
d28a50e176 | ||
![]() |
8808fffc2f | ||
![]() |
9f387f525c | ||
![]() |
807ba71c89 | ||
![]() |
c7662e4f36 | ||
![]() |
5439507f5e | ||
![]() |
73cb6fd89f | ||
![]() |
8ca082892a | ||
![]() |
9c1e1d1fee | ||
![]() |
d538451adb |
@@ -11,7 +11,8 @@ charset = utf-8
|
||||
trim_trailing_whitespace = true
|
||||
insert_final_newline = true
|
||||
|
||||
[{*.yaml,*.yml}] # To match GitHub Actions formatting
|
||||
# To match GitHub Actions formatting
|
||||
[*.{yaml,yml}]
|
||||
indent_size = 2
|
||||
|
||||
[*.md]
|
||||
|
2
.github/ISSUE_TEMPLATE/config.yml
vendored
2
.github/ISSUE_TEMPLATE/config.yml
vendored
@@ -1,7 +1,7 @@
|
||||
blank_issues_enabled: false
|
||||
contact_links:
|
||||
- name: QMK Discord
|
||||
url: https://discord.gg/Uq7gcHh
|
||||
url: https://discord.gg/qmk
|
||||
about: Ask questions, discuss issues and features. Chill.
|
||||
- name: OLKB Subreddit
|
||||
url: https://www.reddit.com/r/olkb
|
||||
|
3
.github/PULL_REQUEST_TEMPLATE.md
vendored
3
.github/PULL_REQUEST_TEMPLATE.md
vendored
@@ -1,6 +1,5 @@
|
||||
<!--- Provide a general summary of your changes in the title above. -->
|
||||
|
||||
<!--- This template is entirely optional and can be removed, but is here to help both you and us. -->
|
||||
<!--- Anything on lines wrapped in comments like these will not show up in the final text. -->
|
||||
|
||||
## Description
|
||||
@@ -15,7 +14,7 @@
|
||||
- [ ] New feature
|
||||
- [ ] Enhancement/optimization
|
||||
- [ ] Keyboard (addition or update)
|
||||
- [ ] Keymap/layout/userspace (addition or update)
|
||||
- [ ] Keymap/layout (addition or update)
|
||||
- [ ] Documentation
|
||||
|
||||
## Issues Fixed or Closed by This PR
|
||||
|
16
.github/labeler.yml
vendored
16
.github/labeler.yml
vendored
@@ -11,15 +11,15 @@ core:
|
||||
- Makefile
|
||||
- '*.mk'
|
||||
dependencies:
|
||||
- all:
|
||||
- changed-files:
|
||||
- any-glob-to-any-file: lib/**
|
||||
- all-globs-to-all-files: '!lib/python/**'
|
||||
- changed-files:
|
||||
- all-globs-to-any-file:
|
||||
- lib/**
|
||||
- '!lib/python/**'
|
||||
keyboard:
|
||||
- all:
|
||||
- changed-files:
|
||||
- any-glob-to-any-file: keyboards/**
|
||||
- all-globs-to-all-files: '!keyboards/**/keymaps/**'
|
||||
- changed-files:
|
||||
- all-globs-to-any-file:
|
||||
- keyboards/**
|
||||
- '!keyboards/**/keymaps/**'
|
||||
keymap:
|
||||
- changed-files:
|
||||
- any-glob-to-any-file:
|
||||
|
2
.github/workflows/docs.yml
vendored
2
.github/workflows/docs.yml
vendored
@@ -56,7 +56,7 @@ jobs:
|
||||
|
||||
- name: Deploy
|
||||
if: ${{ github.event_name == 'push' && github.repository == 'qmk/qmk_firmware' }}
|
||||
uses: JamesIves/github-pages-deploy-action@v4.6.3
|
||||
uses: JamesIves/github-pages-deploy-action@v4.7.2
|
||||
with:
|
||||
token: ${{ secrets.GITHUB_TOKEN }}
|
||||
branch: gh-pages
|
||||
|
2
.github/workflows/format.yml
vendored
2
.github/workflows/format.yml
vendored
@@ -35,7 +35,7 @@ jobs:
|
||||
|
||||
- name: Get changed files
|
||||
id: file_changes
|
||||
uses: tj-actions/changed-files@v44
|
||||
uses: tj-actions/changed-files@v45
|
||||
with:
|
||||
use_rest_api: true
|
||||
|
||||
|
2
.github/workflows/format_push.yml
vendored
2
.github/workflows/format_push.yml
vendored
@@ -47,7 +47,7 @@ jobs:
|
||||
git config user.email 'hello@qmk.fm'
|
||||
|
||||
- name: Create Pull Request
|
||||
uses: peter-evans/create-pull-request@v6
|
||||
uses: peter-evans/create-pull-request@v7
|
||||
if: ${{ github.repository == 'qmk/qmk_firmware'}}
|
||||
with:
|
||||
token: ${{ secrets.QMK_BOT_TOKEN }}
|
||||
|
2
.github/workflows/lint.yml
vendored
2
.github/workflows/lint.yml
vendored
@@ -27,7 +27,7 @@ jobs:
|
||||
|
||||
- name: Get changed files
|
||||
id: file_changes
|
||||
uses: tj-actions/changed-files@v44
|
||||
uses: tj-actions/changed-files@v45
|
||||
with:
|
||||
use_rest_api: true
|
||||
|
||||
|
2
.github/workflows/regen_push.yml
vendored
2
.github/workflows/regen_push.yml
vendored
@@ -34,7 +34,7 @@ jobs:
|
||||
git config user.email 'hello@qmk.fm'
|
||||
|
||||
- name: Create Pull Request
|
||||
uses: peter-evans/create-pull-request@v6
|
||||
uses: peter-evans/create-pull-request@v7
|
||||
if: ${{ github.repository == 'qmk/qmk_firmware'}}
|
||||
with:
|
||||
token: ${{ secrets.QMK_BOT_TOKEN }}
|
||||
|
1
.gitignore
vendored
1
.gitignore
vendored
@@ -118,4 +118,5 @@ compile_commands.json
|
||||
|
||||
# VIA(L) files that don't belong in QMK repo
|
||||
via*.json
|
||||
/keyboards/**/keymaps/via/*
|
||||
/keyboards/**/keymaps/vial/*
|
||||
|
2
Doxyfile
2
Doxyfile
@@ -145,7 +145,7 @@ FILE_PATTERNS = *.c \
|
||||
RECURSIVE = YES
|
||||
EXCLUDE =
|
||||
EXCLUDE_SYMLINKS = NO
|
||||
EXCLUDE_PATTERNS = */protocol/arm_atsam/*
|
||||
EXCLUDE_PATTERNS =
|
||||
EXCLUDE_SYMBOLS =
|
||||
EXAMPLE_PATH =
|
||||
EXAMPLE_PATTERNS = *
|
||||
|
@@ -21,8 +21,10 @@ $(TEST_OUTPUT)_SRC := \
|
||||
$(SRC) \
|
||||
$(QUANTUM_PATH)/keymap_introspection.c \
|
||||
tests/test_common/matrix.c \
|
||||
tests/test_common/pointing_device_driver.c \
|
||||
tests/test_common/test_driver.cpp \
|
||||
tests/test_common/keyboard_report_util.cpp \
|
||||
tests/test_common/mouse_report_util.cpp \
|
||||
tests/test_common/keycode_util.cpp \
|
||||
tests/test_common/keycode_table.cpp \
|
||||
tests/test_common/test_fixture.cpp \
|
||||
|
@@ -34,10 +34,13 @@ ifeq ($(strip $(DUMP_CI_METADATA)),yes)
|
||||
endif
|
||||
|
||||
# Force expansion
|
||||
TARGET := $(TARGET)
|
||||
override TARGET := $(TARGET)
|
||||
|
||||
ifneq ($(FORCE_LAYOUT),)
|
||||
TARGET := $(TARGET)_$(FORCE_LAYOUT)
|
||||
override TARGET := $(TARGET)_$(FORCE_LAYOUT)
|
||||
endif
|
||||
ifneq ($(CONVERT_TO),)
|
||||
override TARGET := $(TARGET)_$(CONVERT_TO)
|
||||
endif
|
||||
|
||||
# Object files and generated keymap directory
|
||||
@@ -58,9 +61,6 @@ ifdef SKIP_GIT
|
||||
VERSION_H_FLAGS += --skip-git
|
||||
endif
|
||||
|
||||
# Generate the board's version.h file.
|
||||
$(shell $(QMK_BIN) generate-version-h $(VERSION_H_FLAGS) -q -o $(INTERMEDIATE_OUTPUT)/src/version.h)
|
||||
|
||||
# Determine which subfolders exist.
|
||||
KEYBOARD_FOLDER_PATH_1 := $(KEYBOARD)
|
||||
KEYBOARD_FOLDER_PATH_2 := $(patsubst %/,%,$(dir $(KEYBOARD_FOLDER_PATH_1)))
|
||||
@@ -186,7 +186,10 @@ endif
|
||||
# Have we found a keymap.json?
|
||||
ifneq ("$(wildcard $(KEYMAP_JSON))", "")
|
||||
ifneq ("$(wildcard $(KEYMAP_C))", "")
|
||||
$(call WARNING_MESSAGE,Keymap is specified as both keymap.json and keymap.c -- keymap.json file wins.)
|
||||
# Allow a separately-found keymap.c next to keymap.json -- the keymap.c
|
||||
# generator will include the other keymap.c in the process, if supplied.
|
||||
OTHER_KEYMAP_C := $(KEYMAP_C)
|
||||
OPT_DEFS += -DOTHER_KEYMAP_C=\"$(OTHER_KEYMAP_C)\"
|
||||
endif
|
||||
|
||||
KEYMAP_PATH := $(KEYMAP_JSON_PATH)
|
||||
@@ -194,8 +197,10 @@ ifneq ("$(wildcard $(KEYMAP_JSON))", "")
|
||||
KEYMAP_C := $(INTERMEDIATE_OUTPUT)/src/keymap.c
|
||||
KEYMAP_H := $(INTERMEDIATE_OUTPUT)/src/config.h
|
||||
|
||||
# Load the keymap-level rules.mk if exists
|
||||
-include $(KEYMAP_PATH)/rules.mk
|
||||
ifeq ($(OTHER_KEYMAP_C),)
|
||||
# Load the keymap-level rules.mk if exists (and we havent already loaded it for keymap.c)
|
||||
-include $(KEYMAP_PATH)/rules.mk
|
||||
endif
|
||||
|
||||
# Load any rules.mk content from keymap.json
|
||||
INFO_RULES_MK = $(shell $(QMK_BIN) generate-rules-mk --quiet --escape --output $(INTERMEDIATE_OUTPUT)/src/rules.mk $(KEYMAP_JSON))
|
||||
@@ -223,6 +228,9 @@ endif
|
||||
|
||||
include $(BUILDDEFS_PATH)/converters.mk
|
||||
|
||||
# Generate the board's version.h file.
|
||||
$(shell $(QMK_BIN) generate-version-h $(VERSION_H_FLAGS) -q -o $(INTERMEDIATE_OUTPUT)/src/version.h)
|
||||
|
||||
MCU_ORIG := $(MCU)
|
||||
include $(wildcard $(PLATFORM_PATH)/*/mcu_selection.mk)
|
||||
|
||||
|
@@ -28,6 +28,7 @@ QUANTUM_SRC += \
|
||||
$(QUANTUM_DIR)/sync_timer.c \
|
||||
$(QUANTUM_DIR)/logging/debug.c \
|
||||
$(QUANTUM_DIR)/logging/sendchar.c \
|
||||
$(QUANTUM_DIR)/process_keycode/process_default_layer.c \
|
||||
|
||||
VPATH += $(QUANTUM_DIR)/logging
|
||||
# Fall back to lib/printf if there is no platform provided print
|
||||
@@ -129,13 +130,13 @@ ifeq ($(strip $(POINTING_DEVICE_ENABLE)), yes)
|
||||
MOUSE_ENABLE := yes
|
||||
VPATH += $(QUANTUM_DIR)/pointing_device
|
||||
SRC += $(QUANTUM_DIR)/pointing_device/pointing_device.c
|
||||
SRC += $(QUANTUM_DIR)/pointing_device/pointing_device_drivers.c
|
||||
SRC += $(QUANTUM_DIR)/pointing_device/pointing_device_auto_mouse.c
|
||||
ifneq ($(strip $(POINTING_DEVICE_DRIVER)), custom)
|
||||
SRC += drivers/sensors/$(strip $(POINTING_DEVICE_DRIVER)).c
|
||||
OPT_DEFS += -DPOINTING_DEVICE_DRIVER_$(strip $(shell echo $(POINTING_DEVICE_DRIVER) | tr '[:lower:]' '[:upper:]'))
|
||||
endif
|
||||
OPT_DEFS += -DPOINTING_DEVICE_DRIVER_$(strip $(POINTING_DEVICE_DRIVER))
|
||||
OPT_DEFS += -DPOINTING_DEVICE_DRIVER_NAME=$(strip $(POINTING_DEVICE_DRIVER))
|
||||
ifeq ($(strip $(POINTING_DEVICE_DRIVER)), adns9800)
|
||||
SPI_DRIVER_REQUIRED = yes
|
||||
else ifeq ($(strip $(POINTING_DEVICE_DRIVER)), analog_joystick)
|
||||
@@ -215,7 +216,7 @@ else
|
||||
COMMON_VPATH += $(PLATFORM_PATH)/$(PLATFORM_KEY)/$(DRIVER_DIR)/flash
|
||||
COMMON_VPATH += $(DRIVER_PATH)/flash
|
||||
SRC += eeprom_driver.c eeprom_legacy_emulated_flash.c legacy_flash_ops.c
|
||||
else ifneq ($(filter $(MCU_SERIES),STM32F1xx STM32F3xx STM32F4xx STM32L4xx STM32G4xx WB32F3G71xx WB32FQ95xx GD32VF103),)
|
||||
else ifneq ($(filter $(MCU_SERIES),STM32F1xx STM32F3xx STM32F4xx STM32L4xx STM32G4xx WB32F3G71xx WB32FQ95xx AT32F415 GD32VF103),)
|
||||
# Wear-leveling EEPROM implementation, backed by MCU flash
|
||||
OPT_DEFS += -DEEPROM_DRIVER -DEEPROM_WEAR_LEVELING
|
||||
SRC += eeprom_driver.c eeprom_wear_leveling.c
|
||||
@@ -238,10 +239,6 @@ else
|
||||
OPT_DEFS += -DEEPROM_DRIVER -DEEPROM_TRANSIENT
|
||||
SRC += eeprom_driver.c eeprom_transient.c
|
||||
endif
|
||||
else ifeq ($(PLATFORM),ARM_ATSAM)
|
||||
# arm_atsam EEPROM
|
||||
OPT_DEFS += -DEEPROM_SAMD
|
||||
SRC += eeprom_samd.c
|
||||
else ifeq ($(PLATFORM),TEST)
|
||||
# Test harness "EEPROM"
|
||||
OPT_DEFS += -DEEPROM_TEST_HARNESS
|
||||
@@ -310,11 +307,11 @@ ifeq ($(strip $(RGBLIGHT_ENABLE)), yes)
|
||||
POST_CONFIG_H += $(QUANTUM_DIR)/rgblight/rgblight_post_config.h
|
||||
OPT_DEFS += -DRGBLIGHT_ENABLE
|
||||
OPT_DEFS += -DRGBLIGHT_$(strip $(shell echo $(RGBLIGHT_DRIVER) | tr '[:lower:]' '[:upper:]'))
|
||||
SRC += $(QUANTUM_DIR)/process_keycode/process_underglow.c
|
||||
SRC += $(QUANTUM_DIR)/color.c
|
||||
SRC += $(QUANTUM_DIR)/rgblight/rgblight.c
|
||||
SRC += $(QUANTUM_DIR)/rgblight/rgblight_drivers.c
|
||||
CIE1931_CURVE := yes
|
||||
RGB_KEYCODES_ENABLE := yes
|
||||
endif
|
||||
|
||||
ifeq ($(strip $(RGBLIGHT_DRIVER)), ws2812)
|
||||
@@ -436,6 +433,13 @@ ifeq ($(strip $(LED_MATRIX_ENABLE)), yes)
|
||||
SRC += snled27351-mono.c
|
||||
endif
|
||||
|
||||
ifeq ($(strip $(LED_MATRIX_CUSTOM_KB)), yes)
|
||||
OPT_DEFS += -DLED_MATRIX_CUSTOM_KB
|
||||
endif
|
||||
|
||||
ifeq ($(strip $(LED_MATRIX_CUSTOM_USER)), yes)
|
||||
OPT_DEFS += -DLED_MATRIX_CUSTOM_USER
|
||||
endif
|
||||
endif
|
||||
|
||||
# Deprecated driver names - do not use
|
||||
@@ -460,12 +464,16 @@ ifeq ($(strip $(RGB_MATRIX_ENABLE)), yes)
|
||||
COMMON_VPATH += $(QUANTUM_DIR)/rgb_matrix/animations
|
||||
COMMON_VPATH += $(QUANTUM_DIR)/rgb_matrix/animations/runners
|
||||
POST_CONFIG_H += $(QUANTUM_DIR)/rgb_matrix/post_config.h
|
||||
|
||||
# TODO: Remove this
|
||||
SRC += $(QUANTUM_DIR)/process_keycode/process_underglow.c
|
||||
|
||||
SRC += $(QUANTUM_DIR)/process_keycode/process_rgb_matrix.c
|
||||
SRC += $(QUANTUM_DIR)/color.c
|
||||
SRC += $(QUANTUM_DIR)/rgb_matrix/rgb_matrix.c
|
||||
SRC += $(QUANTUM_DIR)/rgb_matrix/rgb_matrix_drivers.c
|
||||
LIB8TION_ENABLE := yes
|
||||
CIE1931_CURVE := yes
|
||||
RGB_KEYCODES_ENABLE := yes
|
||||
|
||||
ifeq ($(strip $(RGB_MATRIX_DRIVER)), aw20216s)
|
||||
SPI_DRIVER_REQUIRED = yes
|
||||
@@ -568,10 +576,6 @@ ifeq ($(strip $(RGB_MATRIX_ENABLE)), yes)
|
||||
endif
|
||||
endif
|
||||
|
||||
ifeq ($(strip $(RGB_KEYCODES_ENABLE)), yes)
|
||||
SRC += $(QUANTUM_DIR)/process_keycode/process_rgb.c
|
||||
endif
|
||||
|
||||
VARIABLE_TRACE ?= no
|
||||
ifneq ($(strip $(VARIABLE_TRACE)),no)
|
||||
SRC += $(QUANTUM_DIR)/variable_trace.c
|
||||
@@ -881,7 +885,7 @@ ifeq ($(strip $(BLUETOOTH_ENABLE)), yes)
|
||||
OPT_DEFS += -DBLUETOOTH_$(strip $(shell echo $(BLUETOOTH_DRIVER) | tr '[:lower:]' '[:upper:]'))
|
||||
NO_USB_STARTUP_CHECK := yes
|
||||
COMMON_VPATH += $(DRIVER_PATH)/bluetooth
|
||||
SRC += outputselect.c
|
||||
SRC += outputselect.c process_connection.c
|
||||
|
||||
ifeq ($(strip $(BLUETOOTH_DRIVER)), bluefruit_le)
|
||||
SPI_DRIVER_REQUIRED = yes
|
||||
@@ -936,7 +940,7 @@ ifeq ($(strip $(WS2812_DRIVER_REQUIRED)), yes)
|
||||
|
||||
OPT_DEFS += -DWS2812_$(strip $(shell echo $(WS2812_DRIVER) | tr '[:lower:]' '[:upper:]'))
|
||||
|
||||
SRC += ws2812_$(strip $(WS2812_DRIVER)).c
|
||||
SRC += ws2812.c ws2812_$(strip $(WS2812_DRIVER)).c
|
||||
|
||||
ifeq ($(strip $(PLATFORM)), CHIBIOS)
|
||||
ifeq ($(strip $(WS2812_DRIVER)), pwm)
|
||||
|
@@ -43,25 +43,25 @@ ifneq ($(USE_CCACHE),no)
|
||||
CC_PREFIX ?= ccache
|
||||
endif
|
||||
|
||||
#---------------- Debug Options ----------------
|
||||
|
||||
DEBUG_ENABLE ?= no
|
||||
ifeq ($(strip $(DEBUG_ENABLE)),yes)
|
||||
CFLAGS += -ggdb3
|
||||
CXXFLAGS += -ggdb3
|
||||
ASFLAGS += -ggdb3
|
||||
# Create a map file when debugging
|
||||
LDFLAGS += -Wl,-Map=$(BUILD_DIR)/$(TARGET).map,--cref
|
||||
endif
|
||||
|
||||
|
||||
#---------------- C Compiler Options ----------------
|
||||
|
||||
ifeq ($(strip $(LTO_ENABLE)), yes)
|
||||
ifeq ($(PLATFORM),ARM_ATSAM)
|
||||
$(info Enabling LTO on arm_atsam-targeting boards is known to have a high likelihood of failure.)
|
||||
$(info If unsure, set LTO_ENABLE = no.)
|
||||
endif
|
||||
CDEFS += -flto
|
||||
CDEFS += -DLTO_ENABLE
|
||||
endif
|
||||
|
||||
DEBUG_ENABLE ?= yes
|
||||
ifeq ($(strip $(SKIP_DEBUG_INFO)),yes)
|
||||
DEBUG_ENABLE=no
|
||||
endif
|
||||
|
||||
ifeq ($(strip $(DEBUG_ENABLE)),yes)
|
||||
CFLAGS += -g$(DEBUG)
|
||||
endif
|
||||
CFLAGS += $(CDEFS)
|
||||
CFLAGS += -O$(OPT)
|
||||
# add color
|
||||
@@ -83,9 +83,6 @@ CFLAGS += -fcommon
|
||||
|
||||
#---------------- C++ Compiler Options ----------------
|
||||
|
||||
ifeq ($(strip $(DEBUG_ENABLE)),yes)
|
||||
CXXFLAGS += -g$(DEBUG)
|
||||
endif
|
||||
CXXFLAGS += $(CXXDEFS)
|
||||
CXXFLAGS += -O$(OPT)
|
||||
# to suppress "warning: only initialized variables can be placed into program memory area"
|
||||
@@ -106,14 +103,10 @@ endif
|
||||
|
||||
#---------------- Linker Options ----------------
|
||||
|
||||
CREATE_MAP ?= yes
|
||||
ifeq ($(CREATE_MAP),yes)
|
||||
LDFLAGS += -Wl,-Map=$(BUILD_DIR)/$(TARGET).map,--cref
|
||||
endif
|
||||
ifeq ($(VERBOSE_LD_CMD),yes)
|
||||
LDFLAGS += -v
|
||||
endif
|
||||
#LDFLAGS += -Wl,--relax
|
||||
|
||||
LDFLAGS += $(EXTMEMOPTS)
|
||||
LDFLAGS += $(patsubst %,-L%,$(EXTRALIBDIRS))
|
||||
LDFLAGS += -lm
|
||||
@@ -126,15 +119,11 @@ ADHLNS_ENABLE ?= no
|
||||
ifeq ($(ADHLNS_ENABLE),yes)
|
||||
# Avoid "Options to '-Xassembler' do not match" - only specify assembler options at LTO link time
|
||||
ifeq ($(strip $(LTO_ENABLE)), yes)
|
||||
LDFLAGS += -Wa,-adhlns=$(BUILD_DIR)/$(TARGET).lst
|
||||
LDFLAGS += -Wa,-adhlns=$(BUILD_DIR)/$(TARGET).lst
|
||||
else
|
||||
CFLAGS += -Wa,-adhlns=$(@:%.o=%.lst)
|
||||
CFLAGS += -Wa,-adhlns=$(@:%.o=%.lst)
|
||||
CXXFLAGS += -Wa,-adhlns=$(@:%.o=%.lst)
|
||||
ifeq ($(strip $(DEBUG_ENABLE)),yes)
|
||||
ASFLAGS = -Wa,-adhlns=$(@:%.o=%.lst),-gstabs,--listing-cont-lines=100
|
||||
else
|
||||
ASFLAGS = -Wa,-adhlns=$(@:%.o=%.lst),--listing-cont-lines=100
|
||||
endif
|
||||
ASFLAGS += -Wa,-adhlns=$(@:%.o=%.lst),--listing-cont-lines=100
|
||||
endif
|
||||
endif
|
||||
|
||||
|
@@ -32,9 +32,6 @@ ifneq ($(CONVERT_TO),)
|
||||
|
||||
PLATFORM_KEY = $(shell echo $(CONVERTER) | cut -d "/" -f2)
|
||||
|
||||
# force setting as value can be from environment
|
||||
override TARGET := $(TARGET)_$(CONVERT_TO)
|
||||
|
||||
# Configure any defaults
|
||||
OPT_DEFS += -DCONVERT_TO_$(shell echo $(CONVERT_TO) | tr '[:lower:]' '[:upper:]')
|
||||
OPT_DEFS += -DCONVERTER_TARGET=\"$(CONVERT_TO)\"
|
||||
|
@@ -39,8 +39,15 @@ export default defineConfig(({ mode }) => {
|
||||
provider: "local",
|
||||
},
|
||||
|
||||
editLink: {
|
||||
pattern: 'https://github.com/qmk/qmk_firmware/edit/master/docs/:path'
|
||||
},
|
||||
lastUpdated: true,
|
||||
|
||||
sidebar: sidebar,
|
||||
|
||||
externalLinkIcon: true,
|
||||
|
||||
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" },
|
||||
|
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"license": "GPL-2.0-or-later",
|
||||
"devDependencies": {
|
||||
"vite": "^5.2.10",
|
||||
"vite": "^5.2.14",
|
||||
"vitepress": "^1.1.0",
|
||||
"vitepress-plugin-tabs": "^0.5.0",
|
||||
"vue": "^3.4.24"
|
||||
|
@@ -298,85 +298,85 @@
|
||||
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-arm-eabi@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-android-arm-eabi/-/rollup-android-arm-eabi-4.22.4.tgz#8b613b9725e8f9479d142970b106b6ae878610d5"
|
||||
integrity sha512-Fxamp4aEZnfPOcGA8KSNEohV8hX7zVHOemC8jVBoBUHu5zpJK/Eu3uJwt6BMgy9fkvzxDaurgj96F/NiLukF2w==
|
||||
|
||||
"@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-android-arm64@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-android-arm64/-/rollup-android-arm64-4.22.4.tgz#654ca1049189132ff602bfcf8df14c18da1f15fb"
|
||||
integrity sha512-VXoK5UMrgECLYaMuGuVTOx5kcuap1Jm8g/M83RnCHBKOqvPPmROFJGQaZhGccnsFtfXQ3XYa4/jMCJvZnbJBdA==
|
||||
|
||||
"@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-arm64@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-darwin-arm64/-/rollup-darwin-arm64-4.22.4.tgz#6d241d099d1518ef0c2205d96b3fa52e0fe1954b"
|
||||
integrity sha512-xMM9ORBqu81jyMKCDP+SZDhnX2QEVQzTcC6G18KlTQEzWK8r/oNZtKuZaCcHhnsa6fEeOBionoyl5JsAbE/36Q==
|
||||
|
||||
"@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-darwin-x64@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-darwin-x64/-/rollup-darwin-x64-4.22.4.tgz#42bd19d292a57ee11734c980c4650de26b457791"
|
||||
integrity sha512-aJJyYKQwbHuhTUrjWjxEvGnNNBCnmpHDvrb8JFDbeSH3m2XdHcxDd3jthAzvmoI8w/kSjd2y0udT+4okADsZIw==
|
||||
|
||||
"@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-gnueabihf@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-arm-gnueabihf/-/rollup-linux-arm-gnueabihf-4.22.4.tgz#f23555ee3d8fe941c5c5fd458cd22b65eb1c2232"
|
||||
integrity sha512-j63YtCIRAzbO+gC2L9dWXRh5BFetsv0j0va0Wi9epXDgU/XUi5dJKo4USTttVyK7fGw2nPWK0PbAvyliz50SCQ==
|
||||
|
||||
"@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-arm-musleabihf@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-arm-musleabihf/-/rollup-linux-arm-musleabihf-4.22.4.tgz#f3bbd1ae2420f5539d40ac1fde2b38da67779baa"
|
||||
integrity sha512-dJnWUgwWBX1YBRsuKKMOlXCzh2Wu1mlHzv20TpqEsfdZLb3WoJW2kIEsGwLkroYf24IrPAvOT/ZQ2OYMV6vlrg==
|
||||
|
||||
"@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-gnu@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-arm64-gnu/-/rollup-linux-arm64-gnu-4.22.4.tgz#7abe900120113e08a1f90afb84c7c28774054d15"
|
||||
integrity sha512-AdPRoNi3NKVLolCN/Sp4F4N1d98c4SBnHMKoLuiG6RXgoZ4sllseuGioszumnPGmPM2O7qaAX/IJdeDU8f26Aw==
|
||||
|
||||
"@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-arm64-musl@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-arm64-musl/-/rollup-linux-arm64-musl-4.22.4.tgz#9e655285c8175cd44f57d6a1e8e5dedfbba1d820"
|
||||
integrity sha512-Gl0AxBtDg8uoAn5CCqQDMqAx22Wx22pjDOjBdmG0VIWX3qUBHzYmOKh8KXHL4UpogfJ14G4wk16EQogF+v8hmA==
|
||||
|
||||
"@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-powerpc64le-gnu@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-powerpc64le-gnu/-/rollup-linux-powerpc64le-gnu-4.22.4.tgz#9a79ae6c9e9d8fe83d49e2712ecf4302db5bef5e"
|
||||
integrity sha512-3aVCK9xfWW1oGQpTsYJJPF6bfpWfhbRnhdlyhak2ZiyFLDaayz0EP5j9V1RVLAAxlmWKTDfS9wyRyY3hvhPoOg==
|
||||
|
||||
"@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-riscv64-gnu@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-riscv64-gnu/-/rollup-linux-riscv64-gnu-4.22.4.tgz#67ac70eca4ace8e2942fabca95164e8874ab8128"
|
||||
integrity sha512-ePYIir6VYnhgv2C5Xe9u+ico4t8sZWXschR6fMgoPUK31yQu7hTEJb7bCqivHECwIClJfKgE7zYsh1qTP3WHUA==
|
||||
|
||||
"@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-s390x-gnu@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-s390x-gnu/-/rollup-linux-s390x-gnu-4.22.4.tgz#9f883a7440f51a22ed7f99e1d070bd84ea5005fc"
|
||||
integrity sha512-GqFJ9wLlbB9daxhVlrTe61vJtEY99/xB3C8e4ULVsVfflcpmR6c8UZXjtkMA6FhNONhj2eA5Tk9uAVw5orEs4Q==
|
||||
|
||||
"@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-gnu@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-x64-gnu/-/rollup-linux-x64-gnu-4.22.4.tgz#70116ae6c577fe367f58559e2cffb5641a1dd9d0"
|
||||
integrity sha512-87v0ol2sH9GE3cLQLNEy0K/R0pz1nvg76o8M5nhMR0+Q+BBGLnb35P0fVz4CQxHYXaAOhE8HhlkaZfsdUOlHwg==
|
||||
|
||||
"@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-linux-x64-musl@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-linux-x64-musl/-/rollup-linux-x64-musl-4.22.4.tgz#f473f88219feb07b0b98b53a7923be716d1d182f"
|
||||
integrity sha512-UV6FZMUgePDZrFjrNGIWzDo/vABebuXBhJEqrHxrGiU6HikPy0Z3LfdtciIttEUQfuDdCn8fqh7wiFJjCNwO+g==
|
||||
|
||||
"@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-arm64-msvc@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-win32-arm64-msvc/-/rollup-win32-arm64-msvc-4.22.4.tgz#4349482d17f5d1c58604d1c8900540d676f420e0"
|
||||
integrity sha512-BjI+NVVEGAXjGWYHz/vv0pBqfGoUH0IGZ0cICTn7kB9PyjrATSkX+8WkguNjWoj2qSr1im/+tTGRaY+4/PdcQw==
|
||||
|
||||
"@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-ia32-msvc@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-win32-ia32-msvc/-/rollup-win32-ia32-msvc-4.22.4.tgz#a6fc39a15db618040ec3c2a24c1e26cb5f4d7422"
|
||||
integrity sha512-SiWG/1TuUdPvYmzmYnmd3IEifzR61Tragkbx9D3+R8mzQqDBz8v+BvZNDlkiTtI9T15KYZhP0ehn3Dld4n9J5g==
|
||||
|
||||
"@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==
|
||||
"@rollup/rollup-win32-x64-msvc@4.22.4":
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/@rollup/rollup-win32-x64-msvc/-/rollup-win32-x64-msvc-4.22.4.tgz#3dd5d53e900df2a40841882c02e56f866c04d202"
|
||||
integrity sha512-j8pPKp53/lq9lMXN57S8cFz0MynJk8OWNuUnXct/9KCpKU7DgU3bYMJhwWmcqC0UU29p8Lr0/7KEVcaM6bf47Q==
|
||||
|
||||
"@shikijs/core@1.3.0", "@shikijs/core@^1.3.0":
|
||||
version "1.3.0"
|
||||
@@ -697,28 +697,28 @@ rfdc@^1.3.1:
|
||||
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==
|
||||
version "4.22.4"
|
||||
resolved "https://registry.yarnpkg.com/rollup/-/rollup-4.22.4.tgz#4135a6446671cd2a2453e1ad42a45d5973ec3a0f"
|
||||
integrity sha512-vD8HJ5raRcWOyymsR6Z3o6+RzfEPCnVLMFJ6vRslO1jt4LO6dUo5Qnpg7y4RkZFM2DMe3WUirkI5c16onjrc6A==
|
||||
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"
|
||||
"@rollup/rollup-android-arm-eabi" "4.22.4"
|
||||
"@rollup/rollup-android-arm64" "4.22.4"
|
||||
"@rollup/rollup-darwin-arm64" "4.22.4"
|
||||
"@rollup/rollup-darwin-x64" "4.22.4"
|
||||
"@rollup/rollup-linux-arm-gnueabihf" "4.22.4"
|
||||
"@rollup/rollup-linux-arm-musleabihf" "4.22.4"
|
||||
"@rollup/rollup-linux-arm64-gnu" "4.22.4"
|
||||
"@rollup/rollup-linux-arm64-musl" "4.22.4"
|
||||
"@rollup/rollup-linux-powerpc64le-gnu" "4.22.4"
|
||||
"@rollup/rollup-linux-riscv64-gnu" "4.22.4"
|
||||
"@rollup/rollup-linux-s390x-gnu" "4.22.4"
|
||||
"@rollup/rollup-linux-x64-gnu" "4.22.4"
|
||||
"@rollup/rollup-linux-x64-musl" "4.22.4"
|
||||
"@rollup/rollup-win32-arm64-msvc" "4.22.4"
|
||||
"@rollup/rollup-win32-ia32-msvc" "4.22.4"
|
||||
"@rollup/rollup-win32-x64-msvc" "4.22.4"
|
||||
fsevents "~2.3.2"
|
||||
|
||||
shiki@1.3.0, shiki@^1.3.0:
|
||||
@@ -743,10 +743,10 @@ tabbable@^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==
|
||||
vite@^5.2.14, vite@^5.2.9:
|
||||
version "5.2.14"
|
||||
resolved "https://registry.yarnpkg.com/vite/-/vite-5.2.14.tgz#fd5f60facf6b5f90ec7da6323c467a365d380c3d"
|
||||
integrity sha512-TFQLuwWLPms+NBNlh0D9LZQ+HXW471COABxw/9TEUBrjuHMo9BrYBPrN/SYAwIuVL+rLerycxiLT41t4f5MZpA==
|
||||
dependencies:
|
||||
esbuild "^0.20.1"
|
||||
postcss "^8.4.38"
|
||||
|
@@ -36,6 +36,7 @@ GENERIC_FEATURES = \
|
||||
HAPTIC \
|
||||
KEY_LOCK \
|
||||
KEY_OVERRIDE \
|
||||
LAYER_LOCK \
|
||||
LEADER \
|
||||
MAGIC \
|
||||
MOUSEKEY \
|
||||
|
@@ -67,7 +67,6 @@ OTHER_OPTION_NAMES = \
|
||||
PS2_DRIVER \
|
||||
RAW_ENABLE \
|
||||
SWAP_HANDS_ENABLE \
|
||||
RING_BUFFERED_6KRO_REPORT_ENABLE \
|
||||
WATCHDOG_ENABLE \
|
||||
ERGOINU \
|
||||
NO_USB_STARTUP_CHECK \
|
||||
|
@@ -1140,7 +1140,7 @@
|
||||
"0x00AE": {
|
||||
"group": "media",
|
||||
"key": "KC_MEDIA_PLAY_PAUSE",
|
||||
"label": "Mute",
|
||||
"label": "Play/Pause Track",
|
||||
"aliases": [
|
||||
"KC_MPLY"
|
||||
]
|
||||
|
@@ -84,7 +84,7 @@
|
||||
"group": "midi",
|
||||
"key": "QK_MIDI_NOTE_G_SHARP_0",
|
||||
"aliases": [
|
||||
"MI_Gs"
|
||||
"MI_Gs",
|
||||
"MI_Ab"
|
||||
]
|
||||
},
|
||||
@@ -99,7 +99,7 @@
|
||||
"group": "midi",
|
||||
"key": "QK_MIDI_NOTE_A_SHARP_0",
|
||||
"aliases": [
|
||||
"MI_As"
|
||||
"MI_As",
|
||||
"MI_Bb"
|
||||
]
|
||||
},
|
||||
|
@@ -2,131 +2,131 @@
|
||||
"keycodes": {
|
||||
"0x7E00": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_0",
|
||||
"key": "QK_KB_0"
|
||||
},
|
||||
"0x7E01": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_1",
|
||||
"key": "QK_KB_1"
|
||||
},
|
||||
"0x7E02": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_2",
|
||||
"key": "QK_KB_2"
|
||||
},
|
||||
"0x7E03": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_3",
|
||||
"key": "QK_KB_3"
|
||||
},
|
||||
"0x7E04": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_4",
|
||||
"key": "QK_KB_4"
|
||||
},
|
||||
"0x7E05": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_5",
|
||||
"key": "QK_KB_5"
|
||||
},
|
||||
"0x7E06": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_6",
|
||||
"key": "QK_KB_6"
|
||||
},
|
||||
"0x7E07": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_7",
|
||||
"key": "QK_KB_7"
|
||||
},
|
||||
"0x7E08": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_8",
|
||||
"key": "QK_KB_8"
|
||||
},
|
||||
"0x7E09": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_9",
|
||||
"key": "QK_KB_9"
|
||||
},
|
||||
"0x7E0A": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_10",
|
||||
"key": "QK_KB_10"
|
||||
},
|
||||
"0x7E0B": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_11",
|
||||
"key": "QK_KB_11"
|
||||
},
|
||||
"0x7E0C": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_12",
|
||||
"key": "QK_KB_12"
|
||||
},
|
||||
"0x7E0D": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_13",
|
||||
"key": "QK_KB_13"
|
||||
},
|
||||
"0x7E0E": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_14",
|
||||
"key": "QK_KB_14"
|
||||
},
|
||||
"0x7E0F": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_15",
|
||||
"key": "QK_KB_15"
|
||||
},
|
||||
"0x7E10": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_16",
|
||||
"key": "QK_KB_16"
|
||||
},
|
||||
"0x7E11": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_17",
|
||||
"key": "QK_KB_17"
|
||||
},
|
||||
"0x7E12": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_18",
|
||||
"key": "QK_KB_18"
|
||||
},
|
||||
"0x7E13": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_19",
|
||||
"key": "QK_KB_19"
|
||||
},
|
||||
"0x7E14": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_20",
|
||||
"key": "QK_KB_20"
|
||||
},
|
||||
"0x7E15": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_21",
|
||||
"key": "QK_KB_21"
|
||||
},
|
||||
"0x7E16": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_22",
|
||||
"key": "QK_KB_22"
|
||||
},
|
||||
"0x7E17": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_23",
|
||||
"key": "QK_KB_23"
|
||||
},
|
||||
"0x7E18": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_24",
|
||||
"key": "QK_KB_24"
|
||||
},
|
||||
"0x7E19": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_25",
|
||||
"key": "QK_KB_25"
|
||||
},
|
||||
"0x7E1A": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_26",
|
||||
},
|
||||
"key": "QK_KB_26"
|
||||
},
|
||||
"0x7E1B": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_27",
|
||||
"key": "QK_KB_27"
|
||||
},
|
||||
"0x7E1C": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_28",
|
||||
"key": "QK_KB_28"
|
||||
},
|
||||
"0x7E1D": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_29",
|
||||
"key": "QK_KB_29"
|
||||
},
|
||||
"0x7E1E": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_30",
|
||||
"key": "QK_KB_30"
|
||||
},
|
||||
"0x7E1F": {
|
||||
"group": "kb",
|
||||
"key": "QK_KB_31",
|
||||
},
|
||||
"key": "QK_KB_31"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
@@ -86,7 +86,7 @@
|
||||
"group": "midi",
|
||||
"key": "QK_MIDI_NOTE_G_SHARP_0",
|
||||
"aliases": [
|
||||
"MI_Gs"
|
||||
"MI_Gs",
|
||||
"MI_Ab"
|
||||
]
|
||||
},
|
||||
@@ -101,7 +101,7 @@
|
||||
"group": "midi",
|
||||
"key": "QK_MIDI_NOTE_A_SHARP_0",
|
||||
"aliases": [
|
||||
"MI_As"
|
||||
"MI_As",
|
||||
"MI_Bb"
|
||||
]
|
||||
},
|
||||
|
@@ -2,131 +2,131 @@
|
||||
"keycodes": {
|
||||
"0x7E40": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_0",
|
||||
"key": "QK_USER_0"
|
||||
},
|
||||
"0x7E41": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_1",
|
||||
"key": "QK_USER_1"
|
||||
},
|
||||
"0x7E42": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_2",
|
||||
"key": "QK_USER_2"
|
||||
},
|
||||
"0x7E43": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_3",
|
||||
"key": "QK_USER_3"
|
||||
},
|
||||
"0x7E44": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_4",
|
||||
"key": "QK_USER_4"
|
||||
},
|
||||
"0x7E45": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_5",
|
||||
"key": "QK_USER_5"
|
||||
},
|
||||
"0x7E46": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_6",
|
||||
"key": "QK_USER_6"
|
||||
},
|
||||
"0x7E47": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_7",
|
||||
"key": "QK_USER_7"
|
||||
},
|
||||
"0x7E48": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_8",
|
||||
"key": "QK_USER_8"
|
||||
},
|
||||
"0x7E49": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_9",
|
||||
"key": "QK_USER_9"
|
||||
},
|
||||
"0x7E4A": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_10",
|
||||
"key": "QK_USER_10"
|
||||
},
|
||||
"0x7E4B": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_11",
|
||||
"key": "QK_USER_11"
|
||||
},
|
||||
"0x7E4C": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_12",
|
||||
"key": "QK_USER_12"
|
||||
},
|
||||
"0x7E4D": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_13",
|
||||
"key": "QK_USER_13"
|
||||
},
|
||||
"0x7E4E": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_14",
|
||||
"key": "QK_USER_14"
|
||||
},
|
||||
"0x7E4F": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_15",
|
||||
"key": "QK_USER_15"
|
||||
},
|
||||
"0x7E50": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_16",
|
||||
"key": "QK_USER_16"
|
||||
},
|
||||
"0x7E51": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_17",
|
||||
"key": "QK_USER_17"
|
||||
},
|
||||
"0x7E52": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_18",
|
||||
"key": "QK_USER_18"
|
||||
},
|
||||
"0x7E53": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_19",
|
||||
"key": "QK_USER_19"
|
||||
},
|
||||
"0x7E54": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_20",
|
||||
"key": "QK_USER_20"
|
||||
},
|
||||
"0x7E55": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_21",
|
||||
"key": "QK_USER_21"
|
||||
},
|
||||
"0x7E56": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_22",
|
||||
"key": "QK_USER_22"
|
||||
},
|
||||
"0x7E57": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_23",
|
||||
"key": "QK_USER_23"
|
||||
},
|
||||
"0x7E58": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_24",
|
||||
"key": "QK_USER_24"
|
||||
},
|
||||
"0x7E59": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_25",
|
||||
"key": "QK_USER_25"
|
||||
},
|
||||
"0x7E5A": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_26",
|
||||
},
|
||||
"key": "QK_USER_26"
|
||||
},
|
||||
"0x7E5B": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_27",
|
||||
"key": "QK_USER_27"
|
||||
},
|
||||
"0x7E5C": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_28",
|
||||
"key": "QK_USER_28"
|
||||
},
|
||||
"0x7E5D": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_29",
|
||||
"key": "QK_USER_29"
|
||||
},
|
||||
"0x7E5E": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_30",
|
||||
"key": "QK_USER_30"
|
||||
},
|
||||
"0x7E5F": {
|
||||
"group": "user",
|
||||
"key": "QK_USER_31",
|
||||
},
|
||||
"key": "QK_USER_31"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
7
data/constants/keycodes/keycodes_0.0.6.hjson
Normal file
7
data/constants/keycodes/keycodes_0.0.6.hjson
Normal file
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"ranges": {
|
||||
"0x52E0/0x001F": {
|
||||
"define": "QK_PERSISTENT_DEF_LAYER"
|
||||
}
|
||||
}
|
||||
}
|
115
data/constants/keycodes/keycodes_0.0.6_connection.hjson
Normal file
115
data/constants/keycodes/keycodes_0.0.6_connection.hjson
Normal file
@@ -0,0 +1,115 @@
|
||||
{
|
||||
"ranges": {
|
||||
"0x7780/0x003F": {
|
||||
"define": "QK_CONNECTION"
|
||||
}
|
||||
}
|
||||
"keycodes": {
|
||||
"0x7780": {
|
||||
"group": "connection",
|
||||
"key": "QK_OUTPUT_AUTO",
|
||||
"aliases": [
|
||||
"OU_AUTO"
|
||||
]
|
||||
},
|
||||
"0x7781": {
|
||||
"group": "connection",
|
||||
"key": "QK_OUTPUT_NEXT",
|
||||
"aliases": [
|
||||
"OU_NEXT"
|
||||
]
|
||||
},
|
||||
"0x7782": {
|
||||
"group": "connection",
|
||||
"key": "QK_OUTPUT_PREV",
|
||||
"aliases": [
|
||||
"OU_PREV"
|
||||
]
|
||||
},
|
||||
"0x7783": {
|
||||
"group": "connection",
|
||||
"key": "QK_OUTPUT_NONE",
|
||||
"aliases": [
|
||||
"OU_NONE"
|
||||
]
|
||||
},
|
||||
"0x7784": {
|
||||
"group": "connection",
|
||||
"key": "QK_OUTPUT_USB",
|
||||
"aliases": [
|
||||
"OU_USB"
|
||||
]
|
||||
},
|
||||
"0x7785": {
|
||||
"group": "connection",
|
||||
"key": "QK_OUTPUT_2P4GHZ",
|
||||
"aliases": [
|
||||
"OU_2P4G"
|
||||
]
|
||||
},
|
||||
"0x7786": {
|
||||
"group": "connection",
|
||||
"key": "QK_OUTPUT_BLUETOOTH",
|
||||
"aliases": [
|
||||
"OU_BT"
|
||||
]
|
||||
},
|
||||
|
||||
"0x7790": {
|
||||
"group": "connection",
|
||||
"key": "QK_BLUETOOTH_PROFILE_NEXT",
|
||||
"aliases": [
|
||||
"BT_NEXT"
|
||||
]
|
||||
},
|
||||
"0x7791": {
|
||||
"group": "connection",
|
||||
"key": "QK_BLUETOOTH_PROFILE_PREV",
|
||||
"aliases": [
|
||||
"BT_PREV"
|
||||
]
|
||||
},
|
||||
"0x7792": {
|
||||
"group": "connection",
|
||||
"key": "QK_BLUETOOTH_UNPAIR",
|
||||
"aliases": [
|
||||
"BT_UNPR"
|
||||
]
|
||||
}
|
||||
"0x7793": {
|
||||
"group": "connection",
|
||||
"key": "QK_BLUETOOTH_PROFILE1",
|
||||
"aliases": [
|
||||
"BT_PRF1"
|
||||
]
|
||||
},
|
||||
"0x7794": {
|
||||
"group": "connection",
|
||||
"key": "QK_BLUETOOTH_PROFILE2",
|
||||
"aliases": [
|
||||
"BT_PRF2"
|
||||
]
|
||||
},
|
||||
"0x7795": {
|
||||
"group": "connection",
|
||||
"key": "QK_BLUETOOTH_PROFILE3",
|
||||
"aliases": [
|
||||
"BT_PRF3"
|
||||
]
|
||||
},
|
||||
"0x7796": {
|
||||
"group": "connection",
|
||||
"key": "QK_BLUETOOTH_PROFILE4",
|
||||
"aliases": [
|
||||
"BT_PRF4"
|
||||
]
|
||||
},
|
||||
"0x7797": {
|
||||
"group": "connection",
|
||||
"key": "QK_BLUETOOTH_PROFILE5",
|
||||
"aliases": [
|
||||
"BT_PRF5"
|
||||
]
|
||||
},
|
||||
}
|
||||
}
|
14
data/constants/keycodes/keycodes_0.0.6_quantum.hjson
Normal file
14
data/constants/keycodes/keycodes_0.0.6_quantum.hjson
Normal file
@@ -0,0 +1,14 @@
|
||||
{
|
||||
"keycodes": {
|
||||
"0x7C20": "!delete!", // old QK_OUTPUT_AUTO
|
||||
"0x7C21": "!delete!", // old QK_OUTPUT_USB
|
||||
"0x7C22": "!delete!", // old QK_OUTPUT_BLUETOOTH
|
||||
"0x7C7B": {
|
||||
"group": "quantum",
|
||||
"key": "QK_LAYER_LOCK",
|
||||
"aliases": [
|
||||
"QK_LLCK"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
@@ -84,6 +84,11 @@
|
||||
"board": "STEMCELL",
|
||||
"bootloader": "tinyuf2",
|
||||
"processor": "STM32F411"
|
||||
},
|
||||
"svlinky": {
|
||||
"board": "QMK_PM2040",
|
||||
"bootloader": "rp2040",
|
||||
"processor": "RP2040"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
@@ -64,6 +64,9 @@
|
||||
"WEAR_LEVELING_BACKING_SIZE": {"info_key": "eeprom.wear_leveling.backing_size", "value_type": "int", "to_json": false},
|
||||
"WEAR_LEVELING_LOGICAL_SIZE": {"info_key": "eeprom.wear_leveling.logical_size", "value_type": "int", "to_json": false},
|
||||
|
||||
// Layer locking
|
||||
"LAYER_LOCK_IDLE_TIMEOUT": {"info_key": "layer_lock.timeout", "value_type": "int"},
|
||||
|
||||
// Indicators
|
||||
"LED_CAPS_LOCK_PIN": {"info_key": "indicators.caps_lock"},
|
||||
"LED_NUM_LOCK_PIN": {"info_key": "indicators.num_lock"},
|
||||
|
@@ -563,6 +563,15 @@
|
||||
"plain60": {
|
||||
"target": "evyd13/plain60"
|
||||
},
|
||||
"planck/ez": {
|
||||
"target": "zsa/planck_ez/base"
|
||||
},
|
||||
"planck/ez/base": {
|
||||
"target": "zsa/planck_ez/base"
|
||||
},
|
||||
"planck/ez/glow": {
|
||||
"target": "zsa/planck_ez/glow"
|
||||
},
|
||||
"ploopyco/trackball": {
|
||||
"target": "ploopyco/trackball/rev1_005"
|
||||
},
|
||||
@@ -1356,6 +1365,12 @@
|
||||
"runner3680/5x8": {
|
||||
"target": "omkbd/runner3680/5x8"
|
||||
},
|
||||
"saevus/cor": {
|
||||
"target": "concreteflowers/cor"
|
||||
},
|
||||
"saevus/cor_tkl": {
|
||||
"target": "concreteflowers/cor_tkl"
|
||||
},
|
||||
"scarletbandana": {
|
||||
"target": "woodkeys/scarletbandana"
|
||||
},
|
||||
|
@@ -16,12 +16,6 @@
|
||||
"type": "object",
|
||||
"additionalProperties": {"type": "boolean"}
|
||||
},
|
||||
"build_target": {
|
||||
"oneOf": [
|
||||
{"$ref": "#/keyboard_keymap_tuple"},
|
||||
{"$ref": "#/json_file_path"}
|
||||
]
|
||||
},
|
||||
"filename": {
|
||||
"type": "string",
|
||||
"minLength": 1,
|
||||
@@ -53,6 +47,19 @@
|
||||
{"$ref": "#/keyboard"},
|
||||
{"$ref": "#/filename"}
|
||||
],
|
||||
"minItems": 2,
|
||||
"maxItems": 2,
|
||||
"unevaluatedItems": false
|
||||
},
|
||||
"keyboard_keymap_env": {
|
||||
"type": "array",
|
||||
"prefixItems": [
|
||||
{"$ref": "#/keyboard"},
|
||||
{"$ref": "#/filename"},
|
||||
{"$ref": "#/kvp_object"}
|
||||
],
|
||||
"minItems": 3,
|
||||
"maxItems": 3,
|
||||
"unevaluatedItems": false
|
||||
},
|
||||
"keycode": {
|
||||
@@ -87,6 +94,10 @@
|
||||
"maxLength": 7,
|
||||
"pattern": "^[A-Z][A-Zs_0-9]*$"
|
||||
},
|
||||
"kvp_object": {
|
||||
"type": "object",
|
||||
"additionalProperties": {"type": "string"}
|
||||
},
|
||||
"layout_macro": {
|
||||
"oneOf": [
|
||||
{
|
||||
|
@@ -45,7 +45,7 @@
|
||||
},
|
||||
"development_board": {
|
||||
"type": "string",
|
||||
"enum": ["promicro", "elite_c", "elite_pi", "proton_c", "kb2040", "promicro_rp2040", "blok", "michi", "bit_c_pro", "stemcell", "bluepill", "blackpill_f401", "blackpill_f411", "bonsai_c4", "helios", "liatris", "imera"]
|
||||
"enum": ["promicro", "elite_c", "elite_pi", "proton_c", "kb2040", "promicro_rp2040", "blok", "michi", "bit_c_pro", "stemcell", "bluepill", "blackpill_f401", "blackpill_f411", "bonsai_c4", "helios", "liatris", "imera", "svlinky"]
|
||||
},
|
||||
"pin_compatible": {
|
||||
"type": "string",
|
||||
@@ -92,6 +92,7 @@
|
||||
"GD32VF103",
|
||||
"WB32F3G71",
|
||||
"WB32FQ95",
|
||||
"AT32F415",
|
||||
"atmega16u2",
|
||||
"atmega32u2",
|
||||
"atmega16u4",
|
||||
@@ -216,6 +217,7 @@
|
||||
"type": "string",
|
||||
"enum": [
|
||||
"apm32-dfu",
|
||||
"at32-dfu",
|
||||
"atmel-dfu",
|
||||
"bootloadhid",
|
||||
"caterina",
|
||||
@@ -373,6 +375,12 @@
|
||||
}
|
||||
},
|
||||
"keycodes": {"$ref": "qmk.definitions.v1#/keycode_decl_array"},
|
||||
"layer_lock": {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"timeout": {"$ref": "qmk.definitions.v1#/unsigned_int"}
|
||||
}
|
||||
},
|
||||
"layout_aliases": {
|
||||
"type": "object",
|
||||
"additionalProperties": {"$ref": "qmk.definitions.v1#/layout_macro"}
|
||||
|
@@ -72,10 +72,5 @@
|
||||
"notes": {
|
||||
"type": "string"
|
||||
}
|
||||
},
|
||||
"required": [
|
||||
"keyboard",
|
||||
"layout",
|
||||
"layers"
|
||||
]
|
||||
}
|
||||
}
|
||||
|
@@ -3,6 +3,14 @@
|
||||
"$id": "qmk.user_repo.v1",
|
||||
"title": "User Repository Information",
|
||||
"type": "object",
|
||||
"definitions": {
|
||||
"build_target": {
|
||||
"oneOf": [
|
||||
{"$ref": "qmk.definitions.v1#/keyboard_keymap_tuple"},
|
||||
{"$ref": "qmk.definitions.v1#/json_file_path"}
|
||||
]
|
||||
},
|
||||
},
|
||||
"required": [
|
||||
"userspace_version",
|
||||
"build_targets"
|
||||
@@ -15,7 +23,7 @@
|
||||
"build_targets": {
|
||||
"type": "array",
|
||||
"items": {
|
||||
"$ref": "qmk.definitions.v1#/build_target"
|
||||
"$ref": "#/definitions/build_target"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
31
data/schemas/user_repo_v1_1.jsonschema
Normal file
31
data/schemas/user_repo_v1_1.jsonschema
Normal file
@@ -0,0 +1,31 @@
|
||||
{
|
||||
"$schema": "https://json-schema.org/draft/2020-12/schema#",
|
||||
"$id": "qmk.user_repo.v1_1",
|
||||
"title": "User Repository Information",
|
||||
"type": "object",
|
||||
"definitions": {
|
||||
"build_target": {
|
||||
"oneOf": [
|
||||
{"$ref": "qmk.definitions.v1#/keyboard_keymap_tuple"},
|
||||
{"$ref": "qmk.definitions.v1#/keyboard_keymap_env"},
|
||||
{"$ref": "qmk.definitions.v1#/json_file_path"}
|
||||
]
|
||||
},
|
||||
},
|
||||
"required": [
|
||||
"userspace_version",
|
||||
"build_targets"
|
||||
],
|
||||
"properties": {
|
||||
"userspace_version": {
|
||||
"type": "string",
|
||||
"enum": ["1.1"]
|
||||
},
|
||||
"build_targets": {
|
||||
"type": "array",
|
||||
"items": {
|
||||
"$ref": "#/definitions/build_target"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
198
docs/ChangeLog/20240825.md
Normal file
198
docs/ChangeLog/20240825.md
Normal file
@@ -0,0 +1,198 @@
|
||||
# QMK Breaking Changes - 2024 August 25 Changelog
|
||||
|
||||
## Notable Features
|
||||
|
||||
August 2024 brings another maintenance release of QMK. Almost all PRs this cycle were to do with cleanup or re-organization of existing features and code.
|
||||
|
||||
One key item is that there are no longer any `via`-enabled keymaps in the QMK repository -- these have all transitioned to an [External Userspace](../newbs_external_userspace) repository under the VIA team's control. Going forward, all PRs to `qmk_firmware` must not contain `via` keymaps; these should instead be redirected to the [VIA QMK Userspace](https://github.com/the-via/qmk_userspace_via) repository.
|
||||
|
||||
## Changes Requiring User Action
|
||||
|
||||
### 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 |
|
||||
|----------------------------------|-------------------------------|
|
||||
| dnworks/9973 | dnworks/tkl87 |
|
||||
| maple_computing/lets_split_eh/eh | maple_computing/lets_split_eh |
|
||||
| planck/ez/base | zsa/planck_ez/base |
|
||||
|
||||
### SparkFun Pro Micro RP2040 converter renamed ([#24192](https://github.com/qmk/qmk_firmware/pull/24192))
|
||||
|
||||
The converter for the SparkFun Pro Micro RP2040 has been renamed.
|
||||
|
||||
| Old | New |
|
||||
|-------------------|-------------------|
|
||||
| `promicro_rp2040` | `sparkfun_rp2040` |
|
||||
|
||||
This change was made to avoid confusion between the clones named ProMicro RP2040 and the SparkFun Pro Micro RP2040. The clones should be using the `rp2040_ce` option.
|
||||
|
||||
### Key Override `keymap.c` signature change ([#24120](https://github.com/qmk/qmk_firmware/pull/24120))
|
||||
|
||||
Changes were made to key overrides in order to hook them into the keymap introspection system.
|
||||
|
||||
If you're using key overrides, your `keymap.c` will need a change to the signature of your list of key overrides, as well as removing the `NULL` terminator.
|
||||
|
||||
For example, you'll need to change existing code from (note the highlighted lines):
|
||||
|
||||
```c{1,4-5}
|
||||
const key_override_t **key_overrides = (const key_override_t *[]){
|
||||
&my_override_1,
|
||||
&my_override_2,
|
||||
NULL
|
||||
};
|
||||
```
|
||||
|
||||
to:
|
||||
|
||||
```c{1,4}
|
||||
const key_override_t *key_overrides[] = {
|
||||
&my_override_1,
|
||||
&my_override_2,
|
||||
};
|
||||
```
|
||||
|
||||
### ADNS9800 and PMW33xx firmware upload now opt-in ([#24001](https://github.com/qmk/qmk_firmware/pull/24001))
|
||||
|
||||
Due to ambiguity with licensing compatibility, QMK has made the firmware ROM uploads for the ADNS9800 and PMW33xx lines of pointing device sensors temporarily opt-in with the view to removing them. Historically they were included by default, but as of this PR this is now no longer the case.
|
||||
|
||||
Please get in touch with the QMK team if your sensor no longer functions without the firmware upload -- so far we've tested each device type and they still seem to function without a new firmware, but this has not been a 100% exhaustive validation.
|
||||
|
||||
To re-enable firmware upload for your own builds, add the following to your keymap's `config.h`:
|
||||
|
||||
| Sensor | Define |
|
||||
|----------|--------------------------------|
|
||||
| ADNS9800 | `#define ADNS9800_UPLOAD_SROM` |
|
||||
| PMW33xx | `#define PMW33XX_UPLOAD_SROM` |
|
||||
|
||||
:::info Note
|
||||
If no issues arise during this current breaking changes cycle, these sensor firmware ROMs will be removed from QMK entirely.
|
||||
:::
|
||||
|
||||
## 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
|
||||
|
||||
Last breaking changes cycle, the QMK team informed that [`via` keymaps are moving](./20240526#migration-of-via-keymaps-to-via-team-control) to the control of the VIA team. As of this merge, any `via`-enabled keymaps should now be PR'ed to the [VIA QMK Userspace](https://github.com/the-via/qmk_userspace_via) repository.
|
||||
|
||||
Any existing or newly-opened PRs against `qmk_firmware` will now be asked to remove any `via`-enabled keymaps from their submissions.
|
||||
|
||||
### ADNS9800 and PMW33xx sensor firmware ROM removal
|
||||
|
||||
As mentioned above, there's license compatibility issues between QMK and the firmware blobs historically uploaded for the ADNS9800 and PMW33xx sensors. This notice is to inform users that these firmware blobs will almost certainly be removed from QMK in the next breaking changes merge.
|
||||
|
||||
As previously noted this does not seem to have any detrimental effect to any of those devices, as they seem to include firmware on-chip without requiring one to be uploaded. Please get in touch with the QMK team on Discord if your sensor is no longer functional.
|
||||
|
||||
## Full changelist
|
||||
|
||||
Core:
|
||||
* EEPROM: Don't erase if we don't have to. Adding eeprom_driver_format abstraction. ([#18332](https://github.com/qmk/qmk_firmware/pull/18332))
|
||||
* Generate keymap dd keycodes to header ([#20273](https://github.com/qmk/qmk_firmware/pull/20273))
|
||||
* [wear_leveling] efl updates ([#22489](https://github.com/qmk/qmk_firmware/pull/22489))
|
||||
* GC9xxx LCD family drivers (GC9107 and GC9A01) ([#23091](https://github.com/qmk/qmk_firmware/pull/23091))
|
||||
* [build_test] set CONSOLE_ENABLE=yes if DEBUG > 0 ([#23097](https://github.com/qmk/qmk_firmware/pull/23097))
|
||||
* Enhance overlapping mouse keys control ([#23341](https://github.com/qmk/qmk_firmware/pull/23341))
|
||||
* APA102: API rework ([#23355](https://github.com/qmk/qmk_firmware/pull/23355))
|
||||
* [WIP] Adds bus acquire/release semantics to SPI start/stop. ([#23439](https://github.com/qmk/qmk_firmware/pull/23439))
|
||||
* add farsi keymap extras ([#23650](https://github.com/qmk/qmk_firmware/pull/23650))
|
||||
* Update atomic GPIO macros in keyboard custom matrix ([#23796](https://github.com/qmk/qmk_firmware/pull/23796))
|
||||
* Check LED flags for Pixel Fractal effect ([#23881](https://github.com/qmk/qmk_firmware/pull/23881))
|
||||
* Add STM32F405RG ld script for tinyuf2 ([#23885](https://github.com/qmk/qmk_firmware/pull/23885))
|
||||
* SPI flash API cleanup, add async erase capability. ([#23894](https://github.com/qmk/qmk_firmware/pull/23894))
|
||||
* Add process_keycode handlers for new RGB Matrix and Underglow keycodes ([#23896](https://github.com/qmk/qmk_firmware/pull/23896))
|
||||
* Decouple VIA from STM32 L0/L1 EEPROM implementation ([#23901](https://github.com/qmk/qmk_firmware/pull/23901))
|
||||
* Normalise mouse keycodes ([#23975](https://github.com/qmk/qmk_firmware/pull/23975))
|
||||
* Remove deprecated `led_set_user` ([#23979](https://github.com/qmk/qmk_firmware/pull/23979))
|
||||
* Change ADNS9800 and PMW33XX SROM uploads to opt in. ([#24001](https://github.com/qmk/qmk_firmware/pull/24001))
|
||||
* Rename encoder pins defines ([#24003](https://github.com/qmk/qmk_firmware/pull/24003))
|
||||
* Change suspend condition check order on ChibiOS ([#24020](https://github.com/qmk/qmk_firmware/pull/24020))
|
||||
* Tap dance introspection ([#24049](https://github.com/qmk/qmk_firmware/pull/24049))
|
||||
* Allow overriding `get_hardware_id()`. ([#24051](https://github.com/qmk/qmk_firmware/pull/24051))
|
||||
* Align LUFA suspend logic ([#24055](https://github.com/qmk/qmk_firmware/pull/24055))
|
||||
* Add support for key override introspection. ([#24120](https://github.com/qmk/qmk_firmware/pull/24120))
|
||||
* Dynamic macro callbacks ([#24142](https://github.com/qmk/qmk_firmware/pull/24142))
|
||||
* Rename promicro_rp2040 converter to sparkfun_pm2040 ([#24192](https://github.com/qmk/qmk_firmware/pull/24192))
|
||||
* Refactor starlight RGB matrix effects ([#24202](https://github.com/qmk/qmk_firmware/pull/24202))
|
||||
* Refactor riverflow RGB matrix loop ([#24203](https://github.com/qmk/qmk_firmware/pull/24203))
|
||||
|
||||
CLI:
|
||||
* Remove handling of keyboard level keymap templates ([#24234](https://github.com/qmk/qmk_firmware/pull/24234))
|
||||
* Small tweaks to keymap generation ([#24240](https://github.com/qmk/qmk_firmware/pull/24240))
|
||||
|
||||
Keyboards:
|
||||
* refactor: keyboard/ncr80/r2 ([#22670](https://github.com/qmk/qmk_firmware/pull/22670))
|
||||
* Implement data driven joysticks ([#22947](https://github.com/qmk/qmk_firmware/pull/22947))
|
||||
* Whitefacemountain Ampersand ([#23437](https://github.com/qmk/qmk_firmware/pull/23437))
|
||||
* Add TRKeyboard TRK1 keyboard ([#23642](https://github.com/qmk/qmk_firmware/pull/23642))
|
||||
* Rename dnworks/9973 to dnworks/tkl87 ([#23692](https://github.com/qmk/qmk_firmware/pull/23692))
|
||||
* Update Underglow keycodes ([#23765](https://github.com/qmk/qmk_firmware/pull/23765))
|
||||
* Add boardsource/the_q ([#23782](https://github.com/qmk/qmk_firmware/pull/23782))
|
||||
* BastardKB: remove legacy board `tbk` ([#23818](https://github.com/qmk/qmk_firmware/pull/23818))
|
||||
* Update ZSA Moonlander ([#23911](https://github.com/qmk/qmk_firmware/pull/23911))
|
||||
* Move Planck EZ to ZSA vendor folder ([#23917](https://github.com/qmk/qmk_firmware/pull/23917))
|
||||
* Migrate SPLIT_HAND_PIN to json ([#23924](https://github.com/qmk/qmk_firmware/pull/23924))
|
||||
* Migrate SERIAL_DRIVER to json ([#23925](https://github.com/qmk/qmk_firmware/pull/23925))
|
||||
* Migrate RGB Matrix layout for two boards ([#23963](https://github.com/qmk/qmk_firmware/pull/23963))
|
||||
* Migrate `led_update_kb` implementations to DD ([#23980](https://github.com/qmk/qmk_firmware/pull/23980))
|
||||
* Migrate `led_update_kb` implementations to DD ([#23981](https://github.com/qmk/qmk_firmware/pull/23981))
|
||||
* Migrate `led_update_kb` implementations to DD ([#23983](https://github.com/qmk/qmk_firmware/pull/23983))
|
||||
* Migrate `led_update_kb` implementations to DD ([#23985](https://github.com/qmk/qmk_firmware/pull/23985))
|
||||
* Relocate m256wh VIA logic ([#24006](https://github.com/qmk/qmk_firmware/pull/24006))
|
||||
* Relocate winry315 VIA logic ([#24008](https://github.com/qmk/qmk_firmware/pull/24008))
|
||||
* Relocate m256ws VIA logic ([#24009](https://github.com/qmk/qmk_firmware/pull/24009))
|
||||
* `atreus`: misc cleanups ([#24010](https://github.com/qmk/qmk_firmware/pull/24010))
|
||||
* Relocate work_louder VIA logic ([#24011](https://github.com/qmk/qmk_firmware/pull/24011))
|
||||
* Relocate xelus/pachi/rgb/rev2 VIA logic ([#24016](https://github.com/qmk/qmk_firmware/pull/24016))
|
||||
* Remove custom keycodes from nullbitsco/snap ([#24017](https://github.com/qmk/qmk_firmware/pull/24017))
|
||||
* added bear_face/v3 ([#24032](https://github.com/qmk/qmk_firmware/pull/24032))
|
||||
* Remove DEFAULT_FOLDER from maple_computing/lets_split_eh ([#24054](https://github.com/qmk/qmk_firmware/pull/24054))
|
||||
* refactor bear_face/v1, v2 ([#24060](https://github.com/qmk/qmk_firmware/pull/24060))
|
||||
* Convert `eeconfig_init_kb` implementations to config ([#24087](https://github.com/qmk/qmk_firmware/pull/24087))
|
||||
* Remove broken keymap from keebio/iris ([#24094](https://github.com/qmk/qmk_firmware/pull/24094))
|
||||
* Move LED Matrix LED config to data driven ([#24122](https://github.com/qmk/qmk_firmware/pull/24122))
|
||||
* Move split.soft_serial_pin to split.serial.pin ([#24127](https://github.com/qmk/qmk_firmware/pull/24127))
|
||||
* Remove pointless `RGB_MATRIX_LED_COUNT`s ([#24133](https://github.com/qmk/qmk_firmware/pull/24133))
|
||||
* `hs60/v1`: separate into ANSI and ISO revisions ([#24136](https://github.com/qmk/qmk_firmware/pull/24136))
|
||||
* Migrate half-duplex `SERIAL_USART_TX_PIN` to DD ([#24143](https://github.com/qmk/qmk_firmware/pull/24143))
|
||||
* Migrate split.soft_serial_pin to split.serial.pin O-Z ([#24146](https://github.com/qmk/qmk_firmware/pull/24146))
|
||||
* Migrate split.soft_serial_pin to split.serial.pin 0-H ([#24155](https://github.com/qmk/qmk_firmware/pull/24155))
|
||||
* Remove instances of MASTER_LEFT. ([#24163](https://github.com/qmk/qmk_firmware/pull/24163))
|
||||
* Rename EC Type-K ([#24180](https://github.com/qmk/qmk_firmware/pull/24180))
|
||||
* Migrate split.soft_serial_pin to split.serial.pin H-O ([#24185](https://github.com/qmk/qmk_firmware/pull/24185))
|
||||
* Remove split.transport.protocol=serial ([#24191](https://github.com/qmk/qmk_firmware/pull/24191))
|
||||
* Refactor use of `matrix_scan_kb` ([#24200](https://github.com/qmk/qmk_firmware/pull/24200))
|
||||
* Eliminate use of `#include "../default/keymap.c"`. ([#24215](https://github.com/qmk/qmk_firmware/pull/24215))
|
||||
* Remove keyboard level `QK_BOOT` implementations ([#24231](https://github.com/qmk/qmk_firmware/pull/24231))
|
||||
* Remove `handwired/pytest/has_template` ([#24232](https://github.com/qmk/qmk_firmware/pull/24232))
|
||||
* Refactor opendeck/32 ([#24233](https://github.com/qmk/qmk_firmware/pull/24233))
|
||||
* Refactor printedpad ([#24236](https://github.com/qmk/qmk_firmware/pull/24236))
|
||||
* Refactor orthocode ([#24237](https://github.com/qmk/qmk_firmware/pull/24237))
|
||||
* Remove unnecessary RGB Matrix shutdown hooks ([#24238](https://github.com/qmk/qmk_firmware/pull/24238))
|
||||
* Remove all via-enabled keymaps, including `via`. ([#24322](https://github.com/qmk/qmk_firmware/pull/24322))
|
||||
|
||||
Keyboard fixes:
|
||||
* Fix dogtag/info.json ([#23520](https://github.com/qmk/qmk_firmware/pull/23520))
|
||||
* splitkb/kyria: remove `CONVERT_TO` at keyboard level ([#23857](https://github.com/qmk/qmk_firmware/pull/23857))
|
||||
* Fixup mt/mt84 ([#23883](https://github.com/qmk/qmk_firmware/pull/23883))
|
||||
* Fix for encoders and support ENCODER_MAP_ENABLE on Planck rev7 ([#23967](https://github.com/qmk/qmk_firmware/pull/23967))
|
||||
* `handwired/swiftrax/bumblebee`: fix layout name ([#24064](https://github.com/qmk/qmk_firmware/pull/24064))
|
||||
* Fixup boardsource/the_q RGB matrix coordinates ([#24086](https://github.com/qmk/qmk_firmware/pull/24086))
|
||||
* Various fixes for keyboards not implementing callbacks correctly ([#24092](https://github.com/qmk/qmk_firmware/pull/24092))
|
||||
* Various fixes for keyboards not implementing callbacks correctly ([#24116](https://github.com/qmk/qmk_firmware/pull/24116))
|
||||
* Remove duplicate calls to `housekeeping_task_user` ([#24201](https://github.com/qmk/qmk_firmware/pull/24201))
|
||||
* Fixup `handwired/dactyl_minidox` ([#24253](https://github.com/qmk/qmk_firmware/pull/24253))
|
||||
* Fix build failure on zsa/moonlander with DYNAMIC_MACRO_ENABLE ([#24316](https://github.com/qmk/qmk_firmware/pull/24316))
|
||||
|
||||
Others:
|
||||
* LED drivers: extract documentation from LED/RGB Matrix pages ([#23630](https://github.com/qmk/qmk_firmware/pull/23630))
|
||||
* Implement data driven serial driver ([#23923](https://github.com/qmk/qmk_firmware/pull/23923))
|
||||
* Remove skipped schema files ([#23987](https://github.com/qmk/qmk_firmware/pull/23987))
|
||||
* Update RGBLight (Underglow) keycode names ([#23999](https://github.com/qmk/qmk_firmware/pull/23999))
|
||||
|
||||
Bugs:
|
||||
* Fix NKRO and Mouse Emulation on arm_atsam ([#23945](https://github.com/qmk/qmk_firmware/pull/23945))
|
||||
* Force `dump_lines()` to always use Unix line endings ([#23954](https://github.com/qmk/qmk_firmware/pull/23954))
|
||||
* Fixup home link. ([#24068](https://github.com/qmk/qmk_firmware/pull/24068))
|
@@ -1,19 +0,0 @@
|
||||
## Changes requiring user action
|
||||
|
||||
### SparkFun Pro Micro RP2040 converter renamed
|
||||
|
||||
The converter for the SparkFun Pro Micro RP2040 has been renamed.
|
||||
|
||||
from:
|
||||
|
||||
```
|
||||
promicro_rp2040
|
||||
```
|
||||
|
||||
to:
|
||||
|
||||
```c
|
||||
sparkfun_rp2040
|
||||
```
|
||||
|
||||
This change was made to avoid confusion between the clones named ProMicro RP2040 and the SparkFun Pro Micro RP2040. The clones should be using the `rp2040_ce` option.
|
122
docs/ChangeLog/20241124.md
Normal file
122
docs/ChangeLog/20241124.md
Normal file
@@ -0,0 +1,122 @@
|
||||
# QMK Breaking Changes - 2024 November 24 Changelog
|
||||
|
||||
## Notable Features
|
||||
|
||||
November 2024 brings a relatively lightweight QMK release. As with previous cycles, almost all PRs were related to cleanup or re-organization of aspects of QMK.
|
||||
|
||||
One notable item is the removal of `arm_atsam` -- this affects users with `massdrop/ctrl` or `massdrop/alt` keyboards. These have no current replacement, but support for an alternative to the `arm_atsam` backend is nearing completion. Unfortunately the alternative backend didn't make this quarter's list of merges, so there's a temporary removal of these boards. Users who need to build for these targets should stay on the `0.26.x` version of QMK until these boards have been restored.
|
||||
|
||||
## Changes Requiring User Action
|
||||
|
||||
### 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 |
|
||||
|-------------------|-------------------------|
|
||||
| saevus/cor | concreteflowers/cor |
|
||||
| saevus/cor_tkl | concreteflowers/cor_tkl |
|
||||
|
||||
## 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.
|
||||
|
||||
### RGB Keycode Overhaul ([#23679](https://github.com/qmk/qmk_firmware/pull/23679), [#24484](https://github.com/qmk/qmk_firmware/pull/24484), [#24490](https://github.com/qmk/qmk_firmware/pull/24490))
|
||||
|
||||
RGB keycodes have been reworked to allow for both rgblight and rgb_matrix to coexist for the handful of boards in the repo with both enabled. Previously, `RGB_xxx` style keycodes were available, but now for rgblight we have `UG_xxx` (underglow), and `RM_xxx` for rgb_matrix. Default keymaps have been updated to reflect whichever system the respective board enables.
|
||||
|
||||
Longer-term, `RGB_xxx` style keycodes will be removed, but for now they act as if they're `UG_xxx`, and `UG_xxx` keycodes act upon both rgblight and rgb_matrix simultaneously. Put simply, the existing `RGB_xxx` keycodes act as they always have, giving users time to transition across to the new keycodes instead.
|
||||
|
||||
### ADNS9800 and PMW33xx sensor firmware ROM removal ([#24428](https://github.com/qmk/qmk_firmware/pull/24428))
|
||||
|
||||
Following on from the last Breaking Changes cycle, Binary blobs for optical sensors have been removed from the QMK codebase. Hooks allowing users to supply their own have been put in place; users wishing to source firmware blobs and integrate them into their keymap may do so. Doing so renders their firmware un-distributable due to licensing incompatibility with the GPL -- as such user firmware containing such blobs must not be distributed.
|
||||
|
||||
Please get in touch with the QMK team on Discord if your sensor is no longer functional.
|
||||
|
||||
## Full changelist
|
||||
|
||||
Core:
|
||||
* Refactor F4 ld files to use common files ([#18059](https://github.com/qmk/qmk_firmware/pull/18059))
|
||||
* Add LD7032 support to QP. ([#20828](https://github.com/qmk/qmk_firmware/pull/20828))
|
||||
* Add combo key repress feature ([#22858](https://github.com/qmk/qmk_firmware/pull/22858))
|
||||
* Add Layer Lock feature ([#23430](https://github.com/qmk/qmk_firmware/pull/23430))
|
||||
* Added MCU support for ArteryTek AT32F415 ([#23445](https://github.com/qmk/qmk_firmware/pull/23445))
|
||||
* Allow codegen of `keymap.json` => `keymap.c` without requiring layers/layout etc. ([#23451](https://github.com/qmk/qmk_firmware/pull/23451))
|
||||
* Separate RGBLight/RGB Matrix keycode handling ([#23679](https://github.com/qmk/qmk_firmware/pull/23679))
|
||||
* Allow for inverted SPI CS logic ([#23699](https://github.com/qmk/qmk_firmware/pull/23699))
|
||||
* Add timer_save and _restore functions. ([#23887](https://github.com/qmk/qmk_firmware/pull/23887))
|
||||
* Allow for `get_hardware_id()` to be used for serial number. ([#24053](https://github.com/qmk/qmk_firmware/pull/24053))
|
||||
* Segregrate keycode at pre-process record quantum ([#24194](https://github.com/qmk/qmk_firmware/pull/24194))
|
||||
* Add ability to poweroff ADNS5050 sensor ([#24223](https://github.com/qmk/qmk_firmware/pull/24223))
|
||||
* quantum: util: add bit and bitmask helpers ([#24229](https://github.com/qmk/qmk_firmware/pull/24229))
|
||||
* Add new connection keycodes for Bluetooth, 2.4GHz. ([#24251](https://github.com/qmk/qmk_firmware/pull/24251))
|
||||
* `usb_device_state`: consolidate usb state handling across implementations ([#24258](https://github.com/qmk/qmk_firmware/pull/24258))
|
||||
* Remove global k_rgb_matrix_split ([#24348](https://github.com/qmk/qmk_firmware/pull/24348))
|
||||
* util: uf2families: sync with upstream ([#24351](https://github.com/qmk/qmk_firmware/pull/24351))
|
||||
* [Maintenance] builddefs: common_rules: overhaul debug information generation ([#24352](https://github.com/qmk/qmk_firmware/pull/24352))
|
||||
* Add easier way to set default single layer ([#24376](https://github.com/qmk/qmk_firmware/pull/24376))
|
||||
* Tweak OS detect, add OS_DETECTION_SINGLE_REPORT ([#24379](https://github.com/qmk/qmk_firmware/pull/24379))
|
||||
* Reinstate global `k_rgb_matrix_split` ([#24388](https://github.com/qmk/qmk_firmware/pull/24388))
|
||||
* Bring supported STM32F4 configs in line with F4x1 ([#24413](https://github.com/qmk/qmk_firmware/pull/24413))
|
||||
* Extended wheel reports ([#24422](https://github.com/qmk/qmk_firmware/pull/24422))
|
||||
* Remove binary blobs from optical sensors. ([#24428](https://github.com/qmk/qmk_firmware/pull/24428))
|
||||
* Remove `STM32_PWM_USE_ADVANCED` references ([#24432](https://github.com/qmk/qmk_firmware/pull/24432))
|
||||
* Remove `RING_BUFFERED_6KRO_REPORT_ENABLE` due to disuse. ([#24433](https://github.com/qmk/qmk_firmware/pull/24433))
|
||||
* Move pointing device driver code ([#24445](https://github.com/qmk/qmk_firmware/pull/24445))
|
||||
* Add svlinky converter ([#24449](https://github.com/qmk/qmk_firmware/pull/24449))
|
||||
* Update combo user function variable ([#24467](https://github.com/qmk/qmk_firmware/pull/24467))
|
||||
* `qmk find`: expand operator support ([#24468](https://github.com/qmk/qmk_firmware/pull/24468))
|
||||
* Rename RGB and HSV structs ([#24471](https://github.com/qmk/qmk_firmware/pull/24471))
|
||||
* RGBLight: Improve RGB Test animation ([#24477](https://github.com/qmk/qmk_firmware/pull/24477))
|
||||
* Change default ARM hardware PWM WS2812 tick frequency to 800kHz ([#24508](https://github.com/qmk/qmk_firmware/pull/24508))
|
||||
* Add pointing tests ([#24513](https://github.com/qmk/qmk_firmware/pull/24513))
|
||||
* Joystick: add support for 8-way hat switch ([#24515](https://github.com/qmk/qmk_firmware/pull/24515))
|
||||
* Refactor Riverflow matrix effect with runner ([#24520](https://github.com/qmk/qmk_firmware/pull/24520))
|
||||
* Update Pixel Rain to respect LED range limits ([#24532](https://github.com/qmk/qmk_firmware/pull/24532))
|
||||
* Update Jellybean Raindrops to respect LED range limits ([#24534](https://github.com/qmk/qmk_firmware/pull/24534))
|
||||
* Refactor Breathing effect with runner ([#24535](https://github.com/qmk/qmk_firmware/pull/24535))
|
||||
* Refactor LED Breathing effect with runner ([#24540](https://github.com/qmk/qmk_firmware/pull/24540))
|
||||
* Expose rgb_matrix_update_pwm_buffers to be available in keymaps ([#24573](https://github.com/qmk/qmk_firmware/pull/24573))
|
||||
* Simple Python script to show polling rate ([#24622](https://github.com/qmk/qmk_firmware/pull/24622))
|
||||
* Add keycode PDF(layer) to set the default layer in EEPROM ([#24630](https://github.com/qmk/qmk_firmware/pull/24630))
|
||||
* Provide method to save a single default layer in the full range of 0-31 ([#24639](https://github.com/qmk/qmk_firmware/pull/24639))
|
||||
|
||||
CLI:
|
||||
* Refactor painter arguments to table instead of commandline ([#24456](https://github.com/qmk/qmk_firmware/pull/24456))
|
||||
* `qmk new-keyboard`: separate dev board and MCU selection ([#24548](https://github.com/qmk/qmk_firmware/pull/24548))
|
||||
* Bump minimum required Python version ([#24554](https://github.com/qmk/qmk_firmware/pull/24554))
|
||||
|
||||
Submodule updates:
|
||||
* Remove `arm_atsam` platform ([#24337](https://github.com/qmk/qmk_firmware/pull/24337))
|
||||
|
||||
Keyboards:
|
||||
* add ergodox Community Layout for LAYOUT_ergodox keyboards ([#22963](https://github.com/qmk/qmk_firmware/pull/22963))
|
||||
* Cutie Club Fidelity Layout Additions ([#23838](https://github.com/qmk/qmk_firmware/pull/23838))
|
||||
* Add Ploopyco functions for host state control ([#23953](https://github.com/qmk/qmk_firmware/pull/23953))
|
||||
* Corne rev4 ([#24084](https://github.com/qmk/qmk_firmware/pull/24084))
|
||||
* Rename saevus to concreteflowers ([#24249](https://github.com/qmk/qmk_firmware/pull/24249))
|
||||
* Remove `60_tsangan_hhkb` community layout ([#24355](https://github.com/qmk/qmk_firmware/pull/24355))
|
||||
* add USART configuration to config.h for PS/2 mouse support ([#24398](https://github.com/qmk/qmk_firmware/pull/24398))
|
||||
* Add SteelSeries Prime+ mouse ([#24408](https://github.com/qmk/qmk_firmware/pull/24408))
|
||||
* Rename RGB/HSV structs: keyboard-level code ([#24476](https://github.com/qmk/qmk_firmware/pull/24476))
|
||||
* xiudi/xd002: Remove broken oversized `multilayer_rgb` keymap ([#24480](https://github.com/qmk/qmk_firmware/pull/24480))
|
||||
* Update keycodes for keyboards with RGB Matrix ([#24484](https://github.com/qmk/qmk_firmware/pull/24484))
|
||||
* Cipulot Updates ([#24539](https://github.com/qmk/qmk_firmware/pull/24539))
|
||||
* Update keymaps to use PDF keycode ([#24633](https://github.com/qmk/qmk_firmware/pull/24633))
|
||||
* Remove keyboard use of eeconfig_read_default_layer ([#24635](https://github.com/qmk/qmk_firmware/pull/24635))
|
||||
|
||||
Keyboard fixes:
|
||||
* Fix rendering of `keymap_config.no_gui` within `led_update_kb` ([#24473](https://github.com/qmk/qmk_firmware/pull/24473))
|
||||
* Fix duplication of core `GU_TOGG` keycode ([#24474](https://github.com/qmk/qmk_firmware/pull/24474))
|
||||
* keebio/nyquist: Remove invalid I2C config ([#24479](https://github.com/qmk/qmk_firmware/pull/24479))
|
||||
* horrortroll/nyx/rev1: Fix compilation of custom RGB effect ([#24481](https://github.com/qmk/qmk_firmware/pull/24481))
|
||||
|
||||
Others:
|
||||
* Improve consistency of syntax within `data/constants/keycodes` ([#24528](https://github.com/qmk/qmk_firmware/pull/24528))
|
||||
|
||||
Bugs:
|
||||
* WS2812 API rework ([#24364](https://github.com/qmk/qmk_firmware/pull/24364))
|
||||
* Backward compatibility for new RGB keycode handling ([#24490](https://github.com/qmk/qmk_firmware/pull/24490))
|
||||
* Fix compiliation issues with OS Detection ([#24502](https://github.com/qmk/qmk_firmware/pull/24502))
|
||||
* Revert removal of `QK_OUTPUT_AUTO`, fixup docs to reflect. ([#24593](https://github.com/qmk/qmk_firmware/pull/24593))
|
||||
* Review fixes for layer lock feature ([#24627](https://github.com/qmk/qmk_firmware/pull/24627))
|
@@ -1,19 +0,0 @@
|
||||
## Changes requiring user action
|
||||
|
||||
### Key Override Introspection
|
||||
|
||||
Changes were made to key overrides in order to hook them into the keymap introspection system.
|
||||
|
||||
Key override signature changed from:
|
||||
|
||||
```c
|
||||
const key_override_t **key_overrides = (const key_override_t *[]){
|
||||
```
|
||||
|
||||
to:
|
||||
|
||||
```c
|
||||
const key_override_t *key_overrides[] = {
|
||||
```
|
||||
|
||||
The list of key overrides now does not need to be `NULL`-terminated.
|
@@ -16,6 +16,8 @@
|
||||
"/tutorial": "/newbs",
|
||||
"/unicode": "/feature_unicode",
|
||||
|
||||
"/features/bluetooth": "/features/wireless",
|
||||
|
||||
"/adc_driver": "/drivers/adc",
|
||||
"/apa102_driver": "/drivers/apa102",
|
||||
"/audio_driver": "/drivers/audio",
|
||||
@@ -24,7 +26,7 @@
|
||||
"/feature_auto_shift": "/features/auto_shift",
|
||||
"/feature_autocorrect": "/features/autocorrect",
|
||||
"/feature_backlight": "/features/backlight",
|
||||
"/feature_bluetooth": "/features/bluetooth",
|
||||
"/feature_bluetooth": "/features/wireless",
|
||||
"/feature_bootmagic": "/features/bootmagic",
|
||||
"/feature_caps_word": "/features/caps_word",
|
||||
"/feature_combo": "/features/combo",
|
||||
|
@@ -21,7 +21,8 @@
|
||||
{ "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": "Glossary", "link": "/reference_glossary" },
|
||||
{ "text": "License Violations", "link": "/license_violations" }
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -123,6 +124,7 @@
|
||||
{ "text": "Key Lock", "link": "/features/key_lock" },
|
||||
{ "text": "Key Overrides", "link": "/features/key_overrides" },
|
||||
{ "text": "Layers", "link": "/feature_layers" },
|
||||
{ "text": "Layer Lock", "link": "/features/layer_lock" },
|
||||
{ "text": "One Shot Keys", "link": "/one_shot_keys" },
|
||||
{ "text": "OS Detection", "link": "/features/os_detection" },
|
||||
{ "text": "Raw HID", "link": "/features/rawhid" },
|
||||
@@ -166,8 +168,7 @@
|
||||
]
|
||||
},
|
||||
{ "text": "Audio", "link": "/features/audio" },
|
||||
{ "text": "Bluetooth", "link": "/features/bluetooth" },
|
||||
{ "text": "Bootmagic Lite", "link": "/features/bootmagic" },
|
||||
{ "text": "Bootmagic", "link": "/features/bootmagic" },
|
||||
{ "text": "Converters", "link": "/feature_converters" },
|
||||
{ "text": "Custom Matrix", "link": "/custom_matrix" },
|
||||
{ "text": "DIP Switch", "link": "/features/dip_switch" },
|
||||
@@ -179,7 +180,8 @@
|
||||
{ "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": "Stenography", "link": "/features/stenography" },
|
||||
{ "text": "Wireless", "link": "/features/wireless" }
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -204,7 +206,7 @@
|
||||
{ "text": "My Pull Request Was Flagged", "link": "/breaking_changes_instructions" },
|
||||
{
|
||||
"text": "Most Recent ChangeLog",
|
||||
"link": "/ChangeLog/20240526"
|
||||
"link": "/ChangeLog/20241124"
|
||||
},
|
||||
{ "text": "Past Breaking Changes", "link": "/breaking_changes_history" },
|
||||
{ "text": "Deprecation Policy", "link": "/support_deprecation_policy" }
|
||||
|
@@ -4,7 +4,7 @@ This page attempts to introduce developers to the QMK Compiler. It does not go i
|
||||
|
||||
# Overview
|
||||
|
||||
The QMK Compile API consists of a few movings parts:
|
||||
The QMK Compile API consists of a few moving parts:
|
||||
|
||||

|
||||
|
||||
|
@@ -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 Nov 24](ChangeLog/20241124)
|
||||
* [2024 Aug 25](ChangeLog/20240825)
|
||||
* [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 August 25, 2024.
|
||||
The next Breaking Change is scheduled for February 23, 2025.
|
||||
|
||||
### Important Dates
|
||||
|
||||
* 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.
|
||||
* 2024 Nov 24 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
|
||||
* 2025 Jan 26 - `develop` closed to new PRs.
|
||||
* 2025 Jan 26 - Call for testers.
|
||||
* 2025 Feb 9 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
|
||||
* 2025 Feb 16 - `develop` is locked, only critical bugfix PRs merged.
|
||||
* 2024 Nov 21 - `master` is locked, no PRs merged.
|
||||
* 2025 Feb 23 - Merge `develop` to `master`.
|
||||
* 2025 Feb 23 - `master` is unlocked. PRs can be merged again.
|
||||
|
||||
## What changes will be included?
|
||||
|
||||
@@ -48,7 +48,7 @@ Criteria for acceptance:
|
||||
|
||||
Strongly suggested:
|
||||
|
||||
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20240526`.
|
||||
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20241124`.
|
||||
* This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PRs ID.
|
||||
* One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability.
|
||||
|
||||
|
@@ -2,6 +2,8 @@
|
||||
|
||||
This page links to all previous changelogs from the QMK Breaking Changes process.
|
||||
|
||||
* [2024 Nov 24](ChangeLog/20241124) - version 0.27.0
|
||||
* [2024 Aug 25](ChangeLog/20240825) - version 0.26.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
|
||||
|
@@ -31,4 +31,4 @@ Commenting on your pull request and being responsive to questions, comments, and
|
||||
|
||||
### Ask for Help
|
||||
|
||||
Having your submission flagged may have caught you off guard. If you find yourself intimidated or overwhelmed, let us know. Comment on your pull request, or [reach out to the QMK team on Discord](https://discord.gg/Uq7gcHh).
|
||||
Having your submission flagged may have caught you off guard. If you find yourself intimidated or overwhelmed, let us know. Comment on your pull request, or [reach out to the QMK team on Discord](https://discord.gg/qmk).
|
||||
|
@@ -153,20 +153,26 @@ qmk cd
|
||||
|
||||
This command allows for searching through keyboard/keymap targets, filtering by specific criteria. `info.json` and `rules.mk` files contribute to the search data, as well as keymap configurations, and the results can be filtered using "dotty" syntax matching the overall `info.json` file format.
|
||||
|
||||
For example, one could search for all keyboards using STM32F411:
|
||||
For example, one could search for all keyboards powered by the STM32F411 microcontroller:
|
||||
|
||||
```
|
||||
qmk find -f 'processor=STM32F411'
|
||||
qmk find -f 'processor==STM32F411'
|
||||
```
|
||||
|
||||
...and one can further constrain the list to keyboards using STM32F411 as well as rgb_matrix support:
|
||||
The list can be further constrained by passing additional filter expressions:
|
||||
|
||||
```
|
||||
qmk find -f 'processor=STM32F411' -f 'features.rgb_matrix=true'
|
||||
qmk find -f 'processor==STM32F411' -f 'features.rgb_matrix==true'
|
||||
```
|
||||
|
||||
The following filter expressions are also supported:
|
||||
The following filter expressions are supported:
|
||||
|
||||
- `key == value`: Match targets where `key` is equal to `value`. May include wildcards such as `*` and `?`.
|
||||
- `key != value`: Match targets where `key` is not `value`. May include wildcards such as `*` and `?`.
|
||||
- `key < value`: Match targets where `key` is a number less than `value`.
|
||||
- `key > value`: Match targets where `key` is a number greater than `value`.
|
||||
- `key <= value`: Match targets where `key` is a number less than or equal to `value`.
|
||||
- `key >= value`: Match targets where `key` is a number greater than or equal to `value`.
|
||||
- `exists(key)`: Match targets where `key` is present.
|
||||
- `absent(key)`: Match targets where `key` is not present.
|
||||
- `contains(key, value)`: Match targets where `key` contains `value`. Can be used for strings, arrays and object keys.
|
||||
@@ -175,7 +181,7 @@ The following filter expressions are also supported:
|
||||
You can also list arbitrary values for each matched target with `--print`:
|
||||
|
||||
```
|
||||
qmk find -f 'processor=STM32F411' -p 'keyboard_name' -p 'features.rgb_matrix'
|
||||
qmk find -f 'processor==STM32F411' -p 'keyboard_name' -p 'features.rgb_matrix'
|
||||
```
|
||||
|
||||
**Usage**:
|
||||
|
@@ -57,6 +57,10 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s
|
||||
* [WB32F3G71xx](http://www.westberrytech.com)
|
||||
* [WB32FQ95xx](http://www.westberrytech.com)
|
||||
|
||||
### Artery (AT32)
|
||||
|
||||
* [AT32F415](https://www.arterychip.com/en/product/AT32F415.jsp)
|
||||
|
||||
### NXP (Kinetis)
|
||||
|
||||
* [MKL26Z64](https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/kl-series-cortex-m0-plus/kinetis-kl2x-72-96-mhz-usb-ultra-low-power-microcontrollers-mcus-based-on-arm-cortex-m0-plus-core:KL2x)
|
||||
@@ -75,10 +79,6 @@ You can also use any ARM chip with USB that [ChibiOS](https://www.chibios.org) s
|
||||
|
||||
For a detailed overview about the RP2040 support by QMK see the [dedicated RP2040 page](platformdev_rp2040).
|
||||
|
||||
## Atmel ATSAM
|
||||
|
||||
There is limited support for one of Atmel's ATSAM microcontrollers, that being the [ATSAMD51J18A](https://www.microchip.com/wwwproducts/en/ATSAMD51J18A) used by the [Massdrop keyboards](https://github.com/qmk/qmk_firmware/tree/master/keyboards/massdrop). However, it is not recommended to design a board with this microcontroller as the support is quite specialized to Massdrop hardware.
|
||||
|
||||
## RISC-V
|
||||
|
||||
### GigaDevice
|
||||
|
@@ -413,7 +413,7 @@ Use these to enable or disable building certain features. The more you have enab
|
||||
* `MAGIC_ENABLE`
|
||||
* MAGIC actions (BOOTMAGIC without the boot)
|
||||
* `BOOTMAGIC_ENABLE`
|
||||
* Enable Bootmagic Lite
|
||||
* Enable Bootmagic
|
||||
* `MOUSEKEY_ENABLE`
|
||||
* Mouse keys
|
||||
* `EXTRAKEY_ENABLE`
|
||||
@@ -426,8 +426,6 @@ Use these to enable or disable building certain features. The more you have enab
|
||||
* Key combo feature
|
||||
* `NKRO_ENABLE`
|
||||
* USB N-Key Rollover - if this doesn't work, see here: https://github.com/tmk/tmk_keyboard/wiki/FAQ#nkro-doesnt-work
|
||||
* `RING_BUFFERED_6KRO_REPORT_ENABLE`
|
||||
* USB 6-Key Rollover - Instead of stopping any new input once 6 keys are pressed, the oldest key is released and the new key is pressed.
|
||||
* `AUDIO_ENABLE`
|
||||
* Enable the audio subsystem.
|
||||
* `KEY_OVERRIDE_ENABLE`
|
||||
|
@@ -54,7 +54,7 @@ const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
||||
KC_LCTL, KC_LGUI, KC_LALT, KC_SPC, KC_RALT, MO(1), KC_RGUI, KC_RCTL, KC_LEFT, KC_DOWN, KC_RGHT),
|
||||
|
||||
[1] = LAYOUT_all(
|
||||
KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, RGB_TOG, RGB_MOD, RGB_HUD, RGB_HUI, RGB_SAD, RGB_SAI, RGB_VAD, RGB_VAI, BL_TOGG, BL_DOWN, BL_UP,
|
||||
KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, UG_TOGG, UG_NEXT, UG_HUED, UG_HUEU, UG_SATD, UG_SATU, UG_VALD, UG_VALU, BL_TOGG, BL_DOWN, BL_UP,
|
||||
KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_VOLU,
|
||||
KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, QK_BOOT, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_MPLY, KC_MNXT, KC_VOLD,
|
||||
KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS,
|
||||
@@ -82,7 +82,7 @@ The default keymap uses the `LAYOUT_all` macro, so that will be the value of the
|
||||
"KC_LCTL", "KC_LGUI", "KC_LALT", "KC_SPC", "KC_RALT", "MO(1)", "KC_RGUI", "KC_RCTL", "KC_LEFT", "KC_DOWN", "KC_RGHT"
|
||||
],
|
||||
[
|
||||
"KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "RGB_TOG", "RGB_MOD", "RGB_HUD", "RGB_HUI", "RGB_SAD", "RGB_SAI", "RGB_VAD", "RGB_VAI", "BL_TOGG", "BL_DOWN", "BL_UP",
|
||||
"KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "UG_TOGG", "UG_NEXT", "UG_HUED", "UG_HUEU", "UG_SATD", "UG_SATU", "UG_VALD", "UG_VALU", "BL_TOGG", "BL_DOWN", "BL_UP",
|
||||
"KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_VOLU",
|
||||
"KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "QK_BOOT", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_MPLY", "KC_MNXT", "KC_VOLD",
|
||||
"KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS",
|
||||
|
@@ -11,7 +11,7 @@ Third-party contributions help us grow and improve QMK. We want to make the pull
|
||||
|
||||
## I Don't Want to Read This Whole Thing! I Just Have a Question!
|
||||
|
||||
If you'd like to ask questions about QMK you can do so on the [OLKB Subreddit](https://reddit.com/r/olkb) or on [Discord](https://discord.gg/Uq7gcHh).
|
||||
If you'd like to ask questions about QMK you can do so on the [OLKB Subreddit](https://reddit.com/r/olkb) or on [Discord](https://discord.gg/qmk).
|
||||
|
||||
Please keep these things in mind:
|
||||
|
||||
@@ -29,7 +29,7 @@ QMK is largely written in C, with specific features and parts written in C++. It
|
||||
|
||||
# Where Can I Go for Help?
|
||||
|
||||
If you need help you can [open an issue](https://github.com/qmk/qmk_firmware/issues) or [chat on Discord](https://discord.gg/Uq7gcHh).
|
||||
If you need help you can [open an issue](https://github.com/qmk/qmk_firmware/issues) or [chat on Discord](https://discord.gg/qmk).
|
||||
|
||||
# How Do I Make a Contribution?
|
||||
|
||||
@@ -128,7 +128,7 @@ We also ask that you follow these guidelines:
|
||||
|
||||
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)
|
||||
* [Chat on Discord](https://discord.gg/qmk)
|
||||
* [Open an Issue](https://github.com/qmk/qmk_firmware/issues/new)
|
||||
|
||||
Feature and Bug Fix PRs affect all keyboards. We are also in the process of restructuring QMK. For this reason it is especially important for significant changes to be discussed before implementation has happened. If you open a PR without talking to us first please be prepared to do some significant rework if your choices do not mesh well with our planned direction.
|
||||
|
@@ -184,7 +184,7 @@ Whenever possible you should customize your keyboard by using `process_record_*(
|
||||
|
||||
### Example `matrix_scan_*` Implementation
|
||||
|
||||
This example has been deliberately omitted. You should understand enough about QMK internals to write this without an example before hooking into such a performance sensitive area. If you need help please [open an issue](https://github.com/qmk/qmk_firmware/issues/new) or [chat with us on Discord](https://discord.gg/Uq7gcHh).
|
||||
This example has been deliberately omitted. You should understand enough about QMK internals to write this without an example before hooking into such a performance sensitive area. If you need help please [open an issue](https://github.com/qmk/qmk_firmware/issues/new) or [chat with us on Discord](https://discord.gg/qmk).
|
||||
|
||||
### `matrix_scan_*` Function Documentation
|
||||
|
||||
|
@@ -8,8 +8,8 @@ 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](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.
|
||||
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](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](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.
|
||||
@@ -98,6 +98,7 @@ The device name here is the name that appears in Zadig, and may not be what the
|
||||
|`bootloadhid` |HIDBoot |`16C0:05DF` |HidUsb |
|
||||
|`usbasploader`|USBasp |`16C0:05DC` |libusbK|
|
||||
|`apm32-dfu` |APM32 DFU ISP Mode |`314B:0106` |WinUSB |
|
||||
|`at32-dfu` |AT32 Bootloader DFU |`2E3C:DF11` |WinUSB |
|
||||
|`stm32-dfu` |STM32 BOOTLOADER |`0483:DF11` |WinUSB |
|
||||
|`gd32v-dfu` |GD32V BOOTLOADER |`28E9:0189` |WinUSB |
|
||||
|`kiibohd` |Kiibohd DFU Bootloader |`1C11:B007` |WinUSB |
|
||||
|
@@ -57,27 +57,32 @@ This driver needs one Timer per enabled/used DAC channel, to trigger conversion;
|
||||
|
||||
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
|
||||
::: code-group
|
||||
```c [halconf.h]
|
||||
#pragma once
|
||||
|
||||
#define HAL_USE_DAC TRUE // [!code focus]
|
||||
#define HAL_USE_GPT TRUE // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
```c [mcuconf.h]
|
||||
#pragma once
|
||||
|
||||
```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
|
||||
|
||||
#undef STM32_DAC_USE_DAC1_CH1 // [!code focus]
|
||||
#define STM32_DAC_USE_DAC1_CH1 TRUE // [!code focus]
|
||||
#undef STM32_DAC_USE_DAC1_CH2 // [!code focus]
|
||||
#define STM32_DAC_USE_DAC1_CH2 TRUE // [!code focus]
|
||||
#undef STM32_GPT_USE_TIM6 // [!code focus]
|
||||
#define STM32_GPT_USE_TIM6 TRUE // [!code focus]
|
||||
#undef STM32_GPT_USE_TIM7 // [!code focus]
|
||||
#define STM32_GPT_USE_TIM7 TRUE // [!code focus]
|
||||
#undef STM32_GPT_USE_TIM8 // [!code focus]
|
||||
#define STM32_GPT_USE_TIM8 TRUE // [!code focus]
|
||||
```
|
||||
:::
|
||||
|
||||
::: tip
|
||||
Note: DAC1 (A4) uses TIM6, DAC2 (A5) uses TIM7, and the audio state timer uses TIM8 (configurable).
|
||||
@@ -95,23 +100,28 @@ only needs one timer (GPTD6, Tim6) to trigger the DAC unit to do a conversion; t
|
||||
|
||||
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
|
||||
::: code-group
|
||||
```c [halconf.h]
|
||||
#pragma once
|
||||
|
||||
#define HAL_USE_DAC TRUE // [!code focus]
|
||||
#define HAL_USE_GPT TRUE // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
```c [mcuconf.h]
|
||||
#pragma once
|
||||
|
||||
```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_DAC_USE_DAC1_CH1 // [!code focus]
|
||||
#define STM32_DAC_USE_DAC1_CH1 TRUE // [!code focus]
|
||||
#undef STM32_DAC_USE_DAC1_CH2 // [!code focus]
|
||||
#define STM32_DAC_USE_DAC1_CH2 TRUE // [!code focus]
|
||||
#undef STM32_GPT_USE_TIM6 // [!code focus]
|
||||
#define STM32_GPT_USE_TIM6 TRUE // [!code focus]
|
||||
```
|
||||
:::
|
||||
|
||||
### DAC Config
|
||||
|
||||
@@ -170,19 +180,25 @@ This driver uses the ChibiOS-PWM system to produce a square-wave on specific out
|
||||
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
|
||||
|
||||
::: code-group
|
||||
```c [halconf.h]
|
||||
#pragma once
|
||||
|
||||
#define HAL_USE_PWM TRUE // [!code focus]
|
||||
#define HAL_USE_PAL TRUE // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
```c [mcuconf.h]
|
||||
#pragma once
|
||||
|
||||
```c
|
||||
// mcuconf.h:
|
||||
#include_next <mcuconf.h>
|
||||
#undef STM32_PWM_USE_TIM1
|
||||
#define STM32_PWM_USE_TIM1 TRUE
|
||||
|
||||
#undef STM32_PWM_USE_TIM1 // [!code focus]
|
||||
#define STM32_PWM_USE_TIM1 TRUE // [!code focus]
|
||||
```
|
||||
:::
|
||||
|
||||
If we now target pin A8, looking through the data-sheet of the STM32F103C8, for the timers and alternate functions
|
||||
- TIM1_CH1 = PA8 <- alternate0
|
||||
|
@@ -13,7 +13,7 @@ The following macros provide basic control of GPIOs and are found in `platforms/
|
||||
|`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_set_pin_output_open_drain(pin)`|Set pin as output, open-drain mode (unavailable on AVR) |
|
||||
|`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 |
|
||||
|
@@ -54,18 +54,25 @@ The ATmega16/32U2 does not possess I2C functionality, and so cannot use this dri
|
||||
|
||||
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:
|
||||
To enable I2C, modify your board's `halconf.h` to enable I2C, then modify your board's `mcuconf.h` to enable the peripheral you've chosen:
|
||||
|
||||
```c
|
||||
#define HAL_USE_I2C TRUE
|
||||
::: code-group
|
||||
```c [halconf.h]
|
||||
#pragma once
|
||||
|
||||
#define HAL_USE_I2C TRUE // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
```c [mcuconf.h]
|
||||
#pragma once
|
||||
|
||||
Then, modify your board's `mcuconf.h` to enable the peripheral you've chosen, for example:
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
```c
|
||||
#undef STM32_I2C_USE_I2C2
|
||||
#define STM32_I2C_USE_I2C2 TRUE
|
||||
#undef STM32_I2C_USE_I2C2 // [!code focus]
|
||||
#define STM32_I2C_USE_I2C2 TRUE // [!code focus]
|
||||
```
|
||||
:::
|
||||
|
||||
|`mcuconf.h` Setting |Description |Default|
|
||||
|----------------------------|----------------------------------------------------------------------------------|-------|
|
||||
|
@@ -12,8 +12,6 @@ The Serial driver powers the [Split Keyboard](../features/split_keyboard) featur
|
||||
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.
|
||||
@@ -53,11 +51,15 @@ SERIAL_DRIVER = bitbang
|
||||
#define SOFT_SERIAL_PIN D0 // or D1, D2, D3, E6
|
||||
```
|
||||
|
||||
3. On ARM platforms you must turn on ChibiOS `PAL_USE_CALLBACKS` feature:
|
||||
3. On ARM platforms you must turn on ChibiOS PAL callbacks:
|
||||
|
||||
* In `halconf.h` add the line `#define PAL_USE_CALLBACKS TRUE`.
|
||||
```c
|
||||
#pragma once
|
||||
|
||||
<hr>
|
||||
#define PAL_USE_CALLBACKS TRUE // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
|
||||
## USART Half-duplex
|
||||
|
||||
@@ -117,8 +119,6 @@ For STM32 MCUs several GPIO configuration options can be changed as well. See th
|
||||
|
||||
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.
|
||||
@@ -179,38 +179,46 @@ For STM32 MCUs several GPIO configuration options, including the ability for `TX
|
||||
|
||||
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:
|
||||
1. Enable the SERIAL subsystem in the ChibiOS HAL.
|
||||
|
||||
```c
|
||||
#define HAL_USE_SERIAL TRUE
|
||||
```
|
||||
Add the following to your keyboard's `halconf.h`, creating it if necessary:
|
||||
|
||||
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
|
||||
#pragma once
|
||||
|
||||
```c
|
||||
#include_next <mcuconf.h>
|
||||
#define HAL_USE_SERIAL TRUE // [!code focus]
|
||||
|
||||
#undef STM32_SERIAL_USE_USARTn
|
||||
#define STM32_SERIAL_USE_USARTn TRUE
|
||||
```
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
|
||||
Where 'n' matches the peripheral number of your selected USART on the MCU.
|
||||
2. 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.
|
||||
|
||||
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`.
|
||||
Add the following to your keyboard's `mcuconf.h`, creating it if necessary:
|
||||
|
||||
```c
|
||||
#define SERIAL_USART_DRIVER SD3
|
||||
```
|
||||
```c
|
||||
#pragma once
|
||||
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
#undef STM32_SERIAL_USE_USARTn // [!code focus]
|
||||
#define STM32_SERIAL_USE_USARTn TRUE // [!code focus]
|
||||
```
|
||||
|
||||
Where *n* matches the peripheral number of your selected USART on the MCU.
|
||||
|
||||
3. 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`.
|
||||
|
||||
Add the following to your keyboard's `config.h`:
|
||||
|
||||
```c
|
||||
#define SERIAL_USART_DRIVER SD3
|
||||
```
|
||||
|
||||
### The `SIO` driver
|
||||
|
||||
@@ -218,31 +226,41 @@ The `SIO` Subsystem was added to ChibiOS with the 21.11 release and is only supp
|
||||
|
||||
Follow these steps in order to activate it:
|
||||
|
||||
1. In your keyboards `halconf.h` add:
|
||||
1. Enable the SIO subsystem in the ChibiOS HAL.
|
||||
|
||||
```c
|
||||
#define HAL_USE_SIO TRUE
|
||||
```
|
||||
Add the following to your keyboard's `halconf.h`, creating it if necessary:
|
||||
|
||||
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
|
||||
#pragma once
|
||||
|
||||
```c
|
||||
#include_next <mcuconf.h>
|
||||
#define HAL_USE_SIO TRUE // [!code focus]
|
||||
|
||||
#undef STM32_SIO_USE_USARTn
|
||||
#define STM32_SIO_USE_USARTn TRUE
|
||||
```
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
|
||||
Where 'n' matches the peripheral number of your selected USART on the MCU.
|
||||
2. 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.
|
||||
|
||||
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`.
|
||||
Add the following to your keyboard's `mcuconf.h`, creating it if necessary:
|
||||
|
||||
```c
|
||||
#pragma once
|
||||
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
#undef STM32_SIO_USE_USARTn // [!code focus]
|
||||
#define STM32_SIO_USE_USARTn TRUE // [!code focus]
|
||||
```
|
||||
|
||||
Where *n* matches the peripheral number of your selected USART on the MCU.
|
||||
|
||||
3. 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`.
|
||||
|
||||
Add the following to your keyboard's `config.h`:
|
||||
|
||||
```c
|
||||
#define SERIAL_USART_DRIVER 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**.
|
||||
@@ -254,8 +272,6 @@ Optionally, the PIO peripheral utilized for split communication can be changed w
|
||||
|
||||
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:
|
||||
@@ -265,9 +281,11 @@ There are several advanced configuration options that can be defined in your key
|
||||
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 {#}
|
||||
#define SELECT_SOFT_SERIAL_SPEED n
|
||||
```
|
||||
|
||||
Where *n* is one of:
|
||||
|
||||
| Speed | Bitbang | Half-duplex and Full-duplex |
|
||||
| ----- | -------------------------- | --------------------------- |
|
||||
| `0` | 189000 baud (experimental) | 460800 baud |
|
||||
@@ -287,8 +305,6 @@ This is the default time window in milliseconds in which a successful communicat
|
||||
#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:
|
||||
|
@@ -32,20 +32,27 @@ You may use more than one slave select pin, not just the `SS` pin. This is usefu
|
||||
|
||||
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:
|
||||
To enable SPI, modify your board's `halconf.h` to enable SPI, then modify your board's `mcuconf.h` to enable the peripheral you've chosen:
|
||||
|
||||
```c
|
||||
#define HAL_USE_SPI TRUE
|
||||
#define SPI_USE_WAIT TRUE
|
||||
#define SPI_SELECT_MODE SPI_SELECT_MODE_PAD
|
||||
::: code-group
|
||||
```c [halconf.h]
|
||||
#pragma once
|
||||
|
||||
#define HAL_USE_SPI TRUE // [!code focus]
|
||||
#define SPI_USE_WAIT TRUE // [!code focus]
|
||||
#define SPI_SELECT_MODE SPI_SELECT_MODE_PAD // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
```c [mcuconf.h]
|
||||
#pragma once
|
||||
|
||||
Then, modify your board's `mcuconf.h` to enable the peripheral you've chosen, for example:
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
```c
|
||||
#undef STM32_SPI_USE_SPI2
|
||||
#define STM32_SPI_USE_SPI2 TRUE
|
||||
#undef STM32_SPI_USE_SPI2 // [!code focus]
|
||||
#define STM32_SPI_USE_SPI2 TRUE // [!code focus]
|
||||
```
|
||||
:::
|
||||
|
||||
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.
|
||||
|
||||
|
@@ -35,8 +35,12 @@ You'll need to determine which pins can be used for UART -- as an example, STM32
|
||||
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
|
||||
#pragma once
|
||||
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
#undef STM32_SERIAL_USE_USART2 // [!code focus]
|
||||
#define STM32_SERIAL_USE_USART2 TRUE // [!code focus]
|
||||
```
|
||||
|
||||
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.
|
||||
|
@@ -160,15 +160,23 @@ To configure the DI pin for open drain configuration, add the following to your
|
||||
|
||||
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
|
||||
::: code-group
|
||||
```c [halconf.h]
|
||||
#pragma once
|
||||
|
||||
#define HAL_USE_SPI TRUE // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
`mcuconf.h`:
|
||||
```c
|
||||
#undef STM32_SPI_USE_SPI1
|
||||
#define STM32_SPI_USE_SPI1 TRUE
|
||||
```c [mcuconf.h]
|
||||
#pragma once
|
||||
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
#undef STM32_SPI_USE_SPI1 // [!code focus]
|
||||
#define STM32_SPI_USE_SPI1 TRUE // [!code focus]
|
||||
```
|
||||
:::
|
||||
|
||||
The following `define`s apply only to the `spi` driver:
|
||||
|
||||
@@ -213,15 +221,23 @@ The following `#define`s apply only to the PIO 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
|
||||
::: code-group
|
||||
```c [halconf.h]
|
||||
#pragma once
|
||||
|
||||
#define HAL_USE_PWM TRUE // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
`mcuconf.h`:
|
||||
```c
|
||||
#undef STM32_PWM_USE_TIM2
|
||||
#define STM32_PWM_USE_TIM2 TRUE
|
||||
```c [mcuconf.h]
|
||||
#pragma once
|
||||
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
#undef STM32_PWM_USE_TIM2 // [!code focus]
|
||||
#define STM32_PWM_USE_TIM2 TRUE // [!code focus]
|
||||
```
|
||||
:::
|
||||
|
||||
The following `#define`s apply only to the `pwm` driver:
|
||||
|
||||
@@ -236,18 +252,49 @@ The following `#define`s apply only to the `pwm` driver:
|
||||
|`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.
|
||||
Using a complementary timer output (`TIMx_CHyN`) is possible only for advanced-control timers (1, 8 and 20 on STM32). 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}
|
||||
### `void ws2812_init(void)` {#api-ws2812-init}
|
||||
|
||||
Send RGB data to the WS2812 LED chain.
|
||||
Initialize the LED driver. This function should be called first.
|
||||
|
||||
#### 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.
|
||||
### `void ws2812_set_color(int index, uint8_t red, uint8_t green, uint8_t blue)` {#api-ws2812-set-color}
|
||||
|
||||
Set the color of a single LED. This function does not immediately update the LEDs; call `ws2812_flush()` after you are finished.
|
||||
|
||||
#### Arguments {#api-ws2812-set-color-arguments}
|
||||
|
||||
- `int index`
|
||||
The LED index in the WS2812 chain.
|
||||
- `uint8_t red`
|
||||
The red value to set.
|
||||
- `uint8_t green`
|
||||
The green value to set.
|
||||
- `uint8_t blue`
|
||||
The blue value to set.
|
||||
|
||||
---
|
||||
|
||||
### `void ws812_set_color_all(uint8_t red, uint8_t green, uint8_t blue)` {#api-ws2812-set-color-all}
|
||||
|
||||
Set the color of all LEDs.
|
||||
|
||||
#### Arguments {#api-ws2812-set-color-all-arguments}
|
||||
|
||||
- `uint8_t red`
|
||||
The red value to set.
|
||||
- `uint8_t green`
|
||||
The green value to set.
|
||||
- `uint8_t blue`
|
||||
The blue value to set.
|
||||
|
||||
---
|
||||
|
||||
### `void ws2812_flush(void)` {#api-ws2812-flush}
|
||||
|
||||
Flush the PWM values to the LED chain.
|
||||
|
@@ -40,7 +40,7 @@ That's amazing! We would love to assist you with that!
|
||||
|
||||
In fact, we have a [whole page](https://qmk.fm/powered/) dedicated to adding QMK Branding to your page and keyboard. This covers pretty much everything you need (knowledge and images) to officially support QMK.
|
||||
|
||||
If you have any questions about this, open an issue or head to [Discord](https://discord.gg/Uq7gcHh).
|
||||
If you have any questions about this, open an issue or head to [Discord](https://discord.gg/qmk).
|
||||
|
||||
## What Differences Are There Between QMK and TMK?
|
||||
|
||||
|
@@ -34,7 +34,7 @@ On first run, the VIA code in the firmware will copy the keymap from flash memor
|
||||
|
||||
The simple fix for this is to clear the EEPROM. You can do this in several ways:
|
||||
|
||||
* Hold the Bootmagic Lite key (usually top left/Escape) while plugging the board in, which will also place the board into bootloader mode; then unplug and replug the board.
|
||||
* Hold the Bootmagic key (usually top left/Escape) while plugging the board in, which will also place the board into bootloader mode; then unplug and replug the board.
|
||||
* Press the `QK_CLEAR_EEPROM`/`EE_CLR` keycode if it is accessible on your keymap.
|
||||
* Place the board into bootloader mode and hit the "Clear EEPROM" button. This may not be available for all bootloaders, and you may need to reflash the board afterwards.
|
||||
|
||||
|
@@ -11,7 +11,7 @@ These allow you to combine a modifier with a keycode. When pressed, the keydown
|
||||
|`RCTL(kc)`| |Hold Right Control and press `kc` |
|
||||
|`RSFT(kc)`| |Hold Right Shift and press `kc` |
|
||||
|`RALT(kc)`|`ROPT(kc)`, `ALGR(kc)` |Hold Right Alt and press `kc` |
|
||||
|`RGUI(kc)`|`RCMD(kc)`, `LWIN(kc)` |Hold Right GUI and press `kc` |
|
||||
|`RGUI(kc)`|`RCMD(kc)`, `RWIN(kc)` |Hold Right GUI and press `kc` |
|
||||
|`LSG(kc)` |`SGUI(kc)`, `SCMD(kc)`, `SWIN(kc)`|Hold Left Shift and GUI and press `kc` |
|
||||
|`LAG(kc)` | |Hold Left Alt and Left GUI and press `kc` |
|
||||
|`RSG(kc)` | |Hold Right Shift and Right GUI and press `kc` |
|
||||
|
@@ -21,6 +21,7 @@ The following converters are available at this time:
|
||||
| `promicro` | `liatris` |
|
||||
| `promicro` | `imera` |
|
||||
| `promicro` | `michi` |
|
||||
| `promicro` | `svlinky` |
|
||||
| `elite_c` | `stemcell` |
|
||||
| `elite_c` | `rp2040_ce` |
|
||||
| `elite_c` | `elite_pi` |
|
||||
@@ -87,6 +88,7 @@ If a board currently supported in QMK uses a [Pro Micro](https://www.sparkfun.co
|
||||
| [Liatris](https://splitkb.com/products/liatris) | `liatris` |
|
||||
| [Imera](https://splitkb.com/products/imera) | `imera` |
|
||||
| [Michi](https://github.com/ci-bus/michi-promicro-rp2040) | `michi` |
|
||||
| [Svlinky](https://github.com/sadekbaroudi/svlinky) | `svlinky` |
|
||||
|
||||
Converter summary:
|
||||
|
||||
@@ -105,6 +107,7 @@ Converter summary:
|
||||
| `liatris` | `-e CONVERT_TO=liatris` | `CONVERT_TO=liatris` | `#ifdef CONVERT_TO_LIATRIS` |
|
||||
| `imera` | `-e CONVERT_TO=imera` | `CONVERT_TO=imera` | `#ifdef CONVERT_TO_IMERA` |
|
||||
| `michi` | `-e CONVERT_TO=michi` | `CONVERT_TO=michi` | `#ifdef CONVERT_TO_MICHI` |
|
||||
| `svlinky` | `-e CONVERT_TO=svlinky` | `CONVERT_TO=svlinky` | `#ifdef CONVERT_TO_SVLINKY` |
|
||||
|
||||
### Proton C {#proton_c}
|
||||
|
||||
@@ -170,6 +173,9 @@ The Bonsai C4 only has one on-board LED (B2), and by default, both the Pro Micro
|
||||
|
||||
Feature set is identical to [Adafruit KB2040](#kb2040). VBUS detection is enabled by default for superior split keyboard support. For more information, refer to the [Community Edition pinout](platformdev_rp2040#rp2040_ce) docs.
|
||||
|
||||
### Svlinky {#svlinky}
|
||||
|
||||
Feature set is a pro micro equivalent of the [RP2040 Community Edition](#rp2040_ce), except that two of the analog GPIO have been replaced with digital only GPIO. These two were moved to the FPC connector to support the [VIK specification](https://github.com/sadekbaroudi/vik). This means that if you are expecting analog support on all 4 pins as provided on a RP2040 Community Edition pinout, you will not have that. Please see the [Svlinky github page](https://github.com/sadekbaroudi/svlinky) for more details.
|
||||
|
||||
## Elite-C
|
||||
|
||||
|
@@ -109,7 +109,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
|
||||
}
|
||||
}
|
||||
```
|
||||
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EE_CLR` keycode or [Bootmagic Lite](features/bootmagic) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
|
||||
And lastly, you want to add the `eeconfig_init_user` function, so that when the EEPROM is reset, you can specify default values, and even custom actions. To force an EEPROM reset, use the `EE_CLR` keycode or [Bootmagic](features/bootmagic) functionallity. For example, if you want to set rgb layer indication by default, and save the default valued.
|
||||
|
||||
```c
|
||||
void eeconfig_init_user(void) { // EEPROM is getting reset!
|
||||
|
@@ -8,7 +8,8 @@ For a detailed explanation of how the layer stack works, checkout [Keymap Overvi
|
||||
|
||||
These functions allow you to activate layers in various ways. Note that layers are not generally independent layouts -- multiple layers can be activated at once, and it's typical for layers to use `KC_TRNS` to allow keypresses to pass through to lower layers. When using momentary layer switching with MO(), LM(), TT(), or LT(), make sure to leave the key on the above layers transparent or it may not work as intended.
|
||||
|
||||
* `DF(layer)` - switches the default layer. The default layer is the always-active base layer that other layers stack on top of. See below for more about the default layer. This might be used to switch from QWERTY to Dvorak layout. (Note that this is a temporary switch that only persists until the keyboard loses power. To modify the default layer in a persistent way requires deeper customization, such as calling the `set_single_persistent_default_layer` function inside of [process_record_user](custom_quantum_functions#programming-the-behavior-of-any-keycode).)
|
||||
* `DF(layer)` - switches the default layer. The default layer is the always-active base layer that other layers stack on top of. See below for more about the default layer. This might be used to switch from QWERTY to Dvorak layout. Note that this is a temporary switch that only persists until the keyboard loses power.
|
||||
* `PDF(layer)` - sets a persistent default layer. This switch, which will last through a power loss, might be used to switch from QWERTY to Dvorak layout and only switch again when you want to.
|
||||
* `MO(layer)` - momentarily activates *layer*. As soon as you let go of the key, the layer is deactivated.
|
||||
* `LM(layer, mod)` - Momentarily activates *layer* (like `MO`), but with modifier(s) *mod* active. Only supports layers 0-15. The modifiers this keycode accept are prefixed with `MOD_`, not `KC_`. These modifiers can be combined using bitwise OR, e.g. `LM(_RAISE, MOD_LCTL | MOD_LALT)`.
|
||||
* `LT(layer, kc)` - momentarily activates *layer* when held, and sends *kc* when tapped. Only supports layers 0-15.
|
||||
@@ -17,6 +18,9 @@ These functions allow you to activate layers in various ways. Note that layers a
|
||||
* `TO(layer)` - activates *layer* and de-activates all other layers (except your default layer). This function is special, because instead of just adding/removing one layer to your active layer stack, it will completely replace your current active layers, uniquely allowing you to replace higher layers with a lower one. This is activated on keydown (as soon as the key is pressed).
|
||||
* `TT(layer)` - Layer Tap-Toggle. If you hold the key down, *layer* is activated, and then is de-activated when you let go (like `MO`). If you repeatedly tap it, the layer will be toggled on or off (like `TG`). It needs 5 taps by default, but you can change this by defining `TAPPING_TOGGLE` -- for example, `#define TAPPING_TOGGLE 2` to toggle on just two taps.
|
||||
|
||||
See also the [Layer Lock key](features/layer_lock), which locks the highest
|
||||
active layer until pressed again.
|
||||
|
||||
### Caveats {#caveats}
|
||||
|
||||
Currently, the `layer` argument of `LT()` is limited to layers 0-15, and the `kc` argument to the [Basic Keycode set](keycodes_basic), meaning you can't use keycodes like `LCTL()`, `KC_TILD`, or anything greater than `0xFF`. This is because QMK uses 16-bit keycodes, of which 4 bits are used for the function identifier and 4 bits for the layer, leaving only 8 bits for the keycode.
|
||||
@@ -74,6 +78,7 @@ There are a number of functions (and variables) related to how you can use or ma
|
||||
| `default_layer_and(layer_mask)` | Turns on layers based on matching enabled bits between specifed layer and existing default layer state. |
|
||||
| `default_layer_xor(layer_mask)` | Turns on layers based on non-matching bits between specifed layer and existing default layer state. |
|
||||
| `default_layer_debug(layer_mask)` | Prints out the current bit mask and highest active default layer to debugger console. |
|
||||
| [`set_single_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer) | Sets the default layer, but does _not_ write it to persistent memory (EEPROM). |
|
||||
| [`set_single_persistent_default_layer(layer)`](ref_functions.md#setting-the-persistent-default-layer) | Sets the default layer and writes it to persistent memory (EEPROM). |
|
||||
| [`update_tri_layer(x, y, z)`](ref_functions.md#update_tri_layerx-y-z) | Checks if layers `x` and `y` are both on, and sets `z` based on that (on if both on, otherwise off). |
|
||||
| [`update_tri_layer_state(state, x, y, z)`](ref_functions.md#update_tri_layer_statestate-x-y-z) | Does the same as `update_tri_layer(x, y, z)`, but from `layer_state_set_*` functions. |
|
||||
|
@@ -42,38 +42,7 @@ You can define up to 32 macros in a `keymap.json` file, as used by [Configurator
|
||||
|
||||
### Selecting Your Host Keyboard Layout
|
||||
|
||||
If you type in a language other than English, or use a non-QWERTY layout like Colemak, Dvorak, or Workman, you may have set your computer's input language to match this layout. This presents a challenge when creating macros - you may need to type different keys to get the same letters! To address this you can add the `host_language` key to your `keymap.json`, like so:
|
||||
|
||||
```json
|
||||
{
|
||||
"keyboard": "handwired/my_macropad",
|
||||
"keymap": "my_keymap",
|
||||
"host_language": "dvorak",
|
||||
"macros": [
|
||||
["Hello, World!"]
|
||||
],
|
||||
"layout": "LAYOUT_all",
|
||||
"layers": [
|
||||
["QK_MACRO_0"]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The current list of available languages is:
|
||||
|
||||
| belgian | bepo | br_abnt2 | canadian_multilingual |
|
||||
|:-------:|:----:|:--------:|:---------------------:|
|
||||
| **colemak** | **croatian** | **czech** | **danish** |
|
||||
| **dvorak_fr** | **dvorak** | **dvp** | **estonian** |
|
||||
| **finnish** | **fr_ch** | **french_afnor** | **french** |
|
||||
| **french_osx** | **german_ch** | **german** | **german_osx** |
|
||||
| **hungarian** | **icelandic** | **italian** | **italian_osx_ansi** |
|
||||
| **italian_osx_iso** | **jis** | **latvian** | **lithuanian_azerty** |
|
||||
| **lithuanian_qwerty** | **norman** | **norwegian** | **portuguese** |
|
||||
| **portuguese_osx_iso** | **romanian** | **serbian_latin** | **slovak** |
|
||||
| **slovenian** | **spanish_dvorak** | **spanish_latin_america** | **spanish** |
|
||||
| **swedish** | **turkish_f** | **turkish_q** | **uk** |
|
||||
| **us_international** | **workman** | **workman_zxcvm** |
|
||||
If you type in a language other than English, or use a non-QWERTY layout like Colemak, Dvorak, or Workman, you may have set your computer's input language to match this layout. This presents a challenge when creating macros — you may need to type different keys to get the same letters! To address this you can use [language-specific keycodes](reference_keymap_extras).
|
||||
|
||||
### Macro Basics
|
||||
|
||||
|
@@ -161,15 +161,23 @@ Note that the choice of timer may conflict with the [Audio](audio) feature.
|
||||
|
||||
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
|
||||
::: code-group
|
||||
```c [halconf.h]
|
||||
#pragma once
|
||||
|
||||
#define HAL_USE_PWM TRUE // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
`mcuconf.h`:
|
||||
```c
|
||||
#undef STM32_PWM_USE_TIM4
|
||||
#define STM32_PWM_USE_TIM4 TRUE
|
||||
```c [mcuconf.h]
|
||||
#pragma once
|
||||
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
#undef STM32_PWM_USE_TIM4 // [!code focus]
|
||||
#define STM32_PWM_USE_TIM4 TRUE // [!code focus]
|
||||
```
|
||||
:::
|
||||
|
||||
The following `#define`s apply only to the `pwm` driver:
|
||||
|
||||
@@ -187,15 +195,23 @@ Refer to the ST datasheet for your particular MCU to determine these values. For
|
||||
|
||||
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
|
||||
::: code-group
|
||||
```c [halconf.h]
|
||||
#pragma once
|
||||
|
||||
#define HAL_USE_GPT TRUE // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
`mcuconf.h`:
|
||||
```c
|
||||
#undef STM32_GPT_USE_TIM15
|
||||
#define STM32_GPT_USE_TIM15 TRUE
|
||||
```c [mcuconf.h]
|
||||
#pragma once
|
||||
|
||||
#include_next <mcuconf.h>
|
||||
|
||||
#undef STM32_GPT_USE_TIM15 // [!code focus]
|
||||
#define STM32_GPT_USE_TIM15 TRUE // [!code focus]
|
||||
```
|
||||
:::
|
||||
|
||||
The following `#define`s apply only to the `timer` driver:
|
||||
|
||||
|
@@ -1,46 +0,0 @@
|
||||
# Bluetooth
|
||||
|
||||
## Bluetooth Known Supported Hardware
|
||||
|
||||
Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1, QMK has support for RN-42 modules. For more recent BLE protocols, currently only the Adafruit Bluefruit SPI Friend is directly supported. BLE is needed to connect to iOS devices. Note iOS does not support mouse input.
|
||||
|
||||
|Board |Bluetooth Protocol |Connection Type|rules.mk |Bluetooth Chip|
|
||||
|----------------------------------------------------------------|--------------------|---------------|---------------------------------|--------------|
|
||||
|Roving Networks RN-42 (Sparkfun Bluesmirf) |Bluetooth Classic |UART |`BLUETOOTH_DRIVER = rn42` |RN-42 |
|
||||
|[Bluefruit LE SPI Friend](https://www.adafruit.com/product/2633)|Bluetooth Low Energy|SPI |`BLUETOOTH_DRIVER = bluefruit_le`|nRF51822 |
|
||||
|
||||
Not Supported Yet but possible:
|
||||
* [Bluefruit LE UART Friend](https://www.adafruit.com/product/2479). [Possible tmk implementation found in](https://github.com/tmk/tmk_keyboard/issues/514)
|
||||
* HC-05 boards flashed with RN-42 firmware. They apparently both use the CSR BC417 Chip. Flashing it with RN-42 firmware gives it HID capability.
|
||||
* Sparkfun Bluetooth Mate
|
||||
* HM-13 based boards
|
||||
|
||||
### Adafruit BLE SPI Friend
|
||||
Currently The only bluetooth chipset supported by QMK is the Adafruit Bluefruit SPI Friend. It's a Nordic nRF51822 based chip running Adafruit's custom firmware. Data is transmitted via Adafruit's SDEP over Hardware SPI. The [Feather 32u4 Bluefruit LE](https://www.adafruit.com/product/2829) is supported as it's an AVR mcu connected via SPI to the Nordic BLE chip with Adafruit firmware. If Building a custom board with the SPI friend it would be easiest to just use the pin selection that the 32u4 feather uses but you can change the pins in the config.h options with the following defines:
|
||||
* `#define BLUEFRUIT_LE_RST_PIN D4`
|
||||
* `#define BLUEFRUIT_LE_CS_PIN B4`
|
||||
* `#define BLUEFRUIT_LE_IRQ_PIN E6`
|
||||
|
||||
A Bluefruit UART friend can be converted to an SPI friend, however this [requires](https://github.com/qmk/qmk_firmware/issues/2274) some reflashing and soldering directly to the MDBT40 chip.
|
||||
|
||||
<!-- FIXME: Document bluetooth support more completely. -->
|
||||
## Bluetooth Rules.mk Options
|
||||
|
||||
The currently supported Bluetooth chipsets do not support [N-Key Rollover (NKRO)](../reference_glossary#n-key-rollover-nkro), so `rules.mk` must contain `NKRO_ENABLE = no`.
|
||||
|
||||
Add the following to your `rules.mk`:
|
||||
|
||||
```make
|
||||
BLUETOOTH_ENABLE = yes
|
||||
BLUETOOTH_DRIVER = bluefruit_le # or rn42
|
||||
```
|
||||
|
||||
## Bluetooth Keycodes
|
||||
|
||||
This is used when multiple keyboard outputs can be selected. Currently this only allows for switching between USB and Bluetooth on keyboards that support both.
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|---------------------|---------|----------------------------------------------|
|
||||
|`QK_OUTPUT_AUTO` |`OU_AUTO`|Automatically switch between USB and Bluetooth|
|
||||
|`QK_OUTPUT_USB` |`OU_USB` |USB only |
|
||||
|`QK_OUTPUT_BLUETOOTH`|`OU_BT` |Bluetooth only |
|
@@ -152,14 +152,15 @@ In order to use these features, the following configuration options and function
|
||||
|
||||
| Config Flag | Function | Description |
|
||||
|-----------------------------|-----------------------------------------------------------|--------------------------------------------------------------------------------------------------------|
|
||||
| `COMBO_TERM_PER_COMBO` | uint16_t get_combo_term(uint16_t index, combo_t \*combo) | Optional per-combo timeout window. (default: `COMBO_TERM`) |
|
||||
| `COMBO_MUST_HOLD_PER_COMBO` | bool get_combo_must_hold(uint16_t index, combo_t \*combo) | Controls if a given combo should fire immediately on tap or if it needs to be held. (default: `false`) |
|
||||
| `COMBO_MUST_TAP_PER_COMBO` | bool get_combo_must_tap(uint16_t index, combo_t \*combo) | Controls if a given combo should fire only if tapped within `COMBO_HOLD_TERM`. (default: `false`) |
|
||||
| `COMBO_MUST_PRESS_IN_ORDER_PER_COMBO` | bool get_combo_must_press_in_order(uint16_t index, combo_t \*combo) | Controls if a given combo should fire only if its keys are pressed in order. (default: `true`) |
|
||||
| `COMBO_TERM_PER_COMBO` | `uint16_t get_combo_term(uint16_t combo_index, combo_t *combo)` | Optional per-combo timeout window. (default: `COMBO_TERM`) |
|
||||
| `COMBO_MUST_HOLD_PER_COMBO` | `bool get_combo_must_hold(uint16_t combo_index, combo_t *combo)` | Controls if a given combo should fire immediately on tap or if it needs to be held. (default: `false`) |
|
||||
| `COMBO_MUST_TAP_PER_COMBO` | `bool get_combo_must_tap(uint16_t combo_index, combo_t *combo)` | Controls if a given combo should fire only if tapped within `COMBO_HOLD_TERM`. (default: `false`) |
|
||||
| `COMBO_MUST_PRESS_IN_ORDER_PER_COMBO` | `bool get_combo_must_press_in_order(uint16_t combo_index, combo_t *combo)` | Controls if a given combo should fire only if its keys are pressed in order. (default: `true`) |
|
||||
|
||||
Examples:
|
||||
```c
|
||||
uint16_t get_combo_term(uint16_t index, combo_t *combo) {
|
||||
#ifdef COMBO_TERM_PER_COMBO
|
||||
uint16_t get_combo_term(uint16_t combo_index, combo_t *combo) {
|
||||
// decide by combo->keycode
|
||||
switch (combo->keycode) {
|
||||
case KC_X:
|
||||
@@ -167,7 +168,7 @@ uint16_t get_combo_term(uint16_t index, combo_t *combo) {
|
||||
}
|
||||
|
||||
// or with combo index, i.e. its name from enum.
|
||||
switch (index) {
|
||||
switch (combo_index) {
|
||||
case COMBO_NAME_HERE:
|
||||
return 9001;
|
||||
}
|
||||
@@ -182,8 +183,10 @@ uint16_t get_combo_term(uint16_t index, combo_t *combo) {
|
||||
|
||||
return COMBO_TERM;
|
||||
}
|
||||
#endif
|
||||
|
||||
bool get_combo_must_hold(uint16_t index, combo_t *combo) {
|
||||
#ifdef COMBO_MUST_HOLD_PER_COMBO
|
||||
bool get_combo_must_hold(uint16_t combo_index, combo_t *combo) {
|
||||
// Same as above, decide by keycode, the combo index, or by the keys in the chord.
|
||||
|
||||
if (KEYCODE_IS_MOD(combo->keycode) ||
|
||||
@@ -192,15 +195,17 @@ bool get_combo_must_hold(uint16_t index, combo_t *combo) {
|
||||
return true;
|
||||
}
|
||||
|
||||
switch (index) {
|
||||
switch (combo_index) {
|
||||
case COMBO_NAME_HERE:
|
||||
return true;
|
||||
}
|
||||
|
||||
return false;
|
||||
}
|
||||
#endif
|
||||
|
||||
bool get_combo_must_tap(uint16_t index, combo_t *combo) {
|
||||
#ifdef COMBO_MUST_TAP_PER_COMBO
|
||||
bool get_combo_must_tap(uint16_t combo_index, combo_t *combo) {
|
||||
// If you want all combos to be tap-only, just uncomment the next line
|
||||
// return true
|
||||
|
||||
@@ -219,7 +224,9 @@ bool get_combo_must_tap(uint16_t index, combo_t *combo) {
|
||||
return false;
|
||||
|
||||
}
|
||||
#endif
|
||||
|
||||
#ifdef COMBO_MUST_PRESS_IN_ORDER_PER_COMBO
|
||||
bool get_combo_must_press_in_order(uint16_t combo_index, combo_t *combo) {
|
||||
switch (combo_index) {
|
||||
/* List combos here that you want to only activate if their keys
|
||||
@@ -231,6 +238,7 @@ bool get_combo_must_press_in_order(uint16_t combo_index, combo_t *combo) {
|
||||
return false;
|
||||
}
|
||||
}
|
||||
#endif
|
||||
```
|
||||
|
||||
### Generic hook to (dis)allow a combo activation
|
||||
@@ -307,6 +315,50 @@ bool process_combo_key_release(uint16_t combo_index, combo_t *combo, uint8_t key
|
||||
return false;
|
||||
}
|
||||
```
|
||||
|
||||
### Customizable key repress
|
||||
By defining `COMBO_PROCESS_KEY_REPRESS` and implementing `bool process_combo_key_repress(uint16_t combo_index, combo_t *combo, uint8_t key_index, uint16_t keycode)` you can run your custom code when you repress just released key of a combo. By combining it with custom `process_combo_event` we can for example make special handling for Alt+Tab to switch windows, which, on combo F+G activation, registers Alt and presses Tab - then we can switch windows forward by releasing G and pressing it again, or backwards with F key. Here's the full example:
|
||||
|
||||
```c
|
||||
enum combos {
|
||||
CMB_ALTTAB
|
||||
};
|
||||
|
||||
const uint16_t PROGMEM combo_alttab[] = {KC_F, KC_G, COMBO_END};
|
||||
|
||||
combo_t key_combos[COMBO_LENGTH] = {
|
||||
[CMB_ALTTAB] = COMBO(combo_alttab, KC_NO), // KC_NO to leave processing for process_combo_event
|
||||
};
|
||||
|
||||
void process_combo_event(uint16_t combo_index, bool pressed) {
|
||||
switch (combo_index) {
|
||||
case CMB_ALTTAB:
|
||||
if (pressed) {
|
||||
register_mods(MOD_LALT);
|
||||
tap_code(KC_TAB);
|
||||
} else {
|
||||
unregister_mods(MOD_LALT);
|
||||
}
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
bool process_combo_key_repress(uint16_t combo_index, combo_t *combo, uint8_t key_index, uint16_t keycode) {
|
||||
switch (combo_index) {
|
||||
case CMB_ALTTAB:
|
||||
switch (keycode) {
|
||||
case KC_F:
|
||||
tap_code16(S(KC_TAB));
|
||||
return true;
|
||||
case KC_G:
|
||||
tap_code(KC_TAB);
|
||||
return true;
|
||||
}
|
||||
}
|
||||
return false;
|
||||
}
|
||||
```
|
||||
|
||||
### Layer independent combos
|
||||
|
||||
If you, for example, use multiple base layers for different key layouts, one for QWERTY, and another one for Colemak, you might want your combos to work from the same key positions on all layers. Defining the same combos again for another layout is redundant and takes more memory. The solution is to just check the keycodes from one layer.
|
||||
|
@@ -1,6 +1,6 @@
|
||||
# Command
|
||||
|
||||
Command, formerly known as Magic, is a way to change your keyboard's behavior without having to flash or unplug it to use [Bootmagic Lite](bootmagic). There is a lot of overlap between this functionality and the [Magic Keycodes](../keycodes_magic). Wherever possible we encourage you to use that feature instead of Command.
|
||||
Command, formerly known as Magic, is a way to change your keyboard's behavior without having to flash or unplug it to use [Bootmagic](bootmagic). There is a lot of overlap between this functionality and the [Magic Keycodes](../keycodes_magic). Wherever possible we encourage you to use that feature instead of Command.
|
||||
|
||||
On some keyboards Command is disabled by default. If this is the case, it must be explicitly enabled in your `rules.mk`:
|
||||
|
||||
|
@@ -1,6 +1,6 @@
|
||||
# Joystick {#joystick}
|
||||
|
||||
This feature provides game controller input as a joystick device supporting up to 6 axes and 32 buttons. Axes can be read either from an [ADC-capable input pin](../drivers/adc), or can be virtual, so that its value is provided by your code.
|
||||
This feature provides game controller input as a joystick device supporting up to 6 axes, 32 buttons and a hat switch. Axes can be read either from an [ADC-capable input pin](../drivers/adc), or can be virtual, so that its value is provided by your code.
|
||||
|
||||
An analog device such as a [potentiometer](https://en.wikipedia.org/wiki/Potentiometer) found on an analog joystick's axes is based on a voltage divider, where adjusting the movable wiper controls the output voltage which can then be read by the microcontroller's ADC.
|
||||
|
||||
@@ -18,6 +18,8 @@ By default the joystick driver is `analog`, but you can change this with:
|
||||
JOYSTICK_DRIVER = digital
|
||||
```
|
||||
|
||||
When using `analog` with ARM, [you must use 3.3v with your Joystick](../drivers/adc). Although ARM boards such as the [Helios](https://keeb.supply/products/0xcb-helios) have 5v pin output, the ADC driver does not support it.
|
||||
|
||||
## Configuration {#configuration}
|
||||
|
||||
By default, two axes and eight buttons are defined, with a reported resolution of 8 bits (-127 to +127). This can be changed in your `config.h`:
|
||||
@@ -35,6 +37,42 @@ By default, two axes and eight buttons are defined, with a reported resolution o
|
||||
You must define at least one button or axis. Also note that the maximum ADC resolution of the supported AVR MCUs is 10-bit, and 12-bit for most STM32 MCUs.
|
||||
:::
|
||||
|
||||
### Hat Switch {#hat-switch}
|
||||
|
||||
To enable the 8-way hat switch, add the following to your `config.h`:
|
||||
|
||||
```c
|
||||
#define JOYSTICK_HAS_HAT
|
||||
````
|
||||
|
||||
The position can be set by calling `joystick_set_hat(value)`. The range of values moves clockwise from the top (ie. north), with the default "center" position represented by a value of `-1`:
|
||||
|
||||
```
|
||||
0
|
||||
7 N 1
|
||||
NW .--'--. NE
|
||||
/ \
|
||||
6 W | -1 | E 2
|
||||
\ /
|
||||
SW '--.--' SE
|
||||
5 S 3
|
||||
4
|
||||
```
|
||||
|
||||
Alternatively you can use these predefined names:
|
||||
|
||||
|Define |Value|Angle|
|
||||
|------------------------|-----|-----|
|
||||
|`JOYSTICK_HAT_CENTER` |`-1` | |
|
||||
|`JOYSTICK_HAT_NORTH` |`0` |0° |
|
||||
|`JOYSTICK_HAT_NORTHEAST`|`1` |45° |
|
||||
|`JOYSTICK_HAT_EAST` |`2` |90° |
|
||||
|`JOYSTICK_HAT_SOUTHEAST`|`3` |135° |
|
||||
|`JOYSTICK_HAT_SOUTH` |`4` |180° |
|
||||
|`JOYSTICK_HAT_SOUTHWEST`|`5` |225° |
|
||||
|`JOYSTICK_HAT_WEST` |`6` |270° |
|
||||
|`JOYSTICK_HAT_NORTHWEST`|`7` |315° |
|
||||
|
||||
### Axes {#axes}
|
||||
|
||||
When defining axes for your joystick, you must provide a definition array typically in your `keymap.c`.
|
||||
@@ -147,6 +185,8 @@ Contains the state of the joystick.
|
||||
A bit-packed array containing the joystick button states. The size is calculated as `(JOYSTICK_BUTTON_COUNT - 1) / 8 + 1`.
|
||||
- `int16_t axes[]`
|
||||
An array of analog values for each defined axis.
|
||||
- `int8_t hat`
|
||||
The hat switch position.
|
||||
- `bool dirty`
|
||||
Whether the current state needs to be sent to the host.
|
||||
|
||||
@@ -220,3 +260,14 @@ Set the value of the given axis.
|
||||
The axis to set the value of.
|
||||
- `int16_t value`
|
||||
The value to set.
|
||||
|
||||
---
|
||||
|
||||
### `void joystick_set_hat(int8_t value)` {#api-joystick-set-hat}
|
||||
|
||||
Set the position of the hat switch.
|
||||
|
||||
#### Arguments {#api-joystick-set-hat-arguments}
|
||||
|
||||
- `int8_t value`
|
||||
The hat switch position to set.
|
||||
|
139
docs/features/layer_lock.md
Normal file
139
docs/features/layer_lock.md
Normal file
@@ -0,0 +1,139 @@
|
||||
# Layer Lock
|
||||
|
||||
Some [layer switches](../feature_layers#switching-and-toggling-layers) access
|
||||
the layer by holding the key, including momentary layer `MO(layer)` and layer
|
||||
tap `LT(layer, key)` keys. You may sometimes need to stay on the layer for a
|
||||
long period of time. Layer Lock "locks" the current layer to stay on, supposing
|
||||
it was accessed by one of:
|
||||
|
||||
* `MO(layer)` momentary layer switch
|
||||
* `LT(layer, key)` layer tap
|
||||
* `OSL(layer)` one-shot layer
|
||||
* `TT(layer)` layer tap toggle
|
||||
* `LM(layer, mod)` layer-mod key (the layer is locked, but not the mods)
|
||||
|
||||
Press the Layer Lock key again to unlock the layer. Additionally, when a layer
|
||||
is locked, layer switch keys that turn off the layer such as `TO(other_layer)`
|
||||
will unlock it.
|
||||
|
||||
|
||||
## How do I enable Layer Lock
|
||||
|
||||
In your rules.mk, add:
|
||||
|
||||
```make
|
||||
LAYER_LOCK_ENABLE = yes
|
||||
```
|
||||
|
||||
Pick a key in your keymap on a layer you intend to lock, and assign it the
|
||||
keycode `QK_LAYER_LOCK` (short alias `QK_LLCK`). Note that locking the base
|
||||
layer has no effect, so typically, this key is used on layers above the base
|
||||
layer.
|
||||
|
||||
|
||||
## Example use
|
||||
|
||||
Consider a keymap with the following base layer.
|
||||
|
||||

|
||||
|
||||
The highlighted key is a momentary layer switch `MO(NAV)`. Holding it accesses a
|
||||
navigation layer.
|
||||
|
||||

|
||||
|
||||
|
||||
Holding the NAV key is fine for brief use, but awkward to continue holding when
|
||||
using navigation functions continuously. The Layer Lock key comes to the rescue:
|
||||
|
||||
1. Hold the NAV key, activating the navigation layer.
|
||||
2. Tap Layer Lock.
|
||||
3. Release NAV. The navigation layer stays on.
|
||||
4. Make use of the arrow keys, etc.
|
||||
5. Tap Layer Lock or NAV again to turn the navigation layer back off.
|
||||
|
||||
A variation that would also work is to put the Layer Lock key on the base layer
|
||||
and make other layers transparent (`KC_TRNS`) in that position. Pressing the
|
||||
Layer Lock key locks (or unlocks) the highest active layer, regardless of which
|
||||
layer the Layer Lock key is on.
|
||||
|
||||
|
||||
## Idle timeout
|
||||
|
||||
Optionally, Layer Lock may be configured to unlock if the keyboard is idle
|
||||
for some time. In config.h, define `LAYER_LOCK_IDLE_TIMEOUT` in units of
|
||||
milliseconds:
|
||||
|
||||
```c
|
||||
#define LAYER_LOCK_IDLE_TIMEOUT 60000 // Turn off after 60 seconds.
|
||||
```
|
||||
|
||||
|
||||
## Functions
|
||||
|
||||
Use the following functions to query and manipulate the layer lock state.
|
||||
|
||||
| Function | Description |
|
||||
|----------------------------|------------------------------------|
|
||||
| `is_layer_locked(layer)` | Checks whether `layer` is locked. |
|
||||
| `layer_lock_on(layer)` | Locks and turns on `layer`. |
|
||||
| `layer_lock_off(layer)` | Unlocks and turns off `layer`. |
|
||||
| `layer_lock_invert(layer)` | Toggles whether `layer` is locked. |
|
||||
|
||||
|
||||
## Representing the current Layer Lock state
|
||||
|
||||
There is an optional callback `layer_lock_set_user()` that gets called when a
|
||||
layer is locked or unlocked. This is useful to represent the current lock state
|
||||
for instance by setting an LED. In keymap.c, define
|
||||
|
||||
```c
|
||||
bool layer_lock_set_user(layer_state_t locked_layers) {
|
||||
// Do something like `set_led(is_layer_locked(NAV));`
|
||||
return true;
|
||||
}
|
||||
```
|
||||
|
||||
The argument `locked_layers` is a bitfield in which the kth bit is on if the kth
|
||||
layer is locked. Alternatively, you can use `is_layer_locked(layer)` to check if
|
||||
a given layer is locked.
|
||||
|
||||
|
||||
## Combine Layer Lock with a mod-tap
|
||||
|
||||
It is possible to create a [mod-tap MT key](../mod_tap) that acts as a modifier
|
||||
on hold and Layer Lock on tap. Since Layer Lock is not a [basic
|
||||
keycode](../keycodes_basic), attempting `MT(mod, QK_LLCK)` is invalid does not
|
||||
work directly, yet this effect can be achieved through [changing the tap
|
||||
function](../mod_tap#changing-tap-function). For example, the following
|
||||
implements a `SFTLLCK` key that acts as Shift on hold and Layer Lock on tap:
|
||||
|
||||
```c
|
||||
#define SFTLLCK LSFT_T(KC_0)
|
||||
|
||||
// Use SFTLLCK in your keymap...
|
||||
|
||||
bool process_record_user(uint16_t keycode, keyrecord_t *record) {
|
||||
switch (keycode) {
|
||||
case SFTLLCK:
|
||||
if (record->tap.count) {
|
||||
if (record->event.pressed) {
|
||||
// Toggle the lock on the highest layer.
|
||||
layer_lock_invert(get_highest_layer(layer_state));
|
||||
}
|
||||
return false;
|
||||
}
|
||||
break;
|
||||
|
||||
// Other macros...
|
||||
}
|
||||
return true;
|
||||
}
|
||||
```
|
||||
|
||||
In the above, `KC_0` is an arbitrary placeholder for the tapping keycode. This
|
||||
keycode will never be sent, so any basic keycode will do. In
|
||||
`process_record_user()`, the tap press event is changed to toggle the lock on
|
||||
the highest layer. Layer Lock can be combined with a [layer-tap LT
|
||||
key](../feature_layers#switching-and-toggling-layers) similarly.
|
||||
|
@@ -203,6 +203,19 @@ Tips:
|
||||
* Keep `MOUSEKEY_MOVE_DELTA` at 1. This allows precise movements before the gliding effect starts.
|
||||
* Mouse wheel options are the same as the default accelerated mode, and do not use inertia.
|
||||
|
||||
### Overlapping mouse key control
|
||||
|
||||
When additional overlapping mouse key is pressed, the mouse cursor will continue in a new direction with the same acceleration. The following settings can be used to reset the acceleration with new overlapping keys for more precise control if desired:
|
||||
|
||||
|Define |Default |Description |
|
||||
|------------------------------|----------------------|-----------------------------------------------------------------------|
|
||||
|`MOUSEKEY_OVERLAP_RESET` |undefined |Enables overlapping mouse key control |
|
||||
|`MOUSEKEY_OVERLAP_MOVE_DELTA` |`MOUSEKEY_MOVE_DELTA` |Step size of reset movement acceleration |
|
||||
|`MOUSEKEY_OVERLAP_WHEEL_DELTA`|`MOUSEKEY_WHEEL_DELTA`|Step size of reset mouse wheel acceleration |
|
||||
|`MOUSEKEY_OVERLAP_INTERVAL` |`MOUSEKEY_INTERVAL` |Reset time between cursor movements in milliseconds (Kinetic mode only)|
|
||||
|
||||
?> This feature will not be applied on Inertial mode
|
||||
|
||||
## Use with PS/2 Mouse and Pointing Device
|
||||
|
||||
Mouse keys button state is shared with [PS/2 mouse](ps2_mouse) and [pointing device](pointing_device) so mouse keys button presses can be used for clicks and drags.
|
||||
|
@@ -70,17 +70,33 @@ The process is done in steps, generating a number of intermediate results until
|
||||
We therefore resort to debouncing the result until it has been stable for a given amount of milliseconds.
|
||||
This amount can be configured, in case your board is not stable within the default debouncing time of 200ms.
|
||||
|
||||
## KVM and USB switches
|
||||
|
||||
Some KVM and USB switches may not trigger the USB controller on the keyboard to fully reset upon switching machines.
|
||||
If your keyboard does not redetect the OS in this situation, you can force the keyboard to reset when the USB initialization event is detected, forcing the USB controller to be reconfigured.
|
||||
|
||||
## Configuration Options
|
||||
|
||||
* `#define OS_DETECTION_DEBOUNCE 200`
|
||||
* `#define OS_DETECTION_DEBOUNCE 250`
|
||||
* defined the debounce time for OS detection, in milliseconds
|
||||
* defaults to 250ms
|
||||
* `#define OS_DETECTION_KEYBOARD_RESET`
|
||||
* enables the keyboard reset upon a USB device reinitilization, such as switching devices on some KVMs
|
||||
* enables the keyboard reset upon a USB device reinitilization
|
||||
* this setting may help with detection issues when switching between devices on some KVMs (see [Troubleshooting](#troubleshooting))
|
||||
* `#define OS_DETECTION_SINGLE_REPORT`
|
||||
* allows the report callbacks to be called only once, when the OS detection result is considered stable
|
||||
* subsequent changes in the detection results, if any, are ignored
|
||||
* this setting may help with delayed stability issues when switching devices on some KVMs (see [Troubleshooting](#troubleshooting))
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Some KVMs and USB switches may cause issues when the OS detection is turned on.
|
||||
Here is a list of common issues and how to fix them:
|
||||
|
||||
* **Problem**: _keyboard won't redetect the OS when switching between machines using a KVM_
|
||||
* **Explanation**: some KVMs keep the USB controller powered on during the switch and OS
|
||||
detection happens when the USB device description is being assembled.
|
||||
* **Solution**: use `OS_DETECTION_KEYBOARD_RESET` to force the keyboard to reset upon switching.
|
||||
* **Problem**: _keyboard OS detection callback gets invoked even minuted after startup_
|
||||
* **Explanation**: some OSes, notably macOS on ARM-based Macs, may cause this behavior.
|
||||
The actual cause is not known at this time.'
|
||||
* **Solution**: use `OS_DETECTION_SINGLE_REPORT` to suppress repeated callback invocations.
|
||||
|
||||
|
||||
## Debug
|
||||
|
||||
|
@@ -394,6 +394,7 @@ Ideally, new sensor hardware should be added to `drivers/sensors/` and `quantum/
|
||||
| Setting | Description | Default |
|
||||
| ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------- |
|
||||
| `MOUSE_EXTENDED_REPORT` | (Optional) Enables support for extended mouse reports. (-32767 to 32767, instead of just -127 to 127). | _not defined_ |
|
||||
| `WHEEL_EXTENDED_REPORT` | (Optional) Enables support for extended wheel reports. (-32767 to 32767, instead of just -127 to 127). | _not defined_ |
|
||||
| `POINTING_DEVICE_ROTATION_90` | (Optional) Rotates the X and Y data by 90 degrees. | _not defined_ |
|
||||
| `POINTING_DEVICE_ROTATION_180` | (Optional) Rotates the X and Y data by 180 degrees. | _not defined_ |
|
||||
| `POINTING_DEVICE_ROTATION_270` | (Optional) Rotates the X and Y data by 270 degrees. | _not defined_ |
|
||||
|
@@ -90,18 +90,22 @@ PS2_ENABLE = yes
|
||||
PS2_DRIVER = interrupt
|
||||
```
|
||||
|
||||
In your keyboard config.h:
|
||||
In your keyboard `config.h`:
|
||||
|
||||
```c
|
||||
#define PS2_CLOCK_PIN A8
|
||||
#define PS2_DATA_PIN A9
|
||||
```
|
||||
|
||||
And in the chibios specifig halconf.h:
|
||||
```c
|
||||
#define PAL_USE_CALLBACKS TRUE
|
||||
```
|
||||
And in the ChibiOS specific `halconf.h`:
|
||||
|
||||
```c
|
||||
#pragma once
|
||||
|
||||
#define PAL_USE_CALLBACKS TRUE // [!code focus]
|
||||
|
||||
#include_next <halconf.h>
|
||||
```
|
||||
|
||||
### USART Version {#usart-version}
|
||||
|
||||
|
@@ -81,38 +81,21 @@ As mentioned earlier, the center of the keyboard by default is expected to be `{
|
||||
|
||||
## Keycodes {#keycodes}
|
||||
|
||||
All RGB keycodes are currently shared with the RGBLIGHT system:
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|-------------------|----------|--------------------------------------------------------------------------------------|
|
||||
|`RGB_TOG` | |Toggle RGB lighting on or off |
|
||||
|`RGB_MODE_FORWARD` |`RGB_MOD` |Cycle through modes, reverse direction when Shift is held |
|
||||
|`RGB_MODE_REVERSE` |`RGB_RMOD`|Cycle through modes in reverse, forward direction when Shift is held |
|
||||
|`RGB_HUI` | |Increase hue, decrease hue when Shift is held |
|
||||
|`RGB_HUD` | |Decrease hue, increase hue when Shift is held |
|
||||
|`RGB_SAI` | |Increase saturation, decrease saturation when Shift is held |
|
||||
|`RGB_SAD` | |Decrease saturation, increase saturation when Shift is held |
|
||||
|`RGB_VAI` | |Increase value (brightness), decrease value when Shift is held |
|
||||
|`RGB_VAD` | |Decrease value (brightness), increase value when Shift is held |
|
||||
|`RGB_SPI` | |Increase effect speed (does not support eeprom yet), decrease speed when Shift is held|
|
||||
|`RGB_SPD` | |Decrease effect speed (does not support eeprom yet), increase speed when Shift is held|
|
||||
|`RGB_MODE_PLAIN` |`RGB_M_P` |Static (no animation) mode |
|
||||
|`RGB_MODE_BREATHE` |`RGB_M_B` |Breathing animation mode |
|
||||
|`RGB_MODE_RAINBOW` |`RGB_M_R` |Full gradient scrolling left to right (uses the `RGB_MATRIX_CYCLE_LEFT_RIGHT` mode) |
|
||||
|`RGB_MODE_SWIRL` |`RGB_M_SW`|Full gradient spinning pinwheel around center of keyboard (uses `RGB_MATRIX_CYCLE_PINWHEEL` mode) |
|
||||
|
||||
* `RGB_MODE_*` keycodes will generally work, but not all of the modes are currently mapped to the correct effects for the RGB Matrix system.
|
||||
|
||||
`RGB_MODE_PLAIN`, `RGB_MODE_BREATHE`, `RGB_MODE_RAINBOW`, and `RGB_MODE_SWIRL` are the only ones that are mapped properly. The rest don't have a direct equivalent, and are not mapped.
|
||||
|
||||
::: tip
|
||||
`RGB_*` keycodes cannot be used with functions like `tap_code16(RGB_HUD)` as they're not USB HID keycodes. If you wish to replicate similar behaviour in custom code within your firmware (e.g. inside `encoder_update_user()` or `process_record_user()`), the equivalent [RGB functions](#functions) should be used instead.
|
||||
:::
|
||||
|
||||
|
||||
::: warning
|
||||
By default, if you have both the [RGB Light](rgblight) and the RGB Matrix feature enabled, these keycodes will work for both features, at the same time. You can disable the keycode functionality by defining the `*_DISABLE_KEYCODES` option for the specific feature.
|
||||
:::
|
||||
|Key |Aliases |Description |
|
||||
|-------------------------------|---------|-----------------------------------|
|
||||
|`QK_RGB_MATRIX_ON` |`RM_ON` |Turn on RGB Matrix |
|
||||
|`QK_RGB_MATRIX_OFF` |`RM_OFF` |Turn off RGB Matrix |
|
||||
|`QK_RGB_MATRIX_TOGGLE` |`RM_TOGG`|Toggle RGB Matrix on or off |
|
||||
|`QK_RGB_MATRIX_MODE_NEXT` |`RM_NEXT`|Cycle through animations |
|
||||
|`QK_RGB_MATRIX_MODE_PREVIOUS` |`RM_PREV`|Cycle through animations in reverse|
|
||||
|`QK_RGB_MATRIX_HUE_UP` |`RM_HUEU`|Cycle through hue |
|
||||
|`QK_RGB_MATRIX_HUE_DOWN` |`RM_HUED`|Cycle through hue in reverse |
|
||||
|`QK_RGB_MATRIX_SATURATION_UP` |`RM_SATU`|Increase the saturation |
|
||||
|`QK_RGB_MATRIX_SATURATION_DOWN`|`RM_SATD`|Decrease the saturation |
|
||||
|`QK_RGB_MATRIX_VALUE_UP` |`RM_VALU`|Increase the brightness level |
|
||||
|`QK_RGB_MATRIX_VALUE_DOWN` |`RM_VALD`|Decrease the brightness level |
|
||||
|`QK_RGB_MATRIX_SPEED_UP` |`RM_SPDU`|Increase the animation speed |
|
||||
|`QK_RGB_MATRIX_SPEED_DOWN` |`RM_SPDD`|Decrease the animation speed |
|
||||
|
||||
## RGB Matrix Effects {#rgb-matrix-effects}
|
||||
|
||||
@@ -289,7 +272,7 @@ Solid reactive effects will pulse RGB light on key presses with user configurabl
|
||||
#define RGB_MATRIX_SOLID_REACTIVE_GRADIENT_MODE
|
||||
```
|
||||
|
||||
Gradient mode will loop through the color wheel hues over time and its duration can be controlled with the effect speed keycodes (`RGB_SPI`/`RGB_SPD`).
|
||||
Gradient mode will loop through the color wheel hues over time and its duration can be controlled with the effect speed keycodes (`RM_SPDU`/`RM_SPDD`).
|
||||
|
||||
## Custom RGB Matrix Effects {#custom-rgb-matrix-effects}
|
||||
|
||||
@@ -396,7 +379,6 @@ These are defined in [`color.h`](https://github.com/qmk/qmk_firmware/blob/master
|
||||
#define RGB_MATRIX_DEFAULT_VAL RGB_MATRIX_MAXIMUM_BRIGHTNESS // Sets the default brightness value, if none has been set
|
||||
#define RGB_MATRIX_DEFAULT_SPD 127 // Sets the default animation speed, if none has been set
|
||||
#define RGB_MATRIX_DEFAULT_FLAGS LED_FLAG_ALL // Sets the default LED flags, if none has been set
|
||||
#define RGB_MATRIX_DISABLE_KEYCODES // disables control of rgb matrix by keycodes (must use code functions to control the feature)
|
||||
#define RGB_MATRIX_SPLIT { X, Y } // (Optional) For split keyboards, the number of LEDs connected on each half. X = left, Y = Right.
|
||||
// If reactive effects are enabled, you also will want to enable SPLIT_TRANSPORT_MIRROR
|
||||
#define RGB_TRIGGER_ON_KEYDOWN // Triggers RGB keypress events on key down. This makes RGB control feel more responsive. This may cause RGB to not function properly on some boards
|
||||
@@ -496,18 +478,18 @@ This example sets the modifiers to be a specific color based on the layer state.
|
||||
|
||||
```c
|
||||
bool rgb_matrix_indicators_advanced_user(uint8_t led_min, uint8_t led_max) {
|
||||
HSV hsv = {0, 255, 255};
|
||||
hsv_t hsv = {0, 255, 255};
|
||||
|
||||
if (layer_state_is(layer_state, 2)) {
|
||||
hsv = (HSV){130, 255, 255};
|
||||
hsv = (hsv_t){130, 255, 255};
|
||||
} else {
|
||||
hsv = (HSV){30, 255, 255};
|
||||
hsv = (hsv_t){30, 255, 255};
|
||||
}
|
||||
|
||||
if (hsv.v > rgb_matrix_get_val()) {
|
||||
hsv.v = rgb_matrix_get_val();
|
||||
}
|
||||
RGB rgb = hsv_to_rgb(hsv);
|
||||
rgb_t rgb = hsv_to_rgb(hsv);
|
||||
|
||||
for (uint8_t i = led_min; i < led_max; i++) {
|
||||
if (HAS_FLAGS(g_led_config.flags[i], 0x01)) { // 0x01 == LED_FLAG_MODIFIER
|
||||
@@ -873,13 +855,13 @@ Set the global effect hue, saturation, and value (brightness). New state is not
|
||||
|
||||
---
|
||||
|
||||
### `HSV rgb_matrix_get_hsv(void)` {#api-rgb-matrix-get-hsv}
|
||||
### `hsv_t rgb_matrix_get_hsv(void)` {#api-rgb-matrix-get-hsv}
|
||||
|
||||
Get the current global effect hue, saturation, and value (brightness).
|
||||
|
||||
#### Return Value {#api-rgb-matrix-get-hsv-return}
|
||||
|
||||
The current effect HSV as an `HSV` struct.
|
||||
The current effect HSV as an `hsv_t` struct.
|
||||
|
||||
---
|
||||
|
||||
|
@@ -59,6 +59,10 @@ Changing the **Value** sets the overall brightness.<br>
|
||||
|
||||
## Keycodes
|
||||
|
||||
::: warning
|
||||
These keycodes also simultaneously control [RGB Matrix](rgb_matrix), if enabled. This behaviour is in the process of being deprecated, so during this time it is recommended to additionally include the dedicated RGB Matrix keycodes to your keymap, and add `#define RGB_MATRIX_DISABLE_SHARED_KEYCODES` to `config.h`.
|
||||
:::
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|------------------------------|----------|---------------------------------------------------------------------|
|
||||
|`QK_UNDERGLOW_TOGGLE` |`UG_TOGG` |Toggle RGB lighting on or off |
|
||||
@@ -87,11 +91,6 @@ Changing the **Value** sets the overall brightness.<br>
|
||||
These keycodes cannot be used with functions like `tap_code16()` as they are not USB HID keycodes. If you wish to replicate similar behaviour in custom code within your firmware (e.g. inside `encoder_update_user()` or `process_record_user()`), the equivalent [RGB functions](#functions) should be used instead.
|
||||
:::
|
||||
|
||||
|
||||
::: warning
|
||||
By default, if you have both the RGB Light and the [RGB Matrix](rgb_matrix) feature enabled, these keycodes will work for both features, at the same time. You can disable the keycode functionality by defining the `*_DISABLE_KEYCODES` option for the specific feature.
|
||||
:::
|
||||
|
||||
## Configuration
|
||||
|
||||
Your RGB lighting can be configured by placing these `#define`s in your `config.h`:
|
||||
@@ -104,7 +103,6 @@ Your RGB lighting can be configured by placing these `#define`s in your `config.
|
||||
|`RGBLIGHT_LIMIT_VAL` |`255` |The maximum brightness level |
|
||||
|`RGBLIGHT_SLEEP` |*Not defined* |If defined, the RGB lighting will be switched off when the host goes to sleep |
|
||||
|`RGBLIGHT_SPLIT` |*Not defined* |If defined, synchronization functionality for split keyboards is added |
|
||||
|`RGBLIGHT_DISABLE_KEYCODES`|*Not defined* |If defined, disables the ability to control RGB Light from the keycodes. You must use code functions to control the feature|
|
||||
|`RGBLIGHT_DEFAULT_MODE` |`RGBLIGHT_MODE_STATIC_LIGHT`|The default mode to use upon clearing the EEPROM |
|
||||
|`RGBLIGHT_DEFAULT_HUE` |`0` (red) |The default hue to use upon clearing the EEPROM |
|
||||
|`RGBLIGHT_DEFAULT_SAT` |`UINT8_MAX` (255) |The default saturation to use upon clearing the EEPROM |
|
||||
|
@@ -273,12 +273,12 @@ Now, at the bottom of your `keymap.c` file, you'll need to add the following:
|
||||
* How to figure out tap dance state: interrupted and pressed.
|
||||
*
|
||||
* Interrupted: If the state of a dance is "interrupted", that means that another key has been hit
|
||||
* under the tapping term. This is typically indicitive that you are trying to "tap" the key.
|
||||
* under the tapping term. This is typically indicative that you are trying to "tap" the key.
|
||||
*
|
||||
* Pressed: Whether or not the key is still being pressed. If this value is true, that means the tapping term
|
||||
* has ended, but the key is still being pressed down. This generally means the key is being "held".
|
||||
*
|
||||
* One thing that is currenlty not possible with qmk software in regards to tap dance is to mimic the "permissive hold"
|
||||
* One thing that is currently not possible with qmk software in regards to tap dance is to mimic the "permissive hold"
|
||||
* feature. In general, advanced tap dances do not work well if they are used with commonly typed letters.
|
||||
* For example "A". Tap dances are best used on non-letter keys that are not hit while typing letters.
|
||||
*
|
||||
@@ -290,7 +290,7 @@ Now, at the bottom of your `keymap.c` file, you'll need to add the following:
|
||||
* Not a key that is used frequently to double tap, for example 'tab' is often double tapped in a terminal, or
|
||||
* in a web form. So 'tab' would be a poor choice for a tap dance.
|
||||
* Letters used in common words as a double. For example 'p' in 'pepper'. If a tap dance function existed on the
|
||||
* letter 'p', the word 'pepper' would be quite frustating to type.
|
||||
* letter 'p', the word 'pepper' would be quite frustrating to type.
|
||||
*
|
||||
* For the third point, there does exist the 'TD_DOUBLE_SINGLE_TAP', however this is not fully tested
|
||||
*
|
||||
|
58
docs/features/wireless.md
Normal file
58
docs/features/wireless.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# Wireless / Bluetooth
|
||||
|
||||
## Bluetooth Known Supported Hardware
|
||||
|
||||
Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1, QMK has support for RN-42 modules. For more recent BLE protocols, currently only the Adafruit Bluefruit SPI Friend is directly supported. BLE is needed to connect to iOS devices. Note iOS does not support mouse input.
|
||||
|
||||
|Board |Bluetooth Protocol |Connection Type|rules.mk |Bluetooth Chip|
|
||||
|----------------------------------------------------------------|--------------------|---------------|---------------------------------|--------------|
|
||||
|Roving Networks RN-42 (Sparkfun Bluesmirf) |Bluetooth Classic |UART |`BLUETOOTH_DRIVER = rn42` |RN-42 |
|
||||
|[Bluefruit LE SPI Friend](https://www.adafruit.com/product/2633)|Bluetooth Low Energy|SPI |`BLUETOOTH_DRIVER = bluefruit_le`|nRF51822 |
|
||||
|
||||
Not Supported Yet but possible:
|
||||
* [Bluefruit LE UART Friend](https://www.adafruit.com/product/2479). [Possible tmk implementation found in](https://github.com/tmk/tmk_keyboard/issues/514)
|
||||
* HC-05 boards flashed with RN-42 firmware. They apparently both use the CSR BC417 Chip. Flashing it with RN-42 firmware gives it HID capability.
|
||||
* Sparkfun Bluetooth Mate
|
||||
* HM-13 based boards
|
||||
|
||||
### Adafruit BLE SPI Friend
|
||||
Currently The only bluetooth chipset supported by QMK is the Adafruit Bluefruit SPI Friend. It's a Nordic nRF51822 based chip running Adafruit's custom firmware. Data is transmitted via Adafruit's SDEP over Hardware SPI. The [Feather 32u4 Bluefruit LE](https://www.adafruit.com/product/2829) is supported as it's an AVR mcu connected via SPI to the Nordic BLE chip with Adafruit firmware. If Building a custom board with the SPI friend it would be easiest to just use the pin selection that the 32u4 feather uses but you can change the pins in the config.h options with the following defines:
|
||||
* `#define BLUEFRUIT_LE_RST_PIN D4`
|
||||
* `#define BLUEFRUIT_LE_CS_PIN B4`
|
||||
* `#define BLUEFRUIT_LE_IRQ_PIN E6`
|
||||
|
||||
A Bluefruit UART friend can be converted to an SPI friend, however this [requires](https://github.com/qmk/qmk_firmware/issues/2274) some reflashing and soldering directly to the MDBT40 chip.
|
||||
|
||||
<!-- FIXME: Document bluetooth support more completely. -->
|
||||
## Bluetooth Rules.mk Options
|
||||
|
||||
The currently supported Bluetooth chipsets do not support [N-Key Rollover (NKRO)](../reference_glossary#n-key-rollover-nkro), so `rules.mk` must contain `NKRO_ENABLE = no`.
|
||||
|
||||
Add the following to your `rules.mk`:
|
||||
|
||||
```make
|
||||
BLUETOOTH_ENABLE = yes
|
||||
BLUETOOTH_DRIVER = bluefruit_le # or rn42
|
||||
```
|
||||
|
||||
## Bluetooth Keycodes
|
||||
|
||||
This is used when multiple keyboard outputs can be selected. Currently this only allows for switching between USB and Bluetooth on keyboards that support both.
|
||||
|
||||
| Key | Aliases | Description |
|
||||
|-----------------------------|-----------|-----------------------------------------------------------------------------------------------|
|
||||
| `QK_OUTPUT_AUTO` | `OU_AUTO` | Automatically switch to USB when plugged in, otherwise use wireless |
|
||||
| `QK_OUTPUT_NEXT` | `OU_NEXT` | Cycle forwards through USB, Bluetooth, and 2.4GHz (when available) **(not yet implemented)** |
|
||||
| `QK_OUTPUT_PREV` | `OU_PREV` | Cycle backwards through USB, Bluetooth, and 2.4GHz (when available) **(not yet implemented)** |
|
||||
| `QK_OUTPUT_NONE` | `OU_NONE` | Disable all output **(not yet implemented)** |
|
||||
| `QK_OUTPUT_USB` | `OU_USB` | Output to USB only |
|
||||
| `QK_OUTPUT_2P4GHZ` | `OU_2P4G` | Output to 2.4GHz only **(not yet implemented)** |
|
||||
| `QK_OUTPUT_BLUETOOTH` | `OU_BT` | Output to Bluetooth only |
|
||||
| `QK_BLUETOOTH_PROFILE_NEXT` | `BT_NEXT` | Move to the next Bluetooth profile **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE_PREV` | `BT_PREV` | Move to the previous Bluetooth profile **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_UNPAIR` | `BT_UNPR` | Un-pair the current Bluetooth profile **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE1` | `BT_PRF1` | Swap to Bluetooth profile #1 **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE2` | `BT_PRF2` | Swap to Bluetooth profile #2 **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE3` | `BT_PRF3` | Swap to Bluetooth profile #3 **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE4` | `BT_PRF4` | Swap to Bluetooth profile #4 **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE5` | `BT_PRF5` | Swap to Bluetooth profile #5 **(not yet implemented)** |
|
@@ -53,7 +53,7 @@ QMK maintains [a fork of the LUFA DFU bootloader](https://github.com/qmk/lufa/tr
|
||||
//#define QMK_LED E6
|
||||
//#define QMK_SPEAKER C6
|
||||
```
|
||||
Currently we do not recommend making `QMK_ESC` the same key as the one designated for [Bootmagic Lite](features/bootmagic), as holding it down will cause the MCU to loop back and forth between entering and exiting the bootloader.
|
||||
Currently we do not recommend making `QMK_ESC` the same key as the one designated for [Bootmagic](features/bootmagic), as holding it down will cause the MCU to loop back and forth between entering and exiting the bootloader.
|
||||
|
||||
The manufacturer and product strings are automatically pulled from `config.h`, with " Bootloader" appended to the product string.
|
||||
|
||||
@@ -209,7 +209,7 @@ To enable the additional features, add the following defines to your `config.h`:
|
||||
//#define QMK_SPEAKER C6
|
||||
```
|
||||
|
||||
Currently we do not recommend making `QMK_ESC` the same key as the one designated for [Bootmagic Lite](features/bootmagic), as holding it down will cause the MCU to loop back and forth between entering and exiting the bootloader.
|
||||
Currently we do not recommend making `QMK_ESC` the same key as the one designated for [Bootmagic](features/bootmagic), as holding it down will cause the MCU to loop back and forth between entering and exiting the bootloader.
|
||||
|
||||
The manufacturer and product strings are automatically pulled from `config.h`, with " Bootloader" appended to the product string.
|
||||
|
||||
@@ -345,6 +345,39 @@ Flashing sequence:
|
||||
3. Flash a .bin file
|
||||
4. Reset the device into application mode (may be done automatically)
|
||||
|
||||
## AT32 DFU
|
||||
|
||||
All AT32 MCUs come preloaded with a factory bootloader that cannot be modified nor deleted.
|
||||
|
||||
To ensure compatibility with the AT32-DFU bootloader, make sure this block is present in your `rules.mk`:
|
||||
|
||||
```make
|
||||
# Bootloader selection
|
||||
BOOTLOADER = at32-dfu
|
||||
```
|
||||
|
||||
Compatible flashers:
|
||||
|
||||
* [dfu-util](https://dfu-util.sourceforge.net/) / `:dfu-util` target in QMK (recommended command line)
|
||||
```
|
||||
dfu-util -a 0 -d 2E3C:DF11 -s 0x8000000:leave -D <filename>
|
||||
```
|
||||
|
||||
Flashing sequence:
|
||||
|
||||
1. Enter the bootloader using any of the following methods:
|
||||
* Tap the `QK_BOOT` keycode
|
||||
* If a reset circuit is present, tap the `RESET` button on the PCB; some boards may also have a toggle switch that must be flipped
|
||||
* Otherwise, you need to bridge `BOOT0` to VCC (via `BOOT0` button or jumper), short `RESET` to GND (via `RESET` button or jumper), and then let go of the `BOOT0` bridge
|
||||
2. Wait for the OS to detect the device
|
||||
3. Flash a .bin file
|
||||
4. Reset the device into application mode (may be done automatically)
|
||||
|
||||
### `make` Targets
|
||||
|
||||
* `:dfu-util`: Waits until an AT32 bootloader device is available, and then flashes the firmware.
|
||||
* `:dfu-util-split-left` and `:dfu-util-split-right`: Flashes the firmware as with `:dfu-util`, but also sets the handedness setting in EEPROM.
|
||||
|
||||
## tinyuf2
|
||||
|
||||
Keyboards may opt into supporting the tinyuf2 bootloader. This is currently only supported on F303/F401/F411.
|
||||
|
@@ -5,6 +5,7 @@ This project includes a Docker workflow that will allow you to build a new firmw
|
||||
## Requirements
|
||||
|
||||
The main prerequisite is a working `docker` or `podman` install.
|
||||
|
||||
* [Docker CE](https://docs.docker.com/install/#supported-platforms)
|
||||
* [Podman](https://podman.io/getting-started/installation)
|
||||
|
||||
@@ -18,6 +19,7 @@ cd qmk_firmware
|
||||
```
|
||||
|
||||
Run the following command to build a keymap:
|
||||
|
||||
```
|
||||
util/docker_build.sh <keyboard>:<keymap>
|
||||
# For example: util/docker_build.sh planck/rev6:default
|
||||
@@ -32,6 +34,8 @@ util/docker_build.sh keyboard:keymap:target
|
||||
# For example: util/docker_build.sh planck/rev6:default:flash
|
||||
```
|
||||
|
||||
Note that mass storage bootloaders are not supported by the `flash` target. In this case you will have to manually copy the firmware file to the keyboard.
|
||||
|
||||
You can also start the script without any parameters, in which case it will ask you to input the build parameters one by one, which you may find easier to use:
|
||||
|
||||
```
|
||||
|
@@ -231,7 +231,7 @@ Once you have confirmed that the keyboard is working, if you have used a seperat
|
||||
|
||||
If you found this fullfilling you could experiment by adding additional features such as [in switch LEDs](https://geekhack.org/index.php?topic=94258.0), [in switch RGB](https://www.reddit.com/r/MechanicalKeyboards/comments/5s1l5u/photoskeyboard_science_i_made_a_handwired_rgb/), [RGB underglow](https://medium.com/@DavidNZ/hand-wired-custom-keyboard-cdd14429c7b3#.7a1ovebsk) or even an [OLED display!](https://www.reddit.com/r/olkb/comments/5zy7og/adding_ssd1306_oled_display_to_your_build/)
|
||||
|
||||
There are a lot of possibilities inside the firmware - explore [docs.qmk.fm](https://docs.qmk.fm) for a full feature list, and dive into the different keyboards to see how people use all of them. You can always stop by [the OLKB subreddit](https://reddit.com/r/olkb) or [QMK Discord](https://discord.gg/Uq7gcHh) for help!
|
||||
There are a lot of possibilities inside the firmware - explore [docs.qmk.fm](https://docs.qmk.fm) for a full feature list, and dive into the different keyboards to see how people use all of them. You can always stop by [the OLKB subreddit](https://reddit.com/r/olkb) or [QMK Discord](https://discord.gg/qmk) for help!
|
||||
|
||||
## Links to Other Guides
|
||||
|
||||
|
@@ -111,7 +111,7 @@ The `post_config.h` file can be used for additional post-processing, depending o
|
||||
#define USB_MAX_POWER_CONSUMPTION 400
|
||||
#else
|
||||
// fix iPhone and iPad power adapter issue
|
||||
// iOS device need lessthan 100
|
||||
// iOS devices need less than 100
|
||||
#define USB_MAX_POWER_CONSUMPTION 100
|
||||
#endif
|
||||
|
||||
|
@@ -32,7 +32,7 @@ There are a lot of ways you can contribute to the QMK Community. The easiest way
|
||||
|
||||
* Help people out on our forums and chat rooms:
|
||||
* [/r/olkb](https://www.reddit.com/r/olkb/)
|
||||
* [Discord Server](https://discord.gg/Uq7gcHh)
|
||||
* [Discord Server](https://discord.gg/qmk)
|
||||
* Contribute to our documentation by clicking "Edit This Page" at the bottom
|
||||
* [Report a bug](https://github.com/qmk/qmk_firmware/issues/new/choose)
|
||||
* [Open a Pull Request](contributing)
|
||||
|
@@ -290,15 +290,27 @@ See also: [Backlighting](features/backlight)
|
||||
| `QK_BACKLIGHT_DOWN` | `BL_DOWN` | Decrease the backlight level |
|
||||
| `QK_BACKLIGHT_TOGGLE_BREATHING` | `BL_BRTG` | Toggle backlight breathing |
|
||||
|
||||
## Bluetooth {#bluetooth}
|
||||
## Wireless/Bluetooth {#bluetooth}
|
||||
|
||||
See also: [Bluetooth](features/bluetooth)
|
||||
See also: [Wireless](features/wireless)
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|---------------------|---------|----------------------------------------------|
|
||||
|`QK_OUTPUT_AUTO` |`OU_AUTO`|Automatically switch between USB and Bluetooth|
|
||||
|`QK_OUTPUT_USB` |`OU_USB` |USB only |
|
||||
|`QK_OUTPUT_BLUETOOTH`|`OU_BT` |Bluetooth only |
|
||||
| Key | Aliases | Description |
|
||||
|-----------------------------|-----------|-----------------------------------------------------------------------------------------------|
|
||||
| `QK_OUTPUT_AUTO` | `OU_AUTO` | Automatically switch to USB when plugged in, otherwise use wireless |
|
||||
| `QK_OUTPUT_NEXT` | `OU_NEXT` | Cycle forwards through USB, Bluetooth, and 2.4GHz (when available) **(not yet implemented)** |
|
||||
| `QK_OUTPUT_PREV` | `OU_PREV` | Cycle backwards through USB, Bluetooth, and 2.4GHz (when available) **(not yet implemented)** |
|
||||
| `QK_OUTPUT_NONE` | `OU_NONE` | Disable all output **(not yet implemented)** |
|
||||
| `QK_OUTPUT_USB` | `OU_USB` | Output to USB only |
|
||||
| `QK_OUTPUT_2P4GHZ` | `OU_2P4G` | Output to 2.4GHz only **(not yet implemented)** |
|
||||
| `QK_OUTPUT_BLUETOOTH` | `OU_BT` | Output to Bluetooth only |
|
||||
| `QK_BLUETOOTH_PROFILE_NEXT` | `BT_NEXT` | Move to the next Bluetooth profile **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE_PREV` | `BT_PREV` | Move to the previous Bluetooth profile **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_UNPAIR` | `BT_UNPR` | Un-pair the current Bluetooth profile **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE1` | `BT_PRF1` | Swap to Bluetooth profile #1 **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE2` | `BT_PRF2` | Swap to Bluetooth profile #2 **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE3` | `BT_PRF3` | Swap to Bluetooth profile #3 **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE4` | `BT_PRF4` | Swap to Bluetooth profile #4 **(not yet implemented)** |
|
||||
| `QK_BLUETOOTH_PROFILE5` | `BT_PRF5` | Swap to Bluetooth profile #5 **(not yet implemented)** |
|
||||
|
||||
## Caps Word {#caps-word}
|
||||
|
||||
@@ -375,13 +387,22 @@ See also: [Key Lock](features/key_lock)
|
||||
|---------|--------------------------------------------------------------|
|
||||
|`QK_LOCK`|Hold down the next key pressed, until the key is pressed again|
|
||||
|
||||
## Layer Lock {#layer-lock}
|
||||
|
||||
See also: [Layer Lock](features/layer_lock)
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|---------------|---------|----------------------------------|
|
||||
|`QK_LAYER_LOCK`|`QK_LLCK`|Locks or unlocks the highest layer|
|
||||
|
||||
## Layer Switching {#layer-switching}
|
||||
|
||||
See also: [Layer Switching](feature_layers#switching-and-toggling-layers)
|
||||
|
||||
|Key |Description |
|
||||
|----------------|----------------------------------------------------------------------------------|
|
||||
|`DF(layer)` |Set the base (default) layer |
|
||||
|`DF(layer)` |Set the base (default) layer until the keyboard loses power |
|
||||
|`PDF(layer)` |Set the base (default) layer in EEPROM |
|
||||
|`MO(layer)` |Momentarily turn on `layer` when pressed (requires `KC_TRNS` on destination layer)|
|
||||
|`OSL(layer)` |Momentarily activates `layer` until a key is pressed. See [One Shot Keys](one_shot_keys) for details. |
|
||||
|`LM(layer, mod)`|Momentarily turn on `layer` (like MO) with `mod` active as well. Where `mod` is a mods_bit. Mods can be viewed [here](mod_tap). Example Implementation: `LM(LAYER_1, MOD_LALT)`|
|
||||
@@ -728,23 +749,25 @@ See also: [RGB Lighting](features/rgblight)
|
||||
|`RGB_MODE_RGBTEST` |`RGB_M_T` |Red, Green, Blue test animation mode (deprecated) |
|
||||
|`RGB_MODE_TWINKLE` |`RGB_M_TW`|Twinkle animation mode (deprecated) |
|
||||
|
||||
## RGB Matrix Lighting {#rgb-matrix-lighting}
|
||||
## RGB Matrix {#rgb-matrix}
|
||||
|
||||
See also: [RGB Matrix Lighting](features/rgb_matrix)
|
||||
See also: [RGB Matrix](features/rgb_matrix)
|
||||
|
||||
|Key |Aliases |Description |
|
||||
|-------------------|----------|--------------------------------------------------------------------------------------|
|
||||
|`RGB_TOG` | |Toggle RGB lighting on or off |
|
||||
|`RGB_MODE_FORWARD` |`RGB_MOD` |Cycle through modes, reverse direction when Shift is held |
|
||||
|`RGB_MODE_REVERSE` |`RGB_RMOD`|Cycle through modes in reverse, forward direction when Shift is held |
|
||||
|`RGB_HUI` | |Increase hue, decrease hue when Shift is held |
|
||||
|`RGB_HUD` | |Decrease hue, increase hue when Shift is held |
|
||||
|`RGB_SAI` | |Increase saturation, decrease saturation when Shift is held |
|
||||
|`RGB_SAD` | |Decrease saturation, increase saturation when Shift is held |
|
||||
|`RGB_VAI` | |Increase value (brightness), decrease value when Shift is held |
|
||||
|`RGB_VAD` | |Decrease value (brightness), increase value when Shift is held |
|
||||
|`RGB_SPI` | |Increase effect speed (does not support eeprom yet), decrease speed when Shift is held|
|
||||
|`RGB_SPD` | |Decrease effect speed (does not support eeprom yet), increase speed when Shift is held|
|
||||
|Key |Aliases |Description |
|
||||
|-------------------------------|---------|-----------------------------------|
|
||||
|`QK_RGB_MATRIX_ON` |`RM_ON` |Turn on RGB Matrix |
|
||||
|`QK_RGB_MATRIX_OFF` |`RM_OFF` |Turn off RGB Matrix |
|
||||
|`QK_RGB_MATRIX_TOGGLE` |`RM_TOGG`|Toggle RGB Matrix on or off |
|
||||
|`QK_RGB_MATRIX_MODE_NEXT` |`RM_NEXT`|Cycle through animations |
|
||||
|`QK_RGB_MATRIX_MODE_PREVIOUS` |`RM_PREV`|Cycle through animations in reverse|
|
||||
|`QK_RGB_MATRIX_HUE_UP` |`RM_HUEU`|Cycle through hue |
|
||||
|`QK_RGB_MATRIX_HUE_DOWN` |`RM_HUED`|Cycle through hue in reverse |
|
||||
|`QK_RGB_MATRIX_SATURATION_UP` |`RM_SATU`|Increase the saturation |
|
||||
|`QK_RGB_MATRIX_SATURATION_DOWN`|`RM_SATD`|Decrease the saturation |
|
||||
|`QK_RGB_MATRIX_VALUE_UP` |`RM_VALU`|Increase the brightness level |
|
||||
|`QK_RGB_MATRIX_VALUE_DOWN` |`RM_VALD`|Decrease the brightness level |
|
||||
|`QK_RGB_MATRIX_SPEED_UP` |`RM_SPDU`|Increase the animation speed |
|
||||
|`QK_RGB_MATRIX_SPEED_DOWN` |`RM_SPDD`|Decrease the animation speed |
|
||||
|
||||
## US ANSI Shifted Symbols {#us-ansi-shifted-symbols}
|
||||
|
||||
|
96
docs/license_violations.md
Normal file
96
docs/license_violations.md
Normal file
@@ -0,0 +1,96 @@
|
||||
# License Violations
|
||||
|
||||
QMK Firmware has seen its fair share of license violations, which hurts the community and frustrates the QMK maintainers.
|
||||
|
||||
Typical non-compliance includes:
|
||||
|
||||
* Not providing any source code
|
||||
* Providing "crippled" source code, such as a wired-only firmware for a wireless-capable board
|
||||
|
||||
Boards from vendors who don't provide source code are proving to be a significant time sink as the QMK team and other support helpers volunteer their time trying to determine which board someone has before they can help -- and in these cases they can't help. Occasionally this is followed by abuse; something that QMK and its volunteers should not be subjected to, rather redirected to the vendor in question.
|
||||
|
||||
The QMK team now actively directs support requests back to each vendor - vendors must provide their own product support for their boards. The QMK team are volunteers, the vendor must not expect the team to act as their support staff.
|
||||
|
||||
## Offending Vendors
|
||||
|
||||
The QMK team cannot tell you which boards you should or should not purchase, but please consider the lack of license compliance from the following vendors before making your decision. If you wish to look at the boards upstream QMK Firmware currently supports, you can search [here](https://browse.qmk.fm/).
|
||||
|
||||
If you own a board from one of the following vendors already, consider asking them for the equivalent QMK source code if it's not already available. With enough customers demanding corresponding source code, vendors may start to change their policies.
|
||||
|
||||
| Vendor | Reason |
|
||||
|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| BBB Keyboard | Selling tri-mode boards based on QMK without sources, attempted upstreaming crippled firmware without wireless. |
|
||||
| Chillkey | |
|
||||
| CIDOO | Selling wired boards based on QMK without sources, just `via.json` provided. |
|
||||
| Darmoshark | Selling wired boards based on QMK without sources, just `via.json` provided. |
|
||||
| Epomaker | Lots of historical keyboards with `via.json` but no corresponding sources. Wireless code for a small handful provided, pending core cleanup for QMK upstreaming. Most other boards have source nowhere to be seen. |
|
||||
| Ergokbd (IFKB) | At least their crkbd clone ships with QMK+Vial, seemingly refuses to disclose sources despite multiple customers requesting them. |
|
||||
| iLovBee | Official 30-day copyright source code request issued Sep 11 2024 due to deception on PR, no response received. Ambiguity on PRs -- marketing says wireless, PR author said wired-only, then included wireless code anyway. Seemingly intentionally deceptive. |
|
||||
| KiiBOOM | Seems to use the same OEM as Epomaker, same problems. |
|
||||
| Luminkey | Selling tri-mode boards based on QMK without sources, just `via.json` provided. |
|
||||
| Meletrix | Selling tri-mode boards based on QMK without sources, just `via.json` provided. |
|
||||
| mmd / Smartmmd / i-game.tech | Ambiguity on PRs -- marketing says wireless, PR author said wired-only, then included wireless code anyway. Seemingly intentionally deceptive. |
|
||||
| MyKeyClub | Community-supported JRIS75, vendor was contacted by community members and refused to cooperate. |
|
||||
| owlab | Selling wired based on QMK without sources, just `via.json` provided. Ambiguous as to whether or not wireless firmware is based on QMK, given that their configuration tool looks very similar to VIA. |
|
||||
| qwertykeys | Selling wired and tri-mode boards based on QMK without sources, just `via.json` provided. |
|
||||
| Redragon | Selling tri-mode boards based on QMK without sources, attempted upstreaming crippled firmware without wireless. |
|
||||
| Royal Kludge | PRs for fake boards in order to attain VIA compatibility identified. Lots of other keyboards with `via.json` but no corresponding sources, attempted upstreaming crippled firmware without wireless. Wireless code for some provided, pending core cleanup for QMK upstreaming. PRs including different manufacturer names as well. |
|
||||
| Shenzhen Hangsheng | PR submissions with crippled firmware, debating with maintainers about wireless despite marketing material clearly stating tri-mode. |
|
||||
| Shortcut Studio | Selling tri-mode boards based on QMK without sources, just `via.json` provided. |
|
||||
| Tacworks | Selling tri-mode boards based on QMK, crippled firmware already merged into QMK without wireless without QMK team realising. |
|
||||
| TKD / Vertex | Selling tri-mode boards based on QMK without sources, attempted upstreaming crippled firmware without wireless. |
|
||||
| WOBKEY | Selling tri-mode boards based on QMK without sources, attempted upstreaming crippled firmware without wireless. |
|
||||
| Weikav | Selling tri-mode boards based on QMK without sources, just `via.json` provided. |
|
||||
| Womier | Selling tri-mode boards based on QMK without sources, attempted upstreaming crippled firmware without wireless. |
|
||||
| Wuque Studio | Selling wired and tri-mode boards based on QMK without sources, just `via.json` provided. |
|
||||
| Zuoya | Selling tri-mode boards based on QMK without sources, just `via.json` provided. |
|
||||
|
||||
::: danger Violations
|
||||
Links are not provided above as the QMK team does not wish to inadvertently promote purchases of boards in violation of QMK's license.
|
||||
:::
|
||||
|
||||
## Licensing
|
||||
|
||||
QMK Firmware's license requires full disclosure of source code for any firmware which is based on QMK. This includes any of the following scenarios:
|
||||
|
||||
* Use of public QMK Firmware, but with "closed source" privately-held board definitions
|
||||
* Vendor-customised QMK Firmware, which the vendor keeps private for building their own boards
|
||||
* Any other non-QMK firmware which includes portions of QMK Firmware, such as adaptation of `via.c` into any other non-QMK firmware, even if used as a reference when translated to another programming language.
|
||||
|
||||
As per the GPL license requirements, vendors must provide entire source code for the as-shipped firmware.
|
||||
|
||||
QMK has traditionally been lenient with this clause -- providing source code to the QMK community is necessary but reproducing the exact build may not be possible. QMK has required functionally-equivalent source code to be made available. In rare cases exact code may be requested; vendors must keep copies regardless.
|
||||
|
||||
At minimum, vendors must provide the source code through some distribution mechanism. This could potentially be an clearly available downloadable copy of the code online, a fork of QMK Firmware, or even a DVD accompanying the product in the box.
|
||||
|
||||
If sources are unable to be provided in a timely fashion, QMK may revoke the vendor's license, effectively rendering them unable to leverage QMK.
|
||||
|
||||
Vendors choosing to keep things closed-source because of a desire to have a "competitive edge" compared to other vendors is unacceptable to both QMK and the community, and is a breach of the QMK license. There's no reason to do so; any new or interesting vendor-specific feature will be quickly replicated by other vendors or the community anyway.
|
||||
|
||||
## QMK PR Considerations
|
||||
|
||||
Vendors who submit PRs to QMK Firmware whilst not providing full sources for all of their license-violating boards will be put on hold until source code for all violating boards is provided. Intentional deception may result in boards being removed from QMK and all future PRs for that manufacturer being denied outright.
|
||||
|
||||
Submitting crippled source code in order to attain a merge into QMK Firmware to pave the way for VIA support is unacceptable. This includes submitting a wired-only firmware for a wireless-capable board, or any other PR which does not include key features as-advertised.
|
||||
|
||||
Reusing the `VID` and `PID` for multiple boards (such as for two variants, wired and wireless) is an unacceptable scenario as this creates confusion for support. Many customers have flashed boards with the wrong firmware, which could have been avoided if vendors were obvious about their board identification mechanisms.
|
||||
|
||||
If there is sufficient ambiguity about a board, supporting evidence will need to be presented to the QMK team. This may include impartial third parties who can demonstrate a board's existence and can confirm its feature set, such as well-known content producers; popular review sites or notable video creators may be leveraged. If such evidence is unavailable, as a last resort the vendor may be required to ship a fully functional board in full retail packaging to QMK maintainers for verification. Engineering samples will not be accepted, as one-off boards have been deceptively used in the past.
|
||||
|
||||
PRs submitted to upstream QMK should not expect an instant merge just because source code has been provided -- code from OEMs has historically been of a quality lower than QMK standards, so as per the [PR checklist](https://docs.qmk.fm/pr_checklist) submitters should make the changes as small as possible and be prepared to change their implementation.
|
||||
|
||||
## Detection
|
||||
|
||||
If the QMK team identifies or is informed of a license violation from a vendor:
|
||||
|
||||
* Any current and future PRs for that vendor will be indefinitely put on hold, preventing merge into QMK Firmware, thus preventing any out-of-the-box VIA support
|
||||
* Any existing keyboards from the vendor may be removed from QMK Firmware
|
||||
* Vendors will be added to the _offending vendors_ list above
|
||||
|
||||
Repeated violations may result in that vendor being disallowed from contributing the QMK in its entirety. In the worst case, the QMK team may choose to revoke a vendor's license to use QMK Firmware outright.
|
||||
|
||||
## Remediation
|
||||
|
||||
Vendors must provide fully-featured source code for each of their identified violations, matching the feature capabilities of their as-shipped products. This will usually be in their own fork of QMK Firmware while awaiting a merge into upstream.
|
||||
|
||||
Once all identified violations have been remediated, current and future PRs will no longer be on hold and the vendor will be removed from the offending vendors list above.
|
@@ -4,7 +4,7 @@ Your computer keyboard has a processor inside of it, similar to the one inside y
|
||||
|
||||
QMK tries to put a lot of power into your hands by making easy things easy, and hard things possible. You don't have to know how to program to create powerful keymaps — you only have to follow a few simple syntax rules.
|
||||
|
||||
Not sure if your keyboard can run QMK? If it's a mechanical keyboard you built yourself chances are good it can. We support a [large number of hobbyist boards](https://qmk.fm/keyboards/). If your current keyboard can't run QMK there are a lot of choices out there for boards that do.
|
||||
Not sure if your keyboard can run QMK? If it's a mechanical keyboard you built yourself chances are good it can. We support a [large number of hobbyist boards](https://browse.qmk.fm/). If your current keyboard can't run QMK there are a lot of choices out there for boards that do.
|
||||
|
||||
::: tip Is This Guide For Me?
|
||||
If the thought of programming intimidates you, please [take a look at our online GUI](newbs_building_firmware_configurator) instead.
|
||||
|
@@ -42,7 +42,7 @@ Look at the output from that command, you should see something like this:
|
||||
Ψ Created a new keymap called <github_username> in: /home/me/qmk_firmware/keyboards/clueboard/66/rev3/keymaps/<github_username>.
|
||||
```
|
||||
|
||||
This is the location of your new `keymap.c` file.
|
||||
This is the location of your new keymap file. Your keyboards default keymap file may be a `.json` file or a `.c` file. If your keymap is a `.json` file it can be converted to a `.c` file using QMK's [`json2c`](cli_commands#qmk-json2c) utility.
|
||||
|
||||
## Open `keymap.c` In Your Favorite Text Editor
|
||||
|
||||
|
@@ -15,7 +15,7 @@ Different keyboards have different ways to enter this special mode. If your PCB
|
||||
* Press the physical `RESET` button, usually located on the underside of the PCB
|
||||
* Locate header pins on the PCB labeled `RESET` and `GND`, and short them together while plugging your PCB in
|
||||
|
||||
If you've attempted all of the above to no avail, and the main chip on the board says `STM32` or `RP2-B1` on it, this may be a bit more complicated. Generally your best bet is to ask on [Discord](https://discord.gg/Uq7gcHh) for assistance. It's likely some photos of the board will be asked for -- if you can get them ready beforehand it'll help move things along!
|
||||
If you've attempted all of the above to no avail, and the main chip on the board says `STM32` or `RP2-B1` on it, this may be a bit more complicated. Generally your best bet is to ask on [Discord](https://discord.gg/qmk) for assistance. It's likely some photos of the board will be asked for -- if you can get them ready beforehand it'll help move things along!
|
||||
|
||||
Otherwise, you should see a message in yellow, similar to this in QMK Toolbox:
|
||||
|
||||
@@ -129,4 +129,4 @@ Congrats! Your custom firmware has been programmed to your keyboard and you're r
|
||||
With a little bit of luck everything will work perfectly, but if not there are steps that will help you figure out what's wrong.
|
||||
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.
|
||||
|
||||
Still not working? Browse the FAQ topics for more information, or [chat with us on Discord](https://discord.gg/Uq7gcHh).
|
||||
Still not working? Browse the FAQ topics for more information, or [chat with us on Discord](https://discord.gg/qmk).
|
||||
|
@@ -177,12 +177,13 @@ You'll need to perform some modifications to the file above in order to target y
|
||||
Windows builds of QMK Firmware are generally compiled using QMK MSYS, and the path to gdb's location (`C:\\QMK_MSYS\\mingw64\\bin`) needs to be specified under `armToolchainPath` for it to be detected. You may also need to change the GDB path to point at `C:\\QMK_MSYS\\mingw64\\bin\\gdb-multiarch.exe` in the VSCode Cortex-Debug user settings: 
|
||||
:::
|
||||
|
||||
Optionally, the following modifications should also be made to the keyboard's `rules.mk` file to disable optimisations -- not strictly required but will ensure breakpoints and variable viewing works correctly:
|
||||
The following modifications must be made to the keyboard's `rules.mk` file to enable debug information and disable optimisations -- this will ensure breakpoints and variable viewing works correctly:
|
||||
```makefile
|
||||
# Enable debug information in the final binaries
|
||||
DEBUG_ENABLE = yes
|
||||
# Disable optimisations for debugging purposes
|
||||
LTO_ENABLE = no
|
||||
OPT = g
|
||||
DEBUG = 3
|
||||
```
|
||||
|
||||
At this point, you should build and flash your firmware through normal methods (`qmk compile ...` and `qmk flash ...`).
|
||||
|
@@ -4,52 +4,51 @@ This page describes the support for [Compatible Microcontrollers](compatible_mic
|
||||
|
||||
If you have not yet you should read the [Keyboard Guidelines](hardware_keyboard_guidelines) to get a sense of how keyboards fit into QMK.
|
||||
|
||||
|
||||
QMK has a number of features to simplify working with keyboards. For most, you don't have to write a single line of code. To get started, run `qmk new-keyboard`:
|
||||
|
||||
```
|
||||
$ qmk new-keyboard
|
||||
Ψ Generating a new QMK keyboard directory
|
||||
|
||||
Name Your Keyboard Project
|
||||
For more infomation, see:
|
||||
https://docs.qmk.fm/hardware_keyboard_guidelines#naming-your-keyboardproject
|
||||
Ψ Name Your Keyboard Project
|
||||
Ψ For more information, see:
|
||||
https://docs.qmk.fm/hardware_keyboard_guidelines#naming-your-keyboard-project
|
||||
Keyboard Name? mycoolkeeb
|
||||
Ψ Attribution
|
||||
Ψ Used for maintainer, copyright, etc.
|
||||
Your GitHub Username? [jsmith]
|
||||
Ψ More Attribution
|
||||
Ψ Used for maintainer, copyright, etc.
|
||||
Your Real Name? [John Smith]
|
||||
Ψ Pick Base Layout
|
||||
Ψ As a starting point, one of the common layouts can be used to
|
||||
bootstrap the process
|
||||
Default Layout?
|
||||
1. 60_abnt2
|
||||
...
|
||||
65. none of the above
|
||||
Please enter your choice: [65]
|
||||
Ψ What Powers Your Project
|
||||
Ψ Is your board using a separate development board, such as a Pro Micro,
|
||||
or is the microcontroller integrated onto the PCB?
|
||||
|
||||
keyboard Name? mycoolkeeb
|
||||
|
||||
Attribution
|
||||
Used for maintainer, copyright, etc
|
||||
|
||||
Your GitHub Username? [jsmith]
|
||||
|
||||
More Attribution
|
||||
Used for maintainer, copyright, etc
|
||||
|
||||
Your Real Name? [John Smith]
|
||||
|
||||
Pick Base Layout
|
||||
As a starting point, one of the common layouts can be used to bootstrap the process
|
||||
|
||||
Default Layout?
|
||||
1. 60_ansi
|
||||
...
|
||||
50. tkl_iso
|
||||
51. none of the above
|
||||
Please enter your choice: [51]
|
||||
|
||||
What Powers Your Project
|
||||
For more infomation, see:
|
||||
https://docs.qmk.fm/#/compatible_microcontrollers
|
||||
|
||||
MCU?
|
||||
1. atmega32u4
|
||||
...
|
||||
22. STM32F303
|
||||
Please enter your choice: [12]
|
||||
For more information, see:
|
||||
https://docs.qmk.fm/compatible_microcontrollers
|
||||
Using a Development Board? [y/n] y
|
||||
Ψ Select Development Board
|
||||
Ψ For more information, see:
|
||||
https://docs.qmk.fm/compatible_microcontrollers
|
||||
Development Board?
|
||||
1. bit_c_pro
|
||||
...
|
||||
14. promicro
|
||||
...
|
||||
18. svlinky
|
||||
Please enter your choice: [14]
|
||||
Ψ Created a new keyboard called mycoolkeeb.
|
||||
Ψ To start working on things, `cd` into keyboards/mycoolkeeb,
|
||||
Ψ or open the directory in your preferred text editor.
|
||||
Ψ And build with qmk compile -kb mycoolkeeb -km default.
|
||||
Ψ Build Command: qmk compile -kb mycoolkeeb -km default.
|
||||
Ψ Project Location: /Users/jsmith/qmk_firmware/keyboards/mycoolkeeb.
|
||||
Ψ Now update the config files to match the hardware!
|
||||
```
|
||||
|
||||
This will create all the files needed to support your new keyboard, and populate the settings with default values. Now you just need to customize it for your keyboard.
|
||||
@@ -58,13 +57,13 @@ This will create all the files needed to support your new keyboard, and populate
|
||||
|
||||
This is where you'll describe your keyboard. Please follow the [Keyboard Readme Template](documentation_templates#keyboard-readmemd-template) when writing your `readme.md`. You're encouraged to place an image at the top of your `readme.md`, please use an external service such as [Imgur](https://imgur.com) to host the images.
|
||||
|
||||
## `info.json`
|
||||
## `keyboard.json`
|
||||
|
||||
The `info.json` file is where you configure the hardware and feature set for your keyboard. There are a lot of options that can be placed in that file, too many to list here. For a complete overview of available options see the [Data Driven Configuration Options](reference_info_json) page.
|
||||
The `keyboard.json` file is where you configure the hardware and feature set for your keyboard. There are a lot of options that can be placed in that file, too many to list here. For a complete overview of available options see the [Data Driven Configuration Options](reference_info_json) page.
|
||||
|
||||
### Hardware Configuration
|
||||
|
||||
At the top of the `info.json` you'll find USB related settings. These control how your keyboard appears to the Operating System. If you don't have a good reason to change you should leave the `usb.vid` as `0xFEED`. For the `usb.pid` you should pick a number that is not yet in use.
|
||||
At the top of the `keyboard.json` you'll find USB related settings. These control how your keyboard appears to the Operating System. If you don't have a good reason to change you should leave the `usb.vid` as `0xFEED`. For the `usb.pid` you should pick a number that is not yet in use.
|
||||
|
||||
Do change the `manufacturer` and `keyboard_name` lines to accurately reflect your keyboard.
|
||||
|
||||
@@ -82,10 +81,11 @@ Do change the `manufacturer` and `keyboard_name` lines to accurately reflect you
|
||||
Windows and macOS will display the `manufacturer` and `keyboard_name` in the list of USB devices. `lsusb` on Linux instead prefers the values in the list maintained by the [USB ID Repository](http://www.linux-usb.org/usb-ids.html). By default, it will only use `manufacturer` and `keyboard_name` if the list does not contain that `usb.vid` / `usb.pid`. `sudo lsusb -v` will show the values reported by the device, and they are also present in kernel logs after plugging it in.
|
||||
:::
|
||||
|
||||
|
||||
### Matrix Configuration
|
||||
|
||||
The next section of the `info` file deals with your keyboard's matrix. The first thing you should define is which pins on your MCU are connected to rows and columns. To do so simply specify the names of those pins:
|
||||
The next section of the `keyboard.json` deals with your keyboard's matrix. The first thing you should define is which pins on your MCU are connected to rows and columns. To do so simply specify the names of those pins:
|
||||
|
||||
#### Diode Matrix
|
||||
|
||||
```json
|
||||
"matrix_pins": {
|
||||
@@ -94,7 +94,7 @@ The next section of the `info` file deals with your keyboard's matrix. The first
|
||||
},
|
||||
```
|
||||
|
||||
The size of the `matrix_pins.cols` and `matrix_pins.rows` arrays infer the size of the matrix (previously `MATRIX_ROWS` and `MATRIX_COLS`).
|
||||
The matrix dimensions are inferred from the length of the `matrix_pins.cols` and `matrix_pins.rows` arrays (previously specified explicitly in `config.h` with `MATRIX_ROWS` and `MATRIX_COLS`).
|
||||
|
||||
Finally, you can specify the direction your diodes point. This can be `COL2ROW` or `ROW2COL`.
|
||||
|
||||
@@ -103,54 +103,56 @@ Finally, you can specify the direction your diodes point. This can be `COL2ROW`
|
||||
```
|
||||
|
||||
#### Direct Pin Matrix
|
||||
To configure a keyboard where each switch is connected to a separate pin and ground instead of sharing row and column pins, use `matrix_pins.direct`. The mapping defines the pins of each switch in rows and columns, from left to right. The size of the `matrix_pins.direct` array infers the size of the matrix. Use `NO_PIN` to fill in blank spaces. Overrides the behaviour of `diode_direction`, `matrix_pins.cols` and `matrix_pins.rows`.
|
||||
|
||||
To configure a keyboard where each switch is connected to a separate pin and ground instead of sharing row and column pins, use `matrix_pins.direct`. This overrides the behaviour of `diode_direction`, `matrix_pins.cols` and `matrix_pins.rows`, and they should not be specified together.
|
||||
|
||||
```json
|
||||
"matrix_pins": {
|
||||
"direct": [
|
||||
["F1", "E6", "B0", "B2", "B3" ],
|
||||
["F5", "F0", "B1", "B7", "D2" ],
|
||||
["F6", "F7", "C7", "D5", "D3" ],
|
||||
["B5", "C6", "B6", "NO_PIN", "NO_PIN"]
|
||||
["F1", "E6", "B0", "B2", "B3"],
|
||||
["F5", "F0", "B1", "B7", "D2"],
|
||||
["F6", "F7", "C7", "D5", "D3"],
|
||||
["B5", "C6", "B6", null, null]
|
||||
]
|
||||
},
|
||||
```
|
||||
|
||||
### Layout macros
|
||||
Here, the matrix dimensions are inferred directly from the dimensions of the `matrix_pins.direct` array. Since there are no row or column pins to prescribe the matrix dimensions, you can arrange it however you like. Each "row" must contain the same number of "column"s; use `null` to fill in blank spaces, but try to minimize them.
|
||||
|
||||
Next is configuring Layout Macro(s). These define the physical arrangement of keys, and its position within the matrix that a switch are connected to. This allows you to have a physical arrangement of keys that differs from the wiring matrix.
|
||||
### Layout Macros
|
||||
|
||||
Next is configuring layout macro(s). These define the physical arrangement of keys, and their position within the matrix that switches are connected to. This allows you to have a physical arrangement of keys that differs from the wiring matrix.
|
||||
|
||||
```json
|
||||
"layouts": {
|
||||
"LAYOUT_ortho_4x4": {
|
||||
"layout": [
|
||||
{ "matrix": [0, 0], "x": 0, "y": 0 },
|
||||
{ "matrix": [0, 1], "x": 1, "y": 0 },
|
||||
{ "matrix": [0, 2], "x": 2, "y": 0 },
|
||||
{ "matrix": [0, 3], "x": 3, "y": 0 },
|
||||
{ "matrix": [1, 0], "x": 0, "y": 1 },
|
||||
{ "matrix": [1, 1], "x": 1, "y": 1 },
|
||||
{ "matrix": [1, 2], "x": 2, "y": 1 },
|
||||
{ "matrix": [1, 3], "x": 3, "y": 1 },
|
||||
{ "matrix": [2, 0], "x": 0, "y": 2 },
|
||||
{ "matrix": [2, 1], "x": 1, "y": 2 },
|
||||
{ "matrix": [2, 2], "x": 2, "y": 2 },
|
||||
{ "matrix": [2, 3], "x": 3, "y": 2 },
|
||||
{ "matrix": [3, 0], "x": 0, "y": 3 },
|
||||
{ "matrix": [3, 1], "x": 1, "y": 3 },
|
||||
{ "matrix": [3, 2], "x": 2, "y": 3 },
|
||||
{ "matrix": [3, 3], "x": 3, "y": 3 }
|
||||
{"matrix": [0, 0], "x": 0, "y": 0},
|
||||
{"matrix": [0, 1], "x": 1, "y": 0},
|
||||
{"matrix": [0, 2], "x": 2, "y": 0},
|
||||
{"matrix": [0, 3], "x": 3, "y": 0},
|
||||
{"matrix": [1, 0], "x": 0, "y": 1},
|
||||
{"matrix": [1, 1], "x": 1, "y": 1},
|
||||
{"matrix": [1, 2], "x": 2, "y": 1},
|
||||
{"matrix": [1, 3], "x": 3, "y": 1},
|
||||
{"matrix": [2, 0], "x": 0, "y": 2},
|
||||
{"matrix": [2, 1], "x": 1, "y": 2},
|
||||
{"matrix": [2, 2], "x": 2, "y": 2},
|
||||
{"matrix": [2, 3], "x": 3, "y": 2},
|
||||
{"matrix": [3, 0], "x": 0, "y": 3},
|
||||
{"matrix": [3, 1], "x": 1, "y": 3},
|
||||
{"matrix": [3, 2], "x": 2, "y": 3},
|
||||
{"matrix": [3, 3], "x": 3, "y": 3}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
In the above example,
|
||||
In the above example,
|
||||
|
||||
* `LAYOUT_ortho_4x4` defines the name of the layout macro
|
||||
* It must conform to the [layout guidelines](hardware_keyboard_guidelines#ltkeyboard_namehgt)
|
||||
* `"matrix": [0, 0]` defines the electrical position
|
||||
* It must conform to the [layout guidelines](hardware_keyboard_guidelines#keyboard-name-h)
|
||||
* `"matrix": [0, 0]` defines the matrix row and column that the key is associated with
|
||||
|
||||
::: tip
|
||||
See also: [Split Keyboard Layout Macro](features/split_keyboard#layout-macro) and [Matrix to Physical Layout](understanding_qmk#matrix-to-physical-layout-map).
|
||||
@@ -158,9 +160,10 @@ See also: [Split Keyboard Layout Macro](features/split_keyboard#layout-macro) an
|
||||
|
||||
## Additional Configuration
|
||||
|
||||
There are a lot of features that can be turned on or off, configured or tuned. Some of these have yet to be migrated over to [Data Driven Configuration](data_driven_config). The following sections cover the process for when an `info.json` option is unavailable.
|
||||
There are a lot of features that can be turned on or off, configured or tuned. Some of these have yet to be migrated over to [Data Driven Configuration](data_driven_config). The following sections cover the process for when a data-driven option is unavailable.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
For available options for `config.h`, you should see the [Config Options](config_options#the-configh-file) page for more details.
|
||||
|
||||
### Build Options
|
||||
|
@@ -2,7 +2,7 @@
|
||||
|
||||
This is a non-exhaustive checklist of what the QMK Collaborators will be checking when reviewing submitted PRs.
|
||||
|
||||
If there are any inconsistencies with these recommendations, you're best off [creating an issue](https://github.com/qmk/qmk_firmware/issues/new) against this document, or getting in touch with a QMK Collaborator on [Discord](https://discord.gg/Uq7gcHh).
|
||||
If there are any inconsistencies with these recommendations, you're best off [creating an issue](https://github.com/qmk/qmk_firmware/issues/new) against this document, or getting in touch with a QMK Collaborator on [Discord](https://discord.gg/qmk).
|
||||
|
||||
## Requirements for all PRs
|
||||
|
||||
@@ -44,12 +44,14 @@ If there are any inconsistencies with these recommendations, you're best off [cr
|
||||
Note that personal keymap submissions will no longer be accepted. This section applies to manufacturer-supported keymaps. Please see this [issue](https://github.com/qmk/qmk_firmware/issues/22724) for more information.
|
||||
:::
|
||||
|
||||
- PRs for vendor specific keymaps will be permitted. The naming convention for these should be `default_${vendor}`, `via_${vendor}` i.e. `via_clueboard`.
|
||||
- vendor specific keymaps do not necessarily need to be "vanilla" and can be more richly featured than `default` or `via` stock keymaps.
|
||||
- PRs for vendor specific keymaps will be permitted. The naming convention for these should be `default_${vendor}` i.e. `default_clueboard`.
|
||||
- vendor specific keymaps do not necessarily need to be "vanilla" and can be more richly featured than `default` stock keymaps.
|
||||
- `#include QMK_KEYBOARD_H` preferred to including specific board files
|
||||
- prefer layer enums to #defines
|
||||
- custom keycode enums must have first entry = `QK_USER`
|
||||
- some care with spacing (e.g., alignment on commas or first char of keycodes) makes for a much nicer-looking keymap. Spaces are preferred to tabs
|
||||
- keymaps should not enable VIA
|
||||
- keymaps targeting VIA support should be submitted to the [VIA QMK Userspace](https://github.com/the-via/qmk_userspace_via) repository
|
||||
|
||||
## Keyboard PRs
|
||||
|
||||
@@ -136,12 +138,12 @@ https://github.com/qmk/qmk_firmware/pulls?q=is%3Apr+is%3Aclosed+label%3Akeyboard
|
||||
- `keymaps/default/keymap.c`
|
||||
- `QMKBEST`/`QMKURL` example macros removed
|
||||
- if using `MO(1)` and `MO(2)` keycodes together to access a third layer, the [Tri Layer](features/tri_layer) feature should be used, rather than manually implementing this using `layer_on/off()` and `update_tri_layer()` functions in the keymap's `process_record_user()`.
|
||||
- default (and via) keymaps should be "pristine"
|
||||
- default keymaps should be "pristine"
|
||||
- bare minimum to be used as a "clean slate" for another user to develop their own user-specific keymap
|
||||
- what does pristine mean? no custom keycodes. no advanced features like tap dance or macros. basic mod taps and home row mods would be acceptable where their use is necessary
|
||||
- standard layouts preferred in these keymaps, if possible
|
||||
- should use [encoder map feature](features/encoders#encoder-map), rather than `encoder_update_user()`
|
||||
- default keymap should not enable VIA -- the VIA integration documentation requires a keymap called `via`
|
||||
- default keymap should not enable VIA -- keymaps targeting VIA support should be submitted to the [VIA QMK Userspace](https://github.com/the-via/qmk_userspace_via) repository
|
||||
- submitters can add an example (or bells-and-whistles) keymap showcasing capabilities in the same PR but it shouldn't be embedded in the 'default' keymap
|
||||
- submitters can also have a "manufacturer-matching" keymap that mirrors existing functionality of the commercial product, if porting an existing board
|
||||
- Do not include VIA json files in the PR. These do not belong in the QMK repository as they are not used by QMK firmware -- they belong in the [VIA Keyboard Repo](https://github.com/the-via/keyboards)
|
||||
@@ -174,7 +176,7 @@ Also, specific to ChibiOS:
|
||||
- all core PRs must now target `develop` branch, which will subsequently be merged back to `master` on the breaking changes timeline
|
||||
- as indicated above, the smallest set of changes to core components should be included in each PR
|
||||
- PRs containing multiple areas of change will be asked to be split up and raised separately
|
||||
- keyboard and keymap changes should only be included if they affect base keyboard builds, or the default-like `default`, `via`, `default_????` keymaps etc.
|
||||
- keyboard and keymap changes should only be included if they affect base keyboard builds, or the default-like `default`, `default_????` keymaps etc.
|
||||
- keymap modifications for anything other than the default-like keymaps **should not be included in the initial PR** in order to simplify the review process
|
||||
- the core PR submitter should submit a followup PR affecting other keymaps after initial PR merge
|
||||
- large-scale refactoring or consolidation PRs that affect other keymaps (such as renaming keycodes) should always be raised separately
|
||||
|
@@ -28,6 +28,8 @@ Supported devices:
|
||||
| ILI9341 | RGB LCD | 240x320 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9341_spi` |
|
||||
| ILI9486 | RGB LCD | 320x480 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9486_spi` |
|
||||
| ILI9488 | RGB LCD | 320x480 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ili9488_spi` |
|
||||
| LD7032 (SPI) | Monochrome OLED | 128x40 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ld7032_spi` |
|
||||
| LD7032 (I2C) | Monochrome OLED | 128x40 | I2C | `QUANTUM_PAINTER_DRIVERS += ld7032_i2c` |
|
||||
| SSD1351 | RGB OLED | 128x128 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += ssd1351_spi` |
|
||||
| ST7735 | RGB LCD | 132x162, 80x160 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += st7735_spi` |
|
||||
| ST7789 | RGB LCD | 240x320, 240x240 | SPI + D/C + RST | `QUANTUM_PAINTER_DRIVERS += st7789_spi` |
|
||||
@@ -478,6 +480,40 @@ Native color format mono2 is compatible with SH1106
|
||||
|
||||
SSD1306 and SH1106 are almost entirely identical, to the point of being indisinguishable by Quantum Painter. Enable SH1106 support in Quantum Painter and create SH1106 devices in firmware to perform drawing operations on SSD1306 displays.
|
||||
|
||||
==== LD7032
|
||||
|
||||
Enabling support for the LD7032 in Quantum Painter is done by adding the following to `rules.mk`:
|
||||
|
||||
```make
|
||||
QUANTUM_PAINTER_ENABLE = yes
|
||||
# For SPI:
|
||||
QUANTUM_PAINTER_DRIVERS += ld7032_spi
|
||||
# For I2C:
|
||||
QUANTUM_PAINTER_DRIVERS += ld7032_i2c
|
||||
```
|
||||
|
||||
Creating a SH1106 device in firmware can then be done with the following APIs:
|
||||
|
||||
```c
|
||||
// SPI-based LD7032:
|
||||
painter_device_t qp_ld7032_make_spi_device(uint16_t panel_width, uint16_t panel_height, pin_t chip_select_pin, pin_t dc_pin, pin_t reset_pin, uint16_t spi_divisor, int spi_mode);
|
||||
// I2C-based LD7032:
|
||||
painter_device_t qp_ld7032_make_i2c_device(uint16_t panel_width, uint16_t panel_height, uint8_t i2c_address);
|
||||
```
|
||||
|
||||
The device handle returned from the `qp_ld7032_make_???_device` function can be used to perform all other drawing operations.
|
||||
|
||||
The maximum number of displays of each type can be configured by changing the following in your `config.h` (default is 1):
|
||||
|
||||
```c
|
||||
// 3 SPI displays:
|
||||
#define LD7032_NUM_SPI_DEVICES 3
|
||||
// 3 I2C displays:
|
||||
#define LD7032_NUM_I2C_DEVICES 3
|
||||
```
|
||||
|
||||
Native color format mono2 is compatible with LD7032.
|
||||
|
||||
:::::
|
||||
|
||||
===== Surface
|
||||
|
@@ -69,7 +69,7 @@ layer_state_t layer_state_set_user(layer_state_t state) {
|
||||
|
||||
Do you want to set the default layer, so that it's retained even after you unplug the board? If so, this is the function for you.
|
||||
|
||||
To use this, you would use `set_single_persistent_default_layer(layer)`. If you have a name defined for your layer, you can use that instead (such as _QWERTY, _DVORAK or _COLEMAK).
|
||||
To do this, you would use `set_single_persistent_default_layer(layer)`. If you have a name defined for your layer, you can use that instead (such as _QWERTY, _DVORAK or _COLEMAK).
|
||||
|
||||
This will set the default layer, update the persistent settings, and play a tune if you have [Audio](features/audio) enabled on your board, and the default layer sounds set.
|
||||
|
||||
@@ -82,6 +82,8 @@ To configure the default layer sounds, you would want to define this in your `co
|
||||
}
|
||||
```
|
||||
|
||||
If you do not require it to be retained after you unplug the board, use `set_single_default_layer(layer)` instead.
|
||||
|
||||
|
||||
::: tip
|
||||
There are a large number of predefined songs in [quantum/audio/song_list.h](https://github.com/qmk/qmk_firmware/blob/master/quantum/audio/song_list.h) that you can use.
|
||||
@@ -99,7 +101,7 @@ To reset to the bootloader use `QK_BOOTLOADER` or `QK_BOOT` keycode or `reset_ke
|
||||
|
||||
## Wiping the EEPROM (Persistent Storage)
|
||||
|
||||
If you're having issues with Audio, RGB Underglow, backlighting or keys acting weird, then you can reset the EEPROM (persistent setting storage). To force an EEPROM reset, use the [`EE_CLR` keycode](quantum_keycodes) or [Bootmagic Lite](features/bootmagic) functionality. If neither of those are an option, then you can use a custom macro to do so.
|
||||
If you're having issues with Audio, RGB Underglow, backlighting or keys acting weird, then you can reset the EEPROM (persistent setting storage). To force an EEPROM reset, use the [`EE_CLR` keycode](quantum_keycodes) or [Bootmagic](features/bootmagic) functionality. If neither of those are an option, then you can use a custom macro to do so.
|
||||
|
||||
To wipe the EEPROM, run `eeconfig_init()` from your function or macro to reset most of the settings to default.
|
||||
|
||||
|
@@ -156,25 +156,25 @@ For more on the `info.json` files, see [`info.json` Format](reference_info_json)
|
||||
|
||||
The Configurator's API uses the layout macro and the JSON file we've given it to create a visual representation of the keyboard that has each visual object tied to a specific key, in sequence:
|
||||
|
||||
key in layout macro | JSON object used
|
||||
:---: | :----
|
||||
k00 | {"label":"Num Lock", "x":0, "y":0}
|
||||
k01 | {"label":"/", "x":1, "y":0}
|
||||
k02 | {"label":"*", "x":2, "y":0}
|
||||
k03 | {"label":"-", "x":3, "y":0}
|
||||
k10 | {"label":"7", "x":0, "y":1}
|
||||
k11 | {"label":"8", "x":1, "y":1}
|
||||
k12 | {"label":"9", "x":2, "y":1}
|
||||
k13 | {"label":"+", "x":3, "y":1, "h":2}
|
||||
k20 | {"label":"4", "x":0, "y":2}
|
||||
k21 | {"label":"5", "x":1, "y":2}
|
||||
k22 | {"label":"6", "x":2, "y":2}
|
||||
k30 | {"label":"1", "x":0, "y":3}
|
||||
k31 | {"label":"2", "x":1, "y":3}
|
||||
k32 | {"label":"3", "x":2, "y":3}
|
||||
k33 | {"label":"Enter", "x":3, "y":3, "h":2}
|
||||
k40 | {"label":"0", "x":0, "y":4, "w":2}
|
||||
k42 | {"label":".", "x":2, "y":4}
|
||||
| Key in layout macro | JSON object used |
|
||||
| ------------------- | ---------------------------------------- |
|
||||
| k00 | `{"label":"Num Lock", "x":0, "y":0}` |
|
||||
| k01 | `{"label":"/", "x":1, "y":0}` |
|
||||
| k02 | `{"label":"*", "x":2, "y":0}` |
|
||||
| k03 | `{"label":"-", "x":3, "y":0}` |
|
||||
| k10 | `{"label":"7", "x":0, "y":1}` |
|
||||
| k11 | `{"label":"8", "x":1, "y":1}` |
|
||||
| k12 | `{"label":"9", "x":2, "y":1}` |
|
||||
| k13 | `{"label":"+", "x":3, "y":1, "h":2}` |
|
||||
| k20 | `{"label":"4", "x":0, "y":2}` |
|
||||
| k21 | `{"label":"5", "x":1, "y":2}` |
|
||||
| k22 | `{"label":"6", "x":2, "y":2}` |
|
||||
| k30 | `{"label":"1", "x":0, "y":3}` |
|
||||
| k31 | `{"label":"2", "x":1, "y":3}` |
|
||||
| k32 | `{"label":"3", "x":2, "y":3}` |
|
||||
| k33 | `{"label":"Enter", "x":3, "y":3, "h":2}` |
|
||||
| k40 | `{"label":"0", "x":0, "y":4, "w":2}` |
|
||||
| k42 | `{"label":".", "x":2, "y":4}` |
|
||||
|
||||
When a user selects the top-left key in the Configurator, and assigns Num Lock to it, the Configurator builds a keymap file with `KC_NUM` as the first key, and so on as the keymap is built. The `label` keys are not used; they are only for the user's reference in identifying specific keys when debugging the `info.json` file.
|
||||
|
||||
|
File diff suppressed because it is too large
Load Diff
@@ -2,9 +2,31 @@
|
||||
|
||||
Keyboards are able to support a wide range of languages. However, this support is not actually achieved within the keyboard itself - instead, it sends numerical codes, which the operating system maps to the appropriate characters depending on the user's configured keyboard layout. By default (and per the HID spec), this is the US ANSI layout. For example, when a Swedish person presses the key with the `å` character printed on it, the keyboard is *actually* sending the keycode for `[`.
|
||||
|
||||
Obviously, this can get confusing, so QMK provides language-specific keycode aliases for many keyboard layouts. These won't do much on their own - you still have to set the matching keyboard layout in your OS settings. Think of them more as keycap labels for your keymap.
|
||||
Obviously, this can get confusing, so QMK provides language-specific keycode aliases for many keyboard layouts. These are used in place of the `KC_` prefixed ones. They won't do much on their own - you still have to set the matching keyboard layout in your OS settings. Think of them more as keycap labels for your keymap. The language-specific keycode aliases are defined in the files listed in the [Keycodes Header](#header-files) column below.
|
||||
|
||||
Simply `#include` one of the keycode headers below at the top of your `keymap.c`, and assign the keycodes defined in the header in place of the `KC_` prefixed ones.
|
||||
## Selecting Your Host Keyboard Layout
|
||||
|
||||
To select a host keyboard layout, simply `#include` one of the [keycode headers](#header-files) below at the top of your `keymap.c`. Example:
|
||||
|
||||
```c
|
||||
#include QMK_KEYBOARD_H
|
||||
|
||||
#include "keymap_japanese.h" // [!code focus]
|
||||
```
|
||||
|
||||
Alternatively, if using `keymap.json`, add the `host_language` key as shown in the following example. The available languages are those with a _Sendstring LUT Header_ entry in one of the [Header Files](#header-files) tables.
|
||||
|
||||
```json
|
||||
{
|
||||
"keyboard": "handwired/my_macropad",
|
||||
"keymap": "my_keymap",
|
||||
"host_language": "swedish", // [!code focus]
|
||||
"layout": "LAYOUT_all",
|
||||
"layers": [
|
||||
["SE_ARNG"]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Sendstring Support
|
||||
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user