Compare commits
44 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
22b213e191 | ||
|
|
8522449ccf | ||
|
|
cbeab2ac4f | ||
|
|
aa5a6d38de | ||
|
|
a1096e1dec | ||
|
|
a9739f7868 | ||
|
|
a5fb7cfbc9 | ||
|
|
62d87fa446 | ||
|
|
8e5550dbb2 | ||
|
|
f4123acc72 | ||
|
|
98e65cf3e1 | ||
|
|
7d0fc5d486 | ||
|
|
1c1e8d7f7a | ||
|
|
d0db38cbdc | ||
|
|
1a32aa12e0 | ||
|
|
969f324de4 | ||
|
|
608bcf08fe | ||
|
|
97d622651a | ||
|
|
a8711b2b0a | ||
|
|
338a7ed6d5 | ||
|
|
911232abfc | ||
|
|
4eee8c1023 | ||
|
|
7e8690eae1 | ||
|
|
b9078609b6 | ||
|
|
fd61083710 | ||
|
|
082b69db91 | ||
|
|
92ead44cf6 | ||
|
|
61ecee1585 | ||
|
|
85fa06c3db | ||
|
|
eae39d37c6 | ||
|
|
7aed244aae | ||
|
|
880c0c8ee0 | ||
|
|
f31004ebec | ||
|
|
8f728aa731 | ||
|
|
45a5a94b96 | ||
|
|
bef5c95675 | ||
|
|
e5f47fa269 | ||
|
|
05ea735e86 | ||
|
|
35e62d236b | ||
|
|
fc55fcff3d | ||
|
|
b4bdf3f1d5 | ||
|
|
c4ccbf06e1 | ||
|
|
24c05ff1c7 | ||
|
|
65e1afe0af |
11
.github/workflows/ci_build_major_branch.yml
vendored
@@ -6,13 +6,13 @@ permissions:
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [master, develop]
|
||||
branches: [master, develop, xap]
|
||||
workflow_dispatch:
|
||||
inputs:
|
||||
branch:
|
||||
type: choice
|
||||
description: "Branch to build"
|
||||
options: [master, develop]
|
||||
options: [master, develop, xap]
|
||||
|
||||
env:
|
||||
# https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits
|
||||
@@ -52,7 +52,7 @@ jobs:
|
||||
run: |
|
||||
target_count=$( {
|
||||
qmk find -km default 2>/dev/null
|
||||
# qmk find -km xap 2>/dev/null
|
||||
qmk find -km xap 2>/dev/null
|
||||
} | sort | uniq | wc -l)
|
||||
slice_length=$((target_count / ($CONCURRENT_JOBS - 1))) # Err on the side of caution
|
||||
echo "slice_length=$slice_length" >> $GITHUB_OUTPUT
|
||||
@@ -63,8 +63,7 @@ jobs:
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
keymap: [default]
|
||||
# keymap: [default, xap]
|
||||
keymap: [default, xap]
|
||||
uses: ./.github/workflows/ci_build_major_branch_keymap.yml
|
||||
with:
|
||||
branch: ${{ inputs.branch || github.ref_name }}
|
||||
@@ -88,7 +87,7 @@ jobs:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Download firmwares
|
||||
uses: actions/download-artifact@v5
|
||||
uses: actions/download-artifact@v6
|
||||
with:
|
||||
pattern: firmware-*
|
||||
path: .
|
||||
|
||||
@@ -62,7 +62,7 @@ jobs:
|
||||
echo "targets=$(jq -c 'keys' targets.json)" >> $GITHUB_OUTPUT
|
||||
|
||||
- name: Upload targets json
|
||||
uses: actions/upload-artifact@v4
|
||||
uses: actions/upload-artifact@v5
|
||||
with:
|
||||
name: targets-${{ inputs.keymap }}
|
||||
path: targets.json
|
||||
@@ -92,7 +92,7 @@ jobs:
|
||||
uses: actions/checkout@v5
|
||||
|
||||
- name: Get target definitions
|
||||
uses: actions/download-artifact@v5
|
||||
uses: actions/download-artifact@v6
|
||||
with:
|
||||
name: targets-${{ inputs.keymap }}
|
||||
path: .
|
||||
@@ -112,7 +112,7 @@ jobs:
|
||||
qmk mass-compile -t -j $NCPUS -e DUMP_CI_METADATA=yes $(jq -r '.["${{ matrix.target }}"].targets' targets.json) || touch .failed
|
||||
|
||||
- name: Upload binaries
|
||||
uses: actions/upload-artifact@v4
|
||||
uses: actions/upload-artifact@v5
|
||||
with:
|
||||
name: firmware-${{ inputs.keymap }}-${{ matrix.target }}
|
||||
if-no-files-found: ignore
|
||||
@@ -139,14 +139,14 @@ jobs:
|
||||
uses: actions/checkout@v5
|
||||
|
||||
- name: Download firmwares
|
||||
uses: actions/download-artifact@v5
|
||||
uses: actions/download-artifact@v6
|
||||
with:
|
||||
pattern: firmware-${{ inputs.keymap }}-*
|
||||
path: .
|
||||
merge-multiple: true
|
||||
|
||||
- name: Upload all firmwares
|
||||
uses: actions/upload-artifact@v4
|
||||
uses: actions/upload-artifact@v5
|
||||
with:
|
||||
name: firmware-${{ inputs.keymap }}
|
||||
if-no-files-found: ignore
|
||||
|
||||
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.7.3
|
||||
uses: JamesIves/github-pages-deploy-action@v4.7.4
|
||||
with:
|
||||
token: ${{ secrets.GITHUB_TOKEN }}
|
||||
branch: gh-pages
|
||||
|
||||
2
.github/workflows/format.yml
vendored
@@ -36,7 +36,7 @@ jobs:
|
||||
|
||||
- name: Get changed files
|
||||
id: file_changes
|
||||
uses: tj-actions/changed-files@v46
|
||||
uses: tj-actions/changed-files@v47
|
||||
with:
|
||||
use_rest_api: true
|
||||
|
||||
|
||||
2
.github/workflows/lint.yml
vendored
@@ -27,7 +27,7 @@ jobs:
|
||||
|
||||
- name: Get changed files
|
||||
id: file_changes
|
||||
uses: tj-actions/changed-files@v46
|
||||
uses: tj-actions/changed-files@v47
|
||||
with:
|
||||
use_rest_api: true
|
||||
|
||||
|
||||
5
.gitignore
vendored
@@ -95,6 +95,11 @@ tags
|
||||
*.mpeg
|
||||
*.ttf
|
||||
*.otf
|
||||
# Un-ignore limited image file formats in docs
|
||||
!docs/public/**.gif
|
||||
!docs/public/**.jpg
|
||||
!docs/public/**.jpeg
|
||||
!docs/public/**.png
|
||||
|
||||
# Things Travis sees
|
||||
/.vs
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"license": "GPL-2.0-or-later",
|
||||
"devDependencies": {
|
||||
"vite": "^5.4.19",
|
||||
"vite": "^5.4.21",
|
||||
"vitepress": "^1.1.0",
|
||||
"vitepress-plugin-tabs": "^0.5.0",
|
||||
"vue": "^3.4.24"
|
||||
|
||||
@@ -766,10 +766,10 @@ tabbable@^6.2.0:
|
||||
resolved "https://registry.yarnpkg.com/tabbable/-/tabbable-6.2.0.tgz#732fb62bc0175cfcec257330be187dcfba1f3b97"
|
||||
integrity sha512-Cat63mxsVJlzYvN51JmVXIgNoUokrIaT2zLclCXjRd8boZ0004U4KCs/sToJ75C6sdlByWxpYnb5Boif1VSFew==
|
||||
|
||||
vite@^5.2.9, vite@^5.4.19:
|
||||
version "5.4.19"
|
||||
resolved "https://registry.yarnpkg.com/vite/-/vite-5.4.19.tgz#20efd060410044b3ed555049418a5e7d1998f959"
|
||||
integrity sha512-qO3aKv3HoQC8QKiNSTuUM1l9o/XX3+c+VTgLHbJWHZGeTPVAg2XwazI9UWzoxjIJCGCV2zU60uqMzjeLZuULqA==
|
||||
vite@^5.2.9, vite@^5.4.21:
|
||||
version "5.4.21"
|
||||
resolved "https://registry.yarnpkg.com/vite/-/vite-5.4.21.tgz#84a4f7c5d860b071676d39ba513c0d598fdc7027"
|
||||
integrity sha512-o5a9xKjbtuhY6Bi5S3+HvbRERmouabWbyUcpXXUA1u+GNUKoROi9byOJ8M0nHbHYHkYICiMlqxkg1KkYmm25Sw==
|
||||
dependencies:
|
||||
esbuild "^0.21.3"
|
||||
postcss "^8.4.43"
|
||||
|
||||
@@ -6,7 +6,7 @@ This page describes how QMK's data driven JSON configuration system works. It is
|
||||
|
||||
Historically QMK has been configured through a combination of two mechanisms- `rules.mk` and `config.h`. While this worked well when QMK was only a handful of keyboards we've grown to encompass nearly 4000 supported keyboards. That extrapolates out to 6000 configuration files under `keyboards/` alone! The freeform nature of these files and the unique patterns people have used to avoid duplication have made ongoing maintenance a challenge, and a large number of our keyboards follow patterns that are outdated and sometimes harder to understand.
|
||||
|
||||
We have also been working on bringing the power of QMK to people who aren't comformable with a CLI, and other projects such as VIA are working to make using QMK as easy as installing a program. These tools need information about how a keyboard is laid out or what pins and features are available so that users can take full advantage of QMK. We introduced `info.json` as a first step towards this. The QMK API is an effort to combine these 3 sources of information- `config.h`, `rules.mk`, and `info.json`- into a single source of truth that end-user tools can use.
|
||||
We have also been working on bringing the power of QMK to people who aren't comfortable with a CLI, and other projects such as VIA are working to make using QMK as easy as installing a program. These tools need information about how a keyboard is laid out or what pins and features are available so that users can take full advantage of QMK. We introduced `info.json` as a first step towards this. The QMK API is an effort to combine these 3 sources of information- `config.h`, `rules.mk`, and `info.json`- into a single source of truth that end-user tools can use.
|
||||
|
||||
Now we have support for generating `rules.mk` and `config.h` values from `info.json`, allowing us to have a single source of truth. This will allow us to use automated tooling to maintain keyboards saving a lot of time and maintenance work.
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ If Zadig lists one or more devices with the `HidUsb` driver, your keyboard is pr
|
||||
|
||||
If the arrow appears green, select the driver, and click **Install Driver**. See the [list of known bootloaders](#list-of-known-bootloaders) for the correct driver to install.
|
||||
|
||||

|
||||

|
||||
|
||||
Finally, unplug and replug the keyboard to make sure the new driver has been loaded. If you are using the QMK Toolbox to flash, exit and restart it too, as it can sometimes fail to recognize the driver change.
|
||||
|
||||
@@ -30,15 +30,15 @@ Finally, unplug and replug the keyboard to make sure the new driver has been loa
|
||||
|
||||
If you find that you can no longer type with the keyboard, you may have accidentally replaced the driver for the keyboard itself instead of for the bootloader. This can happen when the keyboard is not in the bootloader mode. You can easily confirm this in Zadig - a healthy keyboard has the `HidUsb` driver installed on all of its interfaces:
|
||||
|
||||

|
||||

|
||||
|
||||
Open the Device Manager, select **View → Devices by container**, and look for an entry with your keyboard's name.
|
||||
|
||||

|
||||

|
||||
|
||||
Right-click each entry and hit **Uninstall device**. Make sure to tick **Delete the driver software for this device** first if it appears.
|
||||
|
||||

|
||||

|
||||
|
||||
Click **Action → Scan for hardware changes**. At this point, you should be able to type again. Double check in Zadig that the keyboard device(s) are using the `HidUsb` driver. If so, you're all done, and your board should be functional again! Otherwise, repeat this process until Zadig reports the correct driver.
|
||||
|
||||
@@ -54,11 +54,11 @@ Open the Device Manager, select **View → Devices by container**, and look for
|
||||
|
||||
Find the `Inf name` value in the Details tab of the device properties. This should generally be something like `oemXX.inf`:
|
||||
|
||||

|
||||

|
||||
|
||||
Then, open a new Command Prompt window as an Administrator (type in `cmd` into the Start menu and press Ctrl+Shift+Enter). Run `pnputil /enum-drivers` to verify the `Inf name` matches the `Published Name` field of one of the entries:
|
||||
|
||||

|
||||

|
||||
|
||||
Run `pnputil /delete-driver oemXX.inf /uninstall`. This will delete the driver and remove it from any devices using it. Note that this will not uninstall the device itself.
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ As its name implies Direct Pin works by connecting one switch per pin. The other
|
||||
|
||||
Here is a schematic showing how we connect a single button to pin A3 on a ProMicro:
|
||||
|
||||

|
||||

|
||||
|
||||
Once you have wired your switches you can assign keycodes to each pin and build a firmware by selecting the MCU you are using from the Keyboard dropdown. Use this link to show only Easy Maker Direct Pin:
|
||||
|
||||
|
||||
@@ -38,7 +38,7 @@ Awesome! Open up a Pull Request for it. We'll review the code, and merge it!
|
||||
|
||||
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.
|
||||
In fact, we have a [whole page](https://qmk.fm/trademark) 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/qmk).
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ Keycodes are actually defined in [quantum/keycode.h](https://github.com/qmk/qmk_
|
||||
There are 3 standard keyboard layouts in use around the world- ANSI, ISO, and JIS. North America primarily uses ANSI, Europe and Africa primarily use ISO, and Japan uses JIS. Regions not mentioned typically use either ANSI or ISO. The keycodes corresponding to these layouts are shown here:
|
||||
|
||||
<!-- Source for this image: https://www.keyboard-layout-editor.com/#/gists/bf431647d1001cff5eff20ae55621e9a -->
|
||||

|
||||

|
||||
|
||||
## How Can I Make Custom Names For Complex Keycodes?
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ The feature maintains a small buffer of recent key presses. On each key press, i
|
||||
|
||||
The tricky part is how to efficiently check the buffer for typos. We don’t want to spend too much memory or time on storing or searching the typos. A good solution is to represent the typos with a trie data structure. A trie is a tree data structure where each node is a letter, and words are formed by following a path to one of the leaves.
|
||||
|
||||

|
||||

|
||||
|
||||
Since we search whether the buffer ends in a typo, we store the trie writing in reverse. The trie is queried starting from the last letter, then second to last letter, and so on, until either a letter doesn’t match or we reach a leaf, meaning a typo was found.
|
||||
|
||||
@@ -279,7 +279,7 @@ All autocorrection data is stored in a single flat array autocorrect_data. Each
|
||||
* 01 ⇒ branching node: a trie node with multiple children.
|
||||
* 10 ⇒ leaf node: a leaf, corresponding to a typo and storing its correction.
|
||||
|
||||

|
||||

|
||||
|
||||
**Branching node**. Each branch is encoded with one byte for the keycode (KC_A–KC_Z) followed by a link to the child node. Links between nodes are 16-bit byte offsets relative to the beginning of the array, serialized in little endian order.
|
||||
|
||||
|
||||
@@ -227,7 +227,7 @@ In this typical example, the backlight LEDs are all connected in parallel toward
|
||||
A pulldown resistor is also placed between the gate pin and ground to keep it at a defined state when it is not otherwise being driven by the MCU.
|
||||
The values of these resistors are not critical - see [this Electronics StackExchange question](https://electronics.stackexchange.com/q/68748) for more information.
|
||||
|
||||

|
||||

|
||||
|
||||
## API {#api}
|
||||
|
||||
|
||||
@@ -35,12 +35,12 @@ layer.
|
||||
|
||||
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
|
||||
|
||||
@@ -55,7 +55,7 @@ Changing the **Hue** cycles around the circle.<br>
|
||||
Changing the **Saturation** moves between the inner and outer sections of the wheel, affecting the intensity of the color.<br>
|
||||
Changing the **Value** sets the overall brightness.<br>
|
||||
|
||||

|
||||

|
||||
|
||||
## Keycodes
|
||||
|
||||
|
||||
@@ -91,11 +91,11 @@ SPLIT_TRANSPORT = custom
|
||||
|
||||
Configuring your layout in a split keyboard works slightly differently to a non-split keyboard. Take for example the following layout. The top left numbers refer to the matrix row and column, and the bottom right are the order of the keys in the layout:
|
||||
|
||||

|
||||

|
||||
|
||||
Since the matrix scanning procedure operates on entire rows, it first populates the left half's rows, then the right half's. Thus, the matrix as QMK views it has double the rows instead of double the columns:
|
||||
|
||||

|
||||

|
||||
|
||||
### Setting Handedness
|
||||
|
||||
@@ -497,7 +497,7 @@ Once you have done that, you will want to solder the diode from the 5V pad to th
|
||||
|
||||
You may need to use the 5V pad from the regulator block above as the pads were too small and placed too closely together to place the Schottky diode properly.
|
||||
|
||||

|
||||

|
||||
|
||||
## Additional Resources
|
||||
|
||||
|
||||
@@ -8,15 +8,15 @@ This guide assumes you're somewhat comfortable with running things at the comman
|
||||
|
||||
Start on the [QMK GitHub page](https://github.com/qmk/qmk_firmware), and you'll see a button in the upper right that says "Fork":
|
||||
|
||||

|
||||

|
||||
|
||||
If you're a part of an organization, you'll need to choose which account to fork it to. In most circumstances, you'll want to fork it to your personal account. Once your fork is completed (sometimes this takes a little while), click the "Clone or Download" button:
|
||||
|
||||

|
||||

|
||||
|
||||
And be sure to select "HTTPS", and select the link and copy it:
|
||||
|
||||

|
||||

|
||||
|
||||
From here, enter `git clone --recurse-submodules ` into the command line, and then paste your link:
|
||||
|
||||
@@ -57,10 +57,10 @@ To https://github.com/whoeveryouare/qmk_firmware.git
|
||||
|
||||
Your changes now exist on your fork on GitHub - if you go back there (`https://github.com/<whoeveryouare>/qmk_firmware`), you can create a "New Pull Request" by clicking this button:
|
||||
|
||||

|
||||

|
||||
|
||||
Here you'll be able to see exactly what you've committed - if it all looks good, you can finalize it by clicking "Create Pull Request":
|
||||
|
||||

|
||||

|
||||
|
||||
After submitting, we may talk to you about your changes, ask that you make changes, and eventually accept it! Thanks for contributing to QMK :)
|
||||
|
||||
@@ -36,12 +36,12 @@ What you want to achieve is one leg from each switch being attached to the corre
|
||||
|
||||
It is fairly simple to plan for an ortholinear keyboard (like a Planck).
|
||||
|
||||

|
||||

|
||||
Image from [RoastPotatoes' "How to hand wire a Planck"](https://blog.roastpotatoes.co/guide/2015/11/04/how-to-handwire-a-planck/)
|
||||
|
||||
But the larger and more complicated your keyboard, the more complex the matrix. [Keyboard Firmware Builder](https://kbfirmware.com/) can help you plan your matrix layout (shown here with a basic fullsize ISO keyboard imported from [Keyboard Layout Editor](https://www.keyboard-layout-editor.com).
|
||||
|
||||

|
||||

|
||||
|
||||
Bear in mind that the number of rows plus the number of columns can not exceed the number of I/O pins on your controller. So the fullsize matrix shown above would be possible on a Proton C or Teensy++, but not on a regular Teensy or Pro Micro.
|
||||
|
||||
@@ -51,14 +51,14 @@ Bear in mind that the number of rows plus the number of columns can not exceed t
|
||||
| :------------ |:-------------:| ------:| ------ |
|
||||
| Pro Micro* | ATmega32u4 | 20 | [link](https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide/hardware-overview-pro-micro#Teensy++_2.0) |
|
||||
| Teensy 2.0 | ATmega32u4 | 25 | [link](https://www.pjrc.com/teensy/pinout.html) |
|
||||
| [QMK Proton C](https://qmk.fm/proton-c/) | STM32F303xC | 36 | [link 1](https://i.imgur.com/RhtrAlc.png), [2](https://deskthority.net/wiki/QMK_Proton_C) |
|
||||
| [QMK Proton C](https://qmk.fm/proton-c/) | STM32F303xC | 36 | [link 1](https://qmk.fm/proton-c-pinout.jpg), [2](https://deskthority.net/wiki/QMK_Proton_C) |
|
||||
| Teensy++ 2.0 | AT90USB1286 | 46 | [link](https://www.pjrc.com/teensy/pinout.html#Teensy_2.0) |
|
||||
|
||||
*Elite C is essentially the same as a Pro Micro with a USB-C instead of Micro-USB
|
||||
|
||||
There are also a number of boards designed specifically for handwiring that mount directly to a small number of switches and offer pinouts for the rest. Though these are generally more expensive and may be more difficult to get hold of.
|
||||
|
||||
<img src="https://i.imgur.com/QiA3ta6.jpg" alt="Postage board mini mounted in place" width="500"/>
|
||||
<img src="/QiA3ta6.jpg" alt="Postage board mini mounted in place" width="500"/>
|
||||
|
||||
| Board | Controller | # I/O |
|
||||
| :------------ |:-------------:| ------:|
|
||||
@@ -74,13 +74,13 @@ Established materials and techniques include:
|
||||
|
||||
| Technique | Examples | Pros | Cons | Image
|
||||
| :-----------| :------- | :------ | :--- | :---
|
||||
| Lengths of wire with stripped segments | [Sasha Solomon's Dactyl](https://medium.com/@sachee/building-my-first-keyboard-and-you-can-too-512c0f8a4c5f) and [Cribbit's modern hand wire](https://geekhack.org/index.php?topic=87689.0) | Neat and tidy | Some effort in stripping the wire | 
|
||||
| Short lengths of wire | [u/xicolinguada's ortho build](https://www.reddit.com/r/MechanicalKeyboards/comments/c39k4f/my_first_hand_wired_keyboard_its_not_perfect_but/) | Easier to strip the wire | More difficult to place | 
|
||||
| Magnet/Enamelled wire | [fknraiden's custom board](https://geekhack.org/index.php?topic=74223.0) | Can be directly soldered onto (insulation burns off with heat) | Appearance? | 
|
||||
| Bending the legs of the diodes for the rows | [Matt3o's Brownfox](https://deskthority.net/viewtopic.php?f=7&t=6050) | Fewer solder joints required | Uninsulated | 
|
||||
| Using rigid wiring (e.g. brass tube) | [u/d_stilgar's invisible hardline](https://www.reddit.com/r/MechanicalKeyboards/comments/8aw5j2/invisible_hardline_keyboard_progress_update_april/) and [u/jonasfasler's first attempt](https://www.reddit.com/r/MechanicalKeyboards/comments/de1jyv/my_first_attempt_at_handwiring_a_keyboard/) | Very pretty | More difficult. No physical insulation | 
|
||||
| Bare wire with insulation added after (e.g. kapton tape) | [Matt3o's 65% on his website](https://matt3o.com/hand-wiring-a-custom-keyboard/) | Easier (no wire stripping required) | Not as attractive | 
|
||||
| Copper tape | [ManuForm Dactyl](https://github.com/tshort/dactyl-keyboard) | Very easy | Only really works when your plate/case aligns with the bottom of your switches | 
|
||||
| Lengths of wire with stripped segments | [Sasha Solomon's Dactyl](https://medium.com/@sachee/building-my-first-keyboard-and-you-can-too-512c0f8a4c5f) and [Cribbit's modern hand wire](https://geekhack.org/index.php?topic=87689.0) | Neat and tidy | Some effort in stripping the wire | 
|
||||
| Short lengths of wire | [u/xicolinguada's ortho build](https://www.reddit.com/r/MechanicalKeyboards/comments/c39k4f/my_first_hand_wired_keyboard_its_not_perfect_but/) | Easier to strip the wire | More difficult to place | 
|
||||
| Magnet/Enamelled wire | [fknraiden's custom board](https://geekhack.org/index.php?topic=74223.0) | Can be directly soldered onto (insulation burns off with heat) | Appearance? | 
|
||||
| Bending the legs of the diodes for the rows | [Matt3o's Brownfox](https://deskthority.net/viewtopic.php?f=7&t=6050) | Fewer solder joints required | Uninsulated | 
|
||||
| Using rigid wiring (e.g. brass tube) | [u/d_stilgar's invisible hardline](https://www.reddit.com/r/MechanicalKeyboards/comments/8aw5j2/invisible_hardline_keyboard_progress_update_april/) and [u/jonasfasler's first attempt](https://www.reddit.com/r/MechanicalKeyboards/comments/de1jyv/my_first_attempt_at_handwiring_a_keyboard/) | Very pretty | More difficult. No physical insulation | 
|
||||
| Bare wire with insulation added after (e.g. kapton tape) | [Matt3o's 65% on his website](https://matt3o.com/hand-wiring-a-custom-keyboard/) | Easier (no wire stripping required) | Not as attractive | 
|
||||
| Copper tape | [ManuForm Dactyl](https://github.com/tshort/dactyl-keyboard) | Very easy | Only really works when your plate/case aligns with the bottom of your switches | 
|
||||
|
||||
|
||||
Note that these methods can be combined. Prepare your lengths of wire before moving on to soldering.
|
||||
@@ -97,11 +97,11 @@ There are a lot of soldering guides and tips available elsewhere but here are so
|
||||
|
||||
To ensure a strong solder joint you want a good amount of contact between the solder and the two pieces of metal you are connecting. A good way of doing this (though not required) is looping around pins or twisting wires together before applying solder.
|
||||
|
||||
<img src="https://i.imgur.com/eHJjmnU.jpg" alt="Looped around rod" width="200"/> <img src="https://i.imgur.com/8nbxmmr.jpg?1" alt="Looped diode leg" width="200"/>
|
||||
<img src="/eHJjmnU.jpg" alt="Looped around rod" width="400"/>
|
||||
|
||||
If your diodes are on a packaging strip and need a bend in them (either the start of a loop or for connecting to its neighbour) this can easily done by bending it over something straight like the edge of a box, table, or ruler. This also helps keep track of the direction of the diode as all the bends will be on the same side.
|
||||
|
||||
<img src="https://i.imgur.com/oITudbX.jpg" alt="Bent diode legs" width="200"/>
|
||||
<img src="/oITudbX.jpg" alt="Bent diode legs" width="400"/>
|
||||
|
||||
If your iron has temperature control, set it to 315ºC (600ºF).
|
||||
|
||||
@@ -164,7 +164,7 @@ Cut wires to the length of the distance from the a point on each column/row to t
|
||||
|
||||
Ribbon cable can be used to keep this extra tidy. You may also want to consider routing the wires beneath the existing columns/rows.
|
||||
|
||||
<img src="https://i.imgur.com/z2QlKfB.jpg" alt="Ribbon Cable" width="350"/>
|
||||
<img src="/z2QlKfB.jpg" alt="Ribbon Cable" width="600"/>
|
||||
|
||||
As you solder the wires to the controller make a note of which row/column is going to which pin on the controller as we'll use this data to setup the matrix when we create the firmware.
|
||||
|
||||
|
||||
@@ -203,8 +203,8 @@ See also: [Basic Keycodes](keycodes_basic)
|
||||
|`KC_WWW_STOP` |`KC_WSTP` |Browser Stop |✔ | |✔ |
|
||||
|`KC_WWW_REFRESH` |`KC_WREF` |Browser Refresh |✔ | |✔ |
|
||||
|`KC_WWW_FAVORITES` |`KC_WFAV` |Browser Favorites |✔ | |✔ |
|
||||
|`KC_MEDIA_FAST_FORWARD` |`KC_MFFD` |Next Track |✔ |✔<sup>5</sup>|✔ |
|
||||
|`KC_MEDIA_REWIND` |`KC_MRWD` |Previous Track |✔<sup>6</sup>|✔<sup>5</sup>|✔ |
|
||||
|`KC_MEDIA_FAST_FORWARD` |`KC_MFFD` |Fast Forward |✔ |✔<sup>5</sup>|✔ |
|
||||
|`KC_MEDIA_REWIND` |`KC_MRWD` |Rewind |✔<sup>6</sup>|✔<sup>5</sup>|✔ |
|
||||
|`KC_BRIGHTNESS_UP` |`KC_BRIU` |Brightness Up |✔ |✔ |✔ |
|
||||
|`KC_BRIGHTNESS_DOWN` |`KC_BRID` |Brightness Down |✔ |✔ |✔ |
|
||||
|`KC_CONTROL_PANEL` |`KC_CPNL` |Open Control Panel |✔ | | |
|
||||
|
||||
@@ -219,8 +219,8 @@ Some of these keycodes may behave differently depending on the OS. For example,
|
||||
|`KC_WWW_STOP` |`KC_WSTP`|Browser Stop |
|
||||
|`KC_WWW_REFRESH` |`KC_WREF`|Browser Refresh |
|
||||
|`KC_WWW_FAVORITES` |`KC_WFAV`|Browser Favorites |
|
||||
|`KC_MEDIA_FAST_FORWARD`|`KC_MFFD`|Next Track |
|
||||
|`KC_MEDIA_REWIND` |`KC_MRWD`|Previous Track |
|
||||
|`KC_MEDIA_FAST_FORWARD`|`KC_MFFD`|Fast Forward |
|
||||
|`KC_MEDIA_REWIND` |`KC_MRWD`|Rewind |
|
||||
|`KC_BRIGHTNESS_UP` |`KC_BRIU`|Brightness Up |
|
||||
|`KC_BRIGHTNESS_DOWN` |`KC_BRID`|Brightness Down |
|
||||
|`KC_CONTROL_PANEL` |`KC_CPNL`|Open Control Panel |
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# QMK Configurator
|
||||
|
||||
[](https://config.qmk.fm/)
|
||||
[](https://config.qmk.fm/)
|
||||
|
||||
The [QMK Configurator](https://config.qmk.fm) is an online graphical user interface that generates QMK Firmware `.hex` or `.bin` files.
|
||||
|
||||
|
||||
@@ -32,11 +32,11 @@ Building locally has a much shorter turnaround time than waiting for GitHub Acti
|
||||
|
||||
A basic skeleton External Userspace repository can be found [here](https://github.com/qmk/qmk_userspace). If you wish to keep your keymaps on GitHub (strongly recommended!), you can fork the repository and use it as a base:
|
||||
|
||||

|
||||

|
||||
|
||||
Going ahead with your fork will copy it to your account, at which point you can clone it to your local machine and begin adding your keymaps:
|
||||
|
||||

|
||||

|
||||
|
||||
```sh
|
||||
cd $HOME
|
||||
@@ -99,8 +99,8 @@ All firmware builds you've added to the External Userspace build targets will be
|
||||
|
||||
GitHub Actions can be used to automatically build your keymaps whenever you push changes to your External Userspace repository. If you have set up your list of build targets, this is as simple as enabling workflows in the GitHub repository settings:
|
||||
|
||||

|
||||

|
||||
|
||||
Any push will result in compilation of all configured builds, and once completed a new release containing the newly-minted firmware files will be created on GitHub, which you can subsequently download and flash to your keyboard:
|
||||
|
||||

|
||||

|
||||
|
||||
@@ -66,7 +66,7 @@ Once both plugins are installed, restart Eclipse as prompted.
|
||||
* Select the _AVR-GCC Toolchain_;
|
||||
* Keep the rest as-is and click <kbd>Finish</kbd>
|
||||
|
||||

|
||||

|
||||
|
||||
3. The project will now be loaded and indexed. Its files can be browsed easily through the _Project Explorer_ on the left.
|
||||
|
||||
|
||||
@@ -174,7 +174,7 @@ You'll need to perform some modifications to the file above in order to target y
|
||||
* `"armToolchainPath"`: _[Optional]_ The path to the ARM toolchain installation location on Windows -- under normal circumstances Linux/macOS will auto-detect this correctly and will not need to be specified.
|
||||
|
||||
::: warning
|
||||
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: 
|
||||
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: 
|
||||
:::
|
||||
|
||||
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:
|
||||
|
||||
@@ -7,7 +7,7 @@ The WeAct Blackpill is a popular choice for handwired boards, as it offers a pow
|
||||
* [WeAct GitHub for F4x1 Blackpill](https://github.com/WeActStudio/WeActStudio.MiniSTM32F4x1)
|
||||
* Unfortunately, due to supply issues official WeAct F411 based blackpills may not be available.
|
||||
|
||||

|
||||

|
||||
|
||||
|
||||
## Pin Usage Limitations
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
The Proton C is an Arm STM32F303xC based drop-in replacement for the Pro Micro.
|
||||
|
||||
<img src="https://i.imgur.com/GdsN1Rdh.jpg" alt="Proton C" />
|
||||
<img src="https://qmk.fm/proton-c.jpg" alt="Proton C" width="800"/>
|
||||
|
||||
#### Features
|
||||
|
||||
|
||||
@@ -17,8 +17,8 @@ The following table shows the current driver status for peripherals on RP2040 MC
|
||||
|
||||
## GPIO
|
||||
|
||||
<img alt="Raspberry Pi Pico pinout" src="https://i.imgur.com/nLaiYDE.jpg" width="48%"/>
|
||||
<img alt="Sparkfun RP2040 Pro Micro pinout" src="https://i.imgur.com/1TPAhrs.jpg" width="48%"/>
|
||||
<img alt="Raspberry Pi Pico pinout" src="/nLaiYDE.jpg" width="48%"/>
|
||||
<img alt="Sparkfun RP2040 Pro Micro pinout" src="/1TPAhrs.jpg" width="48%"/>
|
||||
|
||||
::: warning
|
||||
The GPIO pins of the RP2040 are not 5V tolerant!
|
||||
|
||||
@@ -164,7 +164,7 @@ There are a lot of features that can be turned on or off, configured or tuned. S
|
||||
|
||||
### Configuration Options
|
||||
|
||||
For available options for `config.h`, you should see the [Config Options](config_options#the-configh-file) page for more details.
|
||||
For available options for `config.h`, you should see the [Config Options](config_options#the-config-h-file) page for more details.
|
||||
|
||||
### Build Options
|
||||
|
||||
|
||||
BIN
docs/public/0GNIYY0.jpg
Normal file
|
After Width: | Height: | Size: 95 KiB |
BIN
docs/public/1TPAhrs.jpg
Normal file
|
After Width: | Height: | Size: 115 KiB |
BIN
docs/public/2wUZNWk.png
Normal file
|
After Width: | Height: | Size: 7.6 KiB |
BIN
docs/public/3RrSjzW.png
Normal file
|
After Width: | Height: | Size: 10 KiB |
BIN
docs/public/4wjJzBU.png
Normal file
|
After Width: | Height: | Size: 4.0 KiB |
BIN
docs/public/5wsh5wM.png
Normal file
|
After Width: | Height: | Size: 46 KiB |
BIN
docs/public/8Toomz4.jpg
Normal file
|
After Width: | Height: | Size: 27 KiB |
BIN
docs/public/AvXZShD.jpg
Normal file
|
After Width: | Height: | Size: 92 KiB |
BIN
docs/public/BPEC5n5.jpg
Normal file
|
After Width: | Height: | Size: 38 KiB |
BIN
docs/public/BmAvoUC.png
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
docs/public/Bu4mk9m.png
Normal file
|
After Width: | Height: | Size: 3.4 KiB |
BIN
docs/public/CWYmsk8.png
Normal file
|
After Width: | Height: | Size: 31 KiB |
BIN
docs/public/CnASmPo.jpg
Normal file
|
After Width: | Height: | Size: 282 KiB |
BIN
docs/public/DkEhj9x.png
Normal file
|
After Width: | Height: | Size: 8.8 KiB |
BIN
docs/public/DxMHpJ8.jpg
Normal file
|
After Width: | Height: | Size: 32 KiB |
BIN
docs/public/EGrPM1L.png
Normal file
|
After Width: | Height: | Size: 28 KiB |
BIN
docs/public/EVkxOt1.png
Normal file
|
After Width: | Height: | Size: 64 KiB |
BIN
docs/public/FRShcLD.png
Normal file
|
After Width: | Height: | Size: 41 KiB |
BIN
docs/public/HL5DP8H.png
Normal file
|
After Width: | Height: | Size: 11 KiB |
BIN
docs/public/Hx0E5kC.png
Normal file
|
After Width: | Height: | Size: 9.6 KiB |
BIN
docs/public/JKngtTw.png
Normal file
|
After Width: | Height: | Size: 5.6 KiB |
BIN
docs/public/JcDhZll.png
Normal file
|
After Width: | Height: | Size: 13 KiB |
BIN
docs/public/N1NYcSz.jpg
Normal file
|
After Width: | Height: | Size: 32 KiB |
BIN
docs/public/Ojydlaj.jpg
Normal file
|
After Width: | Height: | Size: 40 KiB |
BIN
docs/public/QeY6kMQ.png
Normal file
|
After Width: | Height: | Size: 3.5 KiB |
BIN
docs/public/QiA3ta6.jpg
Normal file
|
After Width: | Height: | Size: 160 KiB |
BIN
docs/public/RFyNMlL.jpg
Normal file
|
After Width: | Height: | Size: 163 KiB |
BIN
docs/public/UlJ4ZDP.png
Normal file
|
After Width: | Height: | Size: 26 KiB |
BIN
docs/public/aEs2RuA.png
Normal file
|
After Width: | Height: | Size: 3.7 KiB |
BIN
docs/public/aTnG8TV.jpg
Normal file
|
After Width: | Height: | Size: 46 KiB |
BIN
docs/public/anw9cOL.png
Normal file
|
After Width: | Height: | Size: 80 KiB |
BIN
docs/public/b4b7KDb.jpg
Normal file
|
After Width: | Height: | Size: 281 KiB |
BIN
docs/public/b8VgXzx.png
Normal file
|
After Width: | Height: | Size: 9.4 KiB |
BIN
docs/public/eGO0ohO.jpg
Normal file
|
After Width: | Height: | Size: 12 KiB |
BIN
docs/public/eHJjmnU.jpg
Normal file
|
After Width: | Height: | Size: 120 KiB |
BIN
docs/public/fmDvDzR.png
Normal file
|
After Width: | Height: | Size: 12 KiB |
BIN
docs/public/hcegguh.png
Normal file
|
After Width: | Height: | Size: 19 KiB |
BIN
docs/public/mBe5vkL.jpg
Normal file
|
After Width: | Height: | Size: 76 KiB |
BIN
docs/public/nCgeolTh.png
Normal file
|
After Width: | Height: | Size: 197 KiB |
BIN
docs/public/nLaiYDE.jpg
Normal file
|
After Width: | Height: | Size: 217 KiB |
BIN
docs/public/o7WLvBl.png
Normal file
|
After Width: | Height: | Size: 3.4 KiB |
BIN
docs/public/oHYR1yW.png
Normal file
|
After Width: | Height: | Size: 18 KiB |
BIN
docs/public/oITudbX.jpg
Normal file
|
After Width: | Height: | Size: 434 KiB |
BIN
docs/public/vkYVo66.jpg
Normal file
|
After Width: | Height: | Size: 43 KiB |
BIN
docs/public/z2QlKfB.jpg
Normal file
|
After Width: | Height: | Size: 255 KiB |
BIN
docs/public/zmwOL5P.png
Normal file
|
After Width: | Height: | Size: 34 KiB |
@@ -189,15 +189,25 @@ Currently, the Configurator does not support key rotation or non-rectangular key
|
||||
|
||||
For ISO Enter keys, QMK custom is to display it as a rectangular key, 1.25u wide and 2u high, aligned so its right edge is aligned with the right edge of the alphanumeric key block.
|
||||
|
||||

|
||||

|
||||
*A 60% keyboard in standard ISO layout, as rendered by QMK Configurator.*
|
||||
|
||||
#### Vertically-offset keys
|
||||
|
||||
For vertically-offset keys, place them in KLE as if they were not offset, then edit the Y-values as needed in the converted JSON file
|
||||
|
||||

|
||||

|
||||
*An 1800-layout keyboard as rendered in Keyboard Layout Editor, without the vertical offset applied to the arrow keys.*
|
||||
|
||||

|
||||
*A Unix diff file, showing the changes needed to vertically-offset the arrow keys in our keyboard's JSON file.*
|
||||
```diff
|
||||
-{"label": "\u2191", "x", 14.25, "y": 5},
|
||||
+{"label": "\u2191", "x", 14.25, "y": 5.25},
|
||||
...
|
||||
-{"label": "\u2190", "x", 13.25, "y": 6},
|
||||
-{"label": "\u2193", "x", 14.25, "y": 6},
|
||||
-{"label": "\u2192", "x", 15.25, "y": 6},
|
||||
+{"label": "\u2190", "x", 13.25, "y": 6.25},
|
||||
+{"label": "\u2193", "x", 14.25, "y": 6.25},
|
||||
+{"label": "\u2192", "x", 15.25, "y": 6.25},
|
||||
```
|
||||
*A diff showing the changes needed to vertically-offset the arrow keys in our keyboard's JSON file.*
|
||||
|
||||
110
docs/tap_hold.md
@@ -1,15 +1,15 @@
|
||||
# Tap-Hold Configuration Options
|
||||
|
||||
While Tap-Hold options are fantastic, they are not without their issues. We have tried to configure them with reasonable defaults, but that may still cause issues for some people.
|
||||
While Tap-Hold options are fantastic, they are not without their issues. We have tried to configure them with reasonable defaults, but that may still cause issues for some people.
|
||||
|
||||
These options let you modify the behavior of the Tap-Hold keys.
|
||||
These options let you modify the behavior of the tap-hold keys.
|
||||
|
||||
## Tapping Term
|
||||
|
||||
The crux of all of the following features is the tapping term setting. This determines what is a tap and what is a hold. The exact timing for this to feel natural can vary from keyboard to keyboard, from switch to switch, and from key to key.
|
||||
The crux of all of the following features is the tapping term setting. This determines what is a tap and what is a hold. The exact timing for this to feel natural can vary from keyboard to keyboard, from switch to switch, and from key to key.
|
||||
|
||||
::: tip
|
||||
`DYNAMIC_TAPPING_TERM_ENABLE` enables three special keys that can help you quickly find a comfortable tapping term for you. See "Dynamic Tapping Term" for more details.
|
||||
`DYNAMIC_TAPPING_TERM_ENABLE` enables three special keys that can help you quickly find a comfortable tapping term for you. See [Dynamic Tapping Term](#dynamic-tapping-term) for more details.
|
||||
:::
|
||||
|
||||
You can set the global time for this by adding the following setting to your `config.h`:
|
||||
@@ -18,14 +18,14 @@ You can set the global time for this by adding the following setting to your `co
|
||||
#define TAPPING_TERM 200
|
||||
```
|
||||
|
||||
This setting is defined in milliseconds and defaults to 200ms. This is a good average for the majority of people.
|
||||
This setting is defined in milliseconds and defaults to 200ms. This is a good average for the majority of people.
|
||||
|
||||
For more granular control of this feature, you can add the following to your `config.h`:
|
||||
```c
|
||||
#define TAPPING_TERM_PER_KEY
|
||||
```
|
||||
|
||||
You can then add the following function to your keymap:
|
||||
You can then add the following function to your `keymap.c` to customise the tapping term for each key:
|
||||
|
||||
```c
|
||||
uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) {
|
||||
@@ -40,9 +40,41 @@ uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) {
|
||||
}
|
||||
```
|
||||
|
||||
### Example
|
||||
|
||||
You can compare keycodes to `QK_MOD_TAP`/`QK_MOD_TAP_MAX` and `QK_LAYER_TAP`/`QK_LAYER_TAP_MAX` to filter out Mod-Tap/Layer-Tap keys, rather than checking such keys manually in a switch-case. For instance, this example sets all Mod-Tap keys to have a higher tapping term, while leaving all other tap-hold keys unchanged:
|
||||
|
||||
```c
|
||||
uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) {
|
||||
switch (keycode) {
|
||||
case QK_MOD_TAP ... QK_MOD_TAP_MAX:
|
||||
return TAPPING_TERM + 100;
|
||||
default:
|
||||
return TAPPING_TERM;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
You can also use functions like `QK_MOD_TAP_GET_MODS`, `QK_LAYER_MOD_GET_MODS`, and `QK_ONE_SHOT_MOD_GET_MODS` to filter Mod-Tap/Layer-Mod/One Shot keys by their mods.
|
||||
|
||||
For instance, this example sets a higher tapping term for `AltGr` Mod-Taps and lower tapping terms for `Shift` Mod-Taps:
|
||||
|
||||
```c
|
||||
uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) {
|
||||
uint8_t mod = mod_config(QK_MOD_TAP_GET_MODS(keycode));
|
||||
if (mod & MOD_LSFT != 0 || mod & MOD_RSFT != 0) {
|
||||
return 100;
|
||||
}
|
||||
if (mod & MOD_RALT != 0) {
|
||||
return TAPPING_TERM + 50;
|
||||
}
|
||||
return TAPPING_TERM;
|
||||
}
|
||||
```
|
||||
|
||||
### Dynamic Tapping Term {#dynamic-tapping-term}
|
||||
|
||||
`DYNAMIC_TAPPING_TERM_ENABLE` is a feature you can enable in `rules.mk` that lets you use three special keys in your keymap to configure the tapping term on the fly.
|
||||
`DYNAMIC_TAPPING_TERM_ENABLE` is a feature you can enable in `rules.mk` that lets you use three special keys in your keymap to configure the tapping term on the fly:
|
||||
|
||||
| Key | Aliases | Description |
|
||||
|-------------------------------|---------|-------------------------------------------------------------------------------------------|
|
||||
@@ -52,13 +84,13 @@ uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) {
|
||||
|
||||
Set the tapping term as usual with `#define TAPPING_TERM <value>` in `config.h` and add `DYNAMIC_TAPPING_TERM_ENABLE = yes` in `rules.mk`. Then, place the above three keys somewhere in your keymap and flash the new firmware onto your board.
|
||||
|
||||
Now, you can try using your dual-role keys, such as layer-taps and mod-taps, and use `DT_DOWN` and `DT_UP` to adjust the tapping term immediately. If you find that you frequently trigger the modifier of your mod-tap(s) by accident, for example, that's a sign that your tapping term may be too low so tap `DT_UP` a few times to increase the tapping term until that no longer happens. On the flip side, if you get superfluous characters when you actually intended to momentarily activate a layer, tap `DT_DOWN` to lower the tapping term. Do note that these keys affect the *global* tapping term, you cannot change the tapping term of a specific key on the fly.
|
||||
Now, you can try using your dual-role keys such as Layer-Taps and Mod-Taps and use `DT_DOWN` and `DT_UP` to adjust the tapping term immediately. If you find that you frequently trigger the modifier of your Mod-Tap(s) by accident, for example, that's a sign that your tapping term may be too low, so tap `DT_UP` a few times to increase the tapping term until that no longer happens. Conversely, if you get superfluous characters when you actually intended to momentarily activate a layer, tap `DT_DOWN` to lower the tapping term. Do note that these keys affect the *global* tapping term, you cannot change the tapping term of a specific key on the fly.
|
||||
|
||||
Once you're satisfied with the current tapping term value, open `config.h` and replace whatever value you first wrote for the tapping term by the output of the `DT_PRNT` key.
|
||||
Once you're satisfied with the current tapping term value, you can tap the `DT_PRNT` key to see your new tapping term, and you can replace the tapping term in `config.h` with this new value.
|
||||
|
||||
It's important to update `TAPPING_TERM` with the new value because the adjustments made using `DT_UP` and `DT_DOWN` are not persistent.
|
||||
It's important to update `TAPPING_TERM` with the new value because the adjustments made using `DT_UP` and `DT_DOWN` are *not* persistent.
|
||||
|
||||
The value by which the tapping term increases or decreases when you tap `DT_UP` and `DT_DOWN` can be configured in `config.h` with `#define DYNAMIC_TAPPING_TERM_INCREMENT <new value>`. Note that the tapping term is *not* modified when holding down the tap term keys so if you need to, for example, decrease the current tapping term by 50ms, you cannot just press down and hold `DT_DOWN`; you will have to tap it 10 times in a row with the default increment of 5ms.
|
||||
The value by which the tapping term increases or decreases when you tap `DT_UP` and `DT_DOWN` can be configured in `config.h` with `#define DYNAMIC_TAPPING_TERM_INCREMENT <new value>`. Note that the tapping term is *not* modified when *holding* down the tap term keys, so if you need to, for example, decrease the current tapping term by 50ms, you cannot just press down and hold `DT_DOWN`; you will have to tap it 10 times in a row with the default increment of 5ms.
|
||||
|
||||
If you need more flexibility, nothing prevents you from defining your own custom keys to dynamically change the tapping term.
|
||||
|
||||
@@ -97,7 +129,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
|
||||
};
|
||||
```
|
||||
|
||||
In order for this feature to be effective if you use per-key tapping terms, you need to make a few changes to the syntax of the `get_tapping_term` function. All you need to do is replace every occurrence of `TAPPING_TERM` in the `get_tapping_term` function by lowercase `g_tapping_term`. If you don't do that, you will still see the value typed by `DT_PRNT` go up and down as you configure the tapping term on the fly but you won't feel those changes as they don't get applied. If you can go as low as 10ms and still easily trigger the tap function of a dual-role key, that's a sign that you forgot to make the necessary changes to your `get_tapping_term` function.
|
||||
In order for this feature to be effective, if you use per-key tapping terms, then you need to make a few changes to the syntax of the `get_tapping_term` function. All you need to do is replace every occurrence of `TAPPING_TERM` in the `get_tapping_term` function by lowercase `g_tapping_term`. If you don't do this, you will still see the value typed by `DT_PRNT` go up and down as you configure the tapping term on the fly, but you won't feel those changes as they don't get applied. If you can go as low as 10ms and still easily trigger the tap function of a dual-role key, that's a sign that you forgot to make the necessary changes to your `get_tapping_term` function.
|
||||
|
||||
For instance, here's how the example `get_tapping_term` shown earlier should look after the transformation:
|
||||
|
||||
@@ -114,23 +146,23 @@ uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) {
|
||||
}
|
||||
```
|
||||
|
||||
The reason is that `TAPPING_TERM` is a macro that expands to a constant integer and thus cannot be changed at runtime whereas `g_tapping_term` is a variable whose value can be changed at runtime. If you want, you can temporarily enable `DYNAMIC_TAPPING_TERM_ENABLE` to find a suitable tapping term value and then disable that feature and revert back to using the classic syntax for per-key tapping term settings. In case you need to access the tapping term from elsewhere in your code, you can use the `GET_TAPPING_TERM(keycode, record)` macro. This macro will expand to whatever is the appropriate access pattern given the current configuration.
|
||||
The reason is that `TAPPING_TERM` is a macro that expands to a constant integer and thus cannot be changed at runtime, whereas `g_tapping_term` is a variable whose value can be changed at runtime. If you want, you can temporarily enable `DYNAMIC_TAPPING_TERM_ENABLE` to find a suitable tapping term value and then disable that feature and revert back to using the classic syntax for per-key tapping term settings. In case you need to access the tapping term from elsewhere in your code, you can use the `GET_TAPPING_TERM(keycode, record)` macro. This macro will expand to whatever is the appropriate access pattern given the current configuration.
|
||||
|
||||
## Tap-Or-Hold Decision Modes
|
||||
|
||||
The code which decides between the tap and hold actions of dual-role keys supports three different modes, in increasing order of preference for the hold action:
|
||||
|
||||
1. The default mode selects the hold action only if the dual-role key is held down longer than the tapping term. In this mode pressing other keys while the dual-role key is held down does not influence the tap-or-hold decision. In other words, this mode ignores interrupts.
|
||||
1. The default mode selects the hold action only if the dual-role key is held down longer than the tapping term. In this mode, pressing other keys while the dual-role key is held down does not influence the tap-or-hold decision. In other words, this mode ignores interrupts.
|
||||
|
||||
2. The “permissive hold” mode, in addition to the default behavior, immediately selects the hold action when another key is tapped (pressed and then released) while the dual-role key is held down, even if this happens earlier than the tapping term. If another key is just pressed, but then the dual-role key is released before that other key (and earlier than the tapping term), this mode will still select the tap action.
|
||||
2. The "permissive hold" mode, in addition to the default behavior, immediately selects the hold action when another key is tapped (pressed and then released) while the dual-role key is held down, even if this happens earlier than the tapping term. If another key is just pressed, but then the dual-role key is released before that other key (and earlier than the tapping term), this mode will still select the tap action. That is, this mode converts "nested" sequences, but not "rolls".
|
||||
|
||||
3. The “hold on other key press” mode, in addition to the default behavior, immediately selects the hold action when another key is pressed while the dual-role key is held down, even if this happens earlier than the tapping term.
|
||||
3. The "hold on other key press" mode, in addition to the default behavior, immediately selects the hold action when another key is pressed while the dual-role key is held down, even if this happens earlier than the tapping term.
|
||||
|
||||
Note that until the tap-or-hold decision completes (which happens when either the dual-role key is released, or the tapping term has expired, or the extra condition for the selected decision mode is satisfied), key events are delayed and not transmitted to the host immediately. The default mode gives the most delay (if the dual-role key is held down, this mode always waits for the whole tapping term), and the other modes may give less delay when other keys are pressed, because the hold action may be selected earlier.
|
||||
|
||||
### Comparison {#comparison}
|
||||
|
||||
To better illustrate the tap-or-hold decision modes, let us compare the expected output of each decision mode in a handful of tapping scenarios involving a mod-tap key (`LSFT_T(KC_A)`) and a regular key (`KC_B`) with the `TAPPING_TERM` set to 200ms.
|
||||
To better illustrate the tap-or-hold decision modes, let us compare the expected output of each decision mode in a handful of tapping scenarios involving a Mod-Tap key (`LSFT_T(KC_A)`) and a regular key (`KC_B`) with the `TAPPING_TERM` set to 200ms.
|
||||
|
||||
Note: "`kc` held" in the "Physical key event" column means that the key wasn't physically released yet at this point in time.
|
||||
|
||||
@@ -228,7 +260,7 @@ The above sequence will not send `KC_RGHT` but `KC_A` `KC_L` instead, since `LT(
|
||||
|
||||
---
|
||||
|
||||
Example sequence 3 (Mod Tap):
|
||||
Example sequence 3 (Mod-Tap):
|
||||
|
||||
```
|
||||
TAPPING_TERM
|
||||
@@ -246,17 +278,17 @@ followed by any key event that happened after the initial press of `SFT_T(KC_A)`
|
||||
|
||||
### Permissive Hold
|
||||
|
||||
The “permissive hold” mode can be enabled for all dual-role keys by adding the corresponding option to `config.h`:
|
||||
The "permissive hold" mode can be enabled for all dual-role keys by adding the corresponding option to `config.h`:
|
||||
|
||||
```c
|
||||
#define PERMISSIVE_HOLD
|
||||
```
|
||||
|
||||
This makes tap and hold keys (like Layer Tap) work better for fast typists, or for high `TAPPING_TERM` settings.
|
||||
This makes tap and hold keys (like Layer-Tap) work better for fast typists, or for high `TAPPING_TERM` settings.
|
||||
|
||||
If you press a dual-role key, tap another key (press and release) and then release the dual-role key, all within the tapping term, by default the dual-role key will perform its tap action. If the `PERMISSIVE_HOLD` option is enabled, the dual-role key will perform its hold action instead.
|
||||
If you press a dual-role key, tap another key (press and release) and then release the dual-role key, all within the tapping term, by default the dual-role key will perform its tap action. If the `PERMISSIVE_HOLD` option is enabled, the dual-role key will perform its hold action instead.
|
||||
|
||||
An example of a sequence that is affected by the “permissive hold” mode:
|
||||
An example of a sequence that is affected by the "permissive hold" mode:
|
||||
|
||||
- `LT(2, KC_A)` Down
|
||||
- `KC_L` Down (the `L` key is also mapped to `KC_RGHT` on layer 2)
|
||||
@@ -275,9 +307,9 @@ An example of a sequence that is affected by the “permissive hold” mode:
|
||||
+---------------------------|--------+
|
||||
```
|
||||
|
||||
Normally, if you do all this within the `TAPPING_TERM` (default: 200ms), this will be registered as `al` by the firmware and host system. With the `PERMISSIVE_HOLD` option enabled, the Layer Tap key is considered as a layer switch if another key is tapped, and the above sequence would be registered as `KC_RGHT` (the mapping of `L` on layer 2). We could describe this sequence as a “nested tap” (the modified key's key down and key up events are “nested” between the dual-role key's key down and key up events).
|
||||
Normally, if you do all this within the `TAPPING_TERM` (default: 200ms), this will be registered as `al` by the firmware and host system. With the `PERMISSIVE_HOLD` option enabled, the Layer-Tap key is considered as a layer switch if another key is tapped, and the above sequence would be registered as `KC_RGHT` (the mapping of `L` on layer 2). We could describe this sequence as a "nested tap" (the modified key's key down and key up events are "nested" between the dual-role key's key down and key up events).
|
||||
|
||||
However, this slightly different sequence will not be affected by the “permissive hold” mode:
|
||||
However, this slightly different sequence will not be affected by the "permissive hold" mode:
|
||||
|
||||
- `LT(2, KC_A)` Down
|
||||
- `KC_L` Down (the `L` key is also mapped to `KC_RGHT` on layer 2)
|
||||
@@ -296,10 +328,10 @@ However, this slightly different sequence will not be affected by the “permiss
|
||||
+---------------------------|--------+
|
||||
```
|
||||
|
||||
In the sequence above the dual-role key is released before the other key is released, and if that happens within the tapping term, the “permissive hold” mode will still choose the tap action for the dual-role key, and the sequence will be registered as `al` by the host. We could describe this as a “rolling press” (the two keys' key down and key up events behave as if you were rolling a ball across the two keys, first pressing each key down in sequence and then releasing them in the same order).
|
||||
In the sequence above the dual-role key is released before the other key is released, and if that happens within the tapping term, the "permissive hold" mode will still choose the tap action for the dual-role key, and the sequence will be registered as `al` by the host. We could describe this as a "rolling press" (the two keys' key down and key up events behave as if you were rolling a ball across the two keys, first pressing each key down in sequence and then releasing them in the same order).
|
||||
|
||||
::: tip
|
||||
The `PERMISSIVE_HOLD` option is not noticeable if you also enable `HOLD_ON_OTHER_KEY_PRESS` because the latter option considers both the “nested tap” and “rolling press” sequences like shown above as a hold action, not the tap action. `HOLD_ON_OTHER_KEY_PRESS` makes the Tap-Or-Hold decision earlier in the chain of key events, thus taking a precedence over `PERMISSIVE_HOLD`.
|
||||
The `PERMISSIVE_HOLD` option is not noticeable if you also enable `HOLD_ON_OTHER_KEY_PRESS` because the latter option considers both the "nested tap" and "rolling press" sequences like shown above as a hold action, not the tap action. `HOLD_ON_OTHER_KEY_PRESS` makes the tap-or-hold decision earlier in the chain of key events, thus taking a precedence over `PERMISSIVE_HOLD`.
|
||||
:::
|
||||
|
||||
For more granular control of this feature, you can add the following to your `config.h`:
|
||||
@@ -323,19 +355,21 @@ bool get_permissive_hold(uint16_t keycode, keyrecord_t *record) {
|
||||
}
|
||||
```
|
||||
|
||||
As in the earlier example, you can filter Mod-Tap/Layer-Mod/One Shot keys by their mods rather than checking such keys manually in a switch-case. (Also applicable to the other following `PER_KEY` functions.)
|
||||
|
||||
### Hold On Other Key Press
|
||||
|
||||
The “hold on other key press” mode can be enabled for all dual-role keys by adding the corresponding option to `config.h`:
|
||||
The "hold on other key press" mode can be enabled for all dual-role keys by adding the corresponding option to `config.h`:
|
||||
|
||||
```c
|
||||
#define HOLD_ON_OTHER_KEY_PRESS
|
||||
```
|
||||
|
||||
This mode makes tap and hold keys (like Layer Tap) work better for fast typists, or for high `TAPPING_TERM` settings. Compared to the “permissive hold” mode, this mode selects the hold action in more cases.
|
||||
This mode makes tap and hold keys (like Layer-Tap) work better for fast typists, or for high `TAPPING_TERM` settings. Compared to the "permissive hold" mode, this mode selects the hold action in more cases.
|
||||
|
||||
If you press a dual-role key, press another key, and then release the dual-role key, all within the tapping term, by default the dual-role key will perform its tap action. If the `HOLD_ON_OTHER_KEY_PRESS` option is enabled, the dual-role key will perform its hold action instead.
|
||||
If you press a dual-role key, press another key, and then release the dual-role key, all within the tapping term, by default the dual-role key will perform its tap action. If the `HOLD_ON_OTHER_KEY_PRESS` option is enabled, the dual-role key will perform its hold action instead.
|
||||
|
||||
An example of a sequence that is affected by the “hold on other key press” mode, but not by the “permissive hold” mode:
|
||||
An example of a sequence that is affected by the "hold on other key press" mode, but not by the "permissive hold" mode:
|
||||
|
||||
- `LT(2, KC_A)` Down
|
||||
- `KC_L` Down (the `L` key is also mapped to `KC_RGHT` on layer 2)
|
||||
@@ -354,7 +388,7 @@ An example of a sequence that is affected by the “hold on other key press” m
|
||||
+---------------------------|--------+
|
||||
```
|
||||
|
||||
Normally, if you do all this within the `TAPPING_TERM` (default: 200ms), this will be registered as `al` by the firmware and host system. With the `HOLD_ON_OTHER_KEY_PRESS` option enabled, the Layer Tap key is considered as a layer switch if another key is pressed, and the above sequence would be registered as `KC_RGHT` (the mapping of `L` on layer 2).
|
||||
Normally, if you do all this within the `TAPPING_TERM` (default: 200ms), this will be registered as `al` by the firmware and host system. With the `HOLD_ON_OTHER_KEY_PRESS` option enabled, the Layer-Tap key is considered as a layer switch if another key is pressed, and the above sequence would be registered as `KC_RGHT` (the mapping of `L` on layer 2).
|
||||
|
||||
For more granular control of this feature, you can add the following to your `config.h`:
|
||||
|
||||
@@ -394,9 +428,9 @@ Example:
|
||||
- `SFT_T(KC_A)` Down
|
||||
- (wait until tapping term expires...)
|
||||
|
||||
With default settings, `a` will be sent on the first release, then `a` will be sent on the second press allowing the computer to trigger its auto repeat function until the key is released.
|
||||
With default settings, `a` will be sent on the first release, then `a` will be sent on the second press, allowing the computer to trigger its auto repeat function until the key is released.
|
||||
|
||||
With `QUICK_TAP_TERM` configured, the timing between `SFT_T(KC_A)` up and `SFT_T(KC_A)` down must be within `QUICK_TAP_TERM` to trigger auto repeat. Otherwise the second press will be sent as a Shift. If `QUICK_TAP_TERM` is set to `0`, the second press will always be sent as a Shift, effectively disabling auto-repeat.
|
||||
With `QUICK_TAP_TERM` configured, the timing between `SFT_T(KC_A)` up and `SFT_T(KC_A)` down must be within `QUICK_TAP_TERM` to trigger auto-repeat. Otherwise, the second press will be sent as a Shift. If `QUICK_TAP_TERM` is set to `0`, the second press will always be sent as a Shift, effectively disabling auto-repeat.
|
||||
|
||||
::: warning
|
||||
`QUICK_TAP_TERM` timing will also impact anything that uses tapping toggles (Such as the `TT` layer keycode, and the One Shot Tap Toggle).
|
||||
@@ -714,10 +748,10 @@ bool get_retro_tapping(uint16_t keycode, keyrecord_t *record) {
|
||||
}
|
||||
```
|
||||
|
||||
If the programs you use bind an action to taps of modifier keys (e.g. tapping left GUI to bring up the applications menu or tapping left Alt to focus the menu bar), you may find that using retro-tapping falsely triggers those actions. To counteract this, you can define a `DUMMY_MOD_NEUTRALIZER_KEYCODE` in `config.h` that will get sent in between the register and unregister events of a held mod-tap key. That way, the programs on your computer will no longer interpret the mod suppression induced by retro-tapping as a lone tap of a modifier key and will thus not falsely trigger the undesired action.
|
||||
If the programs you use bind an action to taps of modifier keys (e.g. tapping left GUI to bring up the applications menu or tapping left Alt to focus the menu bar), you may find that using retro-tapping falsely triggers those actions. To counteract this, you can define a `DUMMY_MOD_NEUTRALIZER_KEYCODE` in `config.h` that will get sent in between the register and unregister events of a held Mod-Tap key. That way, the programs on your computer will no longer interpret the mod suppression induced by retro-tapping as a lone tap of a modifier key and will thus not falsely trigger the undesired action.
|
||||
|
||||
Naturally, for this technique to be effective, you must choose a `DUMMY_MOD_NEUTRALIZER_KEYCODE` for which no keyboard shortcuts are bound to. Recommended values are: `KC_RIGHT_CTRL` or `KC_F18`.
|
||||
Please note that `DUMMY_MOD_NEUTRALIZER_KEYCODE` must be a basic, unmodified, HID keycode so values like `KC_NO`, `KC_TRANSPARENT` or `KC_PIPE` aka `S(KC_BACKSLASH)` are not permitted.
|
||||
Please note that `DUMMY_MOD_NEUTRALIZER_KEYCODE` must be a basic, unmodified, HID keycode, so values like `KC_NO`, `KC_TRANSPARENT`, or `KC_PIPE` (aka `S(KC_BACKSLASH)`) are not permitted.
|
||||
|
||||
By default, only left Alt and left GUI are neutralized. If you want to change the list of applicable modifier masks, use the following in your `config.h`:
|
||||
|
||||
@@ -743,14 +777,14 @@ Do not use `MOD_xxx` constants like `MOD_LSFT` or `MOD_RALT`, since they're 5-bi
|
||||
|
||||
### Retro Shift
|
||||
|
||||
[Auto Shift,](features/auto_shift) has its own version of `retro tapping` called `retro shift`. It is extremely similar to `retro tapping`, but holding the key past `AUTO_SHIFT_TIMEOUT` results in the value it sends being shifted. Other configurations also affect it differently; see [here](features/auto_shift#retro-shift) for more information.
|
||||
[Auto Shift](features/auto_shift) has its own version of `retro tapping` called `retro shift`. It is extremely similar to `retro tapping`, but holding the key past `AUTO_SHIFT_TIMEOUT` results in the value it sends being shifted. Other configurations also affect it differently; see [here](features/auto_shift#retro-shift) for more information.
|
||||
|
||||
## Why do we include the key record for the per key functions?
|
||||
|
||||
One thing that you may notice is that we include the key record for all of the "per key" functions, and may be wondering why we do that.
|
||||
|
||||
Well, it's simple really: customization. But specifically, it depends on how your keyboard is wired up. For instance, if each row is actually using a row in the keyboard's matrix, then it may be simpler to use `if (record->event.key.row == 3)` instead of checking a whole bunch of keycodes. Which is especially good for those people using the Tap Hold type keys on the home row. So you could fine-tune those to not interfere with your normal typing.
|
||||
Well, it's simple really: customization. But specifically, it depends on how your keyboard is wired up. For instance, if each row is actually using a row in the keyboard's matrix, then it may be simpler to use `if (record->event.key.row == 3)` instead of checking a whole bunch of keycodes, which is especially good for those people using the tap-hold keys on the home row (see about *home row mods* [here](https://precondition.github.io/home-row-mods)). So, you could fine-tune those to not interfere with your normal typing.
|
||||
|
||||
## Why are there no `*_kb` or `*_user` functions?!
|
||||
|
||||
Unlike many of the other functions here, there isn't a need (or even reason) to have a quantum or keyboard-level function. Only user-level functions are useful here, so no need to mark them as such.
|
||||
Unlike many of the other functions here, there isn't a need (or even reason) to have a quantum- or keyboard-level function. Only user-level functions are useful here, so there is no need to mark them as such.
|
||||
@@ -51,7 +51,7 @@ Matrix Scanning runs many times per second. The exact rate varies but typically
|
||||
|
||||
Once we know the state of every switch on our keyboard we have to map that to a keycode. In QMK this is done by making use of C macros to allow us to separate the definition of the physical layout from the definition of keycodes.
|
||||
|
||||
At the keyboard level we define a C macro (typically named `LAYOUT()`) which maps our keyboard's matrix to physical keys. Sometimes the matrix does not have a switch in every location, and we can use this macro to pre-populate those with KC_NO, making the keymap definition easier to work with. Here's an example `LAYOUT()` macro for a numpad:
|
||||
At the keyboard level, QMK will generate a macro (typically named `LAYOUT()`) from our configuration file `info.json`, which then maps our keyboard's matrix to physical keys. Sometimes the matrix does not have a switch in every location, and QMK will use this macro to pre-populate those with KC_NO, making the keymap definition easier to work with. Here's an example `LAYOUT()` macro for a numpad:
|
||||
|
||||
```c
|
||||
#define LAYOUT( \
|
||||
@@ -71,7 +71,7 @@ At the keyboard level we define a C macro (typically named `LAYOUT()`) which map
|
||||
|
||||
Notice how the second block of our `LAYOUT()` macro matches the Matrix Scanning array above? This macro is what will map the matrix scanning array to keycodes. However, if you look at a 17 key numpad you'll notice that it has 3 places where the matrix could have a switch but doesn't, due to larger keys. We have populated those spaces with `KC_NO` so that our keymap definition doesn't have to.
|
||||
|
||||
You can also use this macro to handle unusual matrix layouts, for example the [Alice](https://github.com/qmk/qmk_firmware/blob/325da02e57fe7374e77b82cb00360ba45167e25c/keyboards/sneakbox/aliceclone/aliceclone.h#L24). Explaining that is outside the scope of this document.
|
||||
This macro can handle unusual matrix layouts, for example the [Alice](https://github.com/qmk/qmk_firmware/blob/325da02e57fe7374e77b82cb00360ba45167e25c/keyboards/sneakbox/aliceclone/aliceclone.h#L24). Explaining that is outside the scope of this document.
|
||||
|
||||
##### Keycode Assignment
|
||||
|
||||
|
||||
65
keyboards/cata/keyboard.json
Normal file
@@ -0,0 +1,65 @@
|
||||
{
|
||||
"manufacturer": "Steven Karrmann",
|
||||
"keyboard_name": "Cata",
|
||||
"maintainer": "skarrmann",
|
||||
"bootloader": "rp2040",
|
||||
"diode_direction": "COL2ROW",
|
||||
"features": {
|
||||
"bootmagic": true,
|
||||
"extrakey": true,
|
||||
"mousekey": true,
|
||||
"nkro": true
|
||||
},
|
||||
"matrix_pins": {
|
||||
"cols": ["GP9", "GP10", "GP11", "GP12", "GP13", "GP14"],
|
||||
"rows": ["GP27", "GP5", "GP26", "GP6", "GP15", "GP7", "GP14", "GP8"]
|
||||
},
|
||||
"processor": "RP2040",
|
||||
"url": "https://github.com/skarrmann/cata",
|
||||
"usb": {
|
||||
"device_version": "1.0.0",
|
||||
"pid": "0x0000",
|
||||
"vid": "0xFEED"
|
||||
},
|
||||
"community_layouts": ["split_3x5_2"],
|
||||
"layouts": {
|
||||
"LAYOUT_split_3x5_2": {
|
||||
"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": [0, 4], "x": 4, "y": 0},
|
||||
{"matrix": [1, 0], "x": 6, "y": 0},
|
||||
{"matrix": [1, 1], "x": 7, "y": 0},
|
||||
{"matrix": [1, 2], "x": 8, "y": 0},
|
||||
{"matrix": [1, 3], "x": 9, "y": 0},
|
||||
{"matrix": [1, 4], "x": 10, "y": 0},
|
||||
{"matrix": [2, 0], "x": 0, "y": 1},
|
||||
{"matrix": [2, 1], "x": 1, "y": 1},
|
||||
{"matrix": [2, 2], "x": 2, "y": 1},
|
||||
{"matrix": [2, 3], "x": 3, "y": 1},
|
||||
{"matrix": [2, 4], "x": 4, "y": 1},
|
||||
{"matrix": [3, 0], "x": 6, "y": 1},
|
||||
{"matrix": [3, 1], "x": 7, "y": 1},
|
||||
{"matrix": [3, 2], "x": 8, "y": 1},
|
||||
{"matrix": [3, 3], "x": 9, "y": 1},
|
||||
{"matrix": [3, 4], "x": 10, "y": 1},
|
||||
{"matrix": [4, 0], "x": 0, "y": 2},
|
||||
{"matrix": [4, 1], "x": 1, "y": 2},
|
||||
{"matrix": [4, 2], "x": 2, "y": 2},
|
||||
{"matrix": [4, 3], "x": 3, "y": 2},
|
||||
{"matrix": [4, 4], "x": 4, "y": 2},
|
||||
{"matrix": [5, 0], "x": 6, "y": 2},
|
||||
{"matrix": [5, 1], "x": 7, "y": 2},
|
||||
{"matrix": [5, 2], "x": 8, "y": 2},
|
||||
{"matrix": [5, 3], "x": 9, "y": 2},
|
||||
{"matrix": [5, 4], "x": 10, "y": 2},
|
||||
{"matrix": [6, 3], "x": 3, "y": 3},
|
||||
{"matrix": [6, 4], "x": 4, "y": 3},
|
||||
{"matrix": [7, 0], "x": 6, "y": 3},
|
||||
{"matrix": [7, 1], "x": 7, "y": 3}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
42
keyboards/cata/keymaps/default/keymap.c
Normal file
@@ -0,0 +1,42 @@
|
||||
// Copyright 2025 Steven Karrmann (@skarrmann)
|
||||
// SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
#include QMK_KEYBOARD_H
|
||||
|
||||
enum layer_names {
|
||||
_BASE,
|
||||
_SYMBOL,
|
||||
_NAVIGATION,
|
||||
_FUNCTION
|
||||
};
|
||||
|
||||
#define MO_SYM MO(_SYMBOL)
|
||||
#define MO_NAV MO(_NAVIGATION)
|
||||
#define MO_FUN MO(_FUNCTION)
|
||||
|
||||
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
||||
[_BASE] = LAYOUT_split_3x5_2(
|
||||
KC_Q , KC_W , KC_E , KC_R , KC_T , KC_Y , KC_U , KC_I , KC_O , KC_P ,
|
||||
KC_A , KC_S , KC_D , KC_F , KC_G , KC_H , KC_J , KC_K , KC_L , KC_QUOT,
|
||||
KC_Z , KC_X , KC_C , KC_V , KC_B , KC_N , KC_M , KC_COMM, KC_DOT , KC_SLSH,
|
||||
MO_NAV , KC_LSFT, KC_SPC , MO_SYM
|
||||
),
|
||||
[_SYMBOL] = LAYOUT_split_3x5_2(
|
||||
KC_SCLN, KC_LBRC, KC_RBRC, KC_5 , XXXXXXX, XXXXXXX, KC_6 , KC_MINS, KC_EQL , KC_GRV ,
|
||||
KC_1 , KC_2 , KC_3 , KC_4 , KC_BSLS, XXXXXXX, KC_7 , KC_8 , KC_9 , KC_0 ,
|
||||
OS_LGUI, OS_LALT, OS_LSFT, OS_LCTL, XXXXXXX, XXXXXXX, OS_RCTL, OS_RSFT, OS_RALT, OS_RGUI,
|
||||
MO_FUN , _______, _______, _______
|
||||
),
|
||||
[_NAVIGATION] = LAYOUT_split_3x5_2(
|
||||
KC_PSCR, KC_INS , KC_APP , KC_DEL , XXXXXXX, XXXXXXX, KC_HOME, KC_PGDN, KC_PGUP, KC_END ,
|
||||
KC_ESC , KC_TAB , KC_ENT , KC_BSPC, XXXXXXX, XXXXXXX, KC_LEFT, KC_DOWN, KC_UP , KC_RGHT,
|
||||
OS_LGUI, OS_LALT, OS_LSFT, OS_LCTL, XXXXXXX, XXXXXXX, OS_RCTL, OS_RSFT, OS_RALT, OS_RGUI,
|
||||
_______, _______, _______, MO_FUN
|
||||
),
|
||||
[_FUNCTION] = LAYOUT_split_3x5_2(
|
||||
KC_F1 , KC_F2 , KC_F3 , KC_F4 , QK_BOOT, KC_SCRL, KC_F9 , KC_F10 , KC_F11 , KC_F12 ,
|
||||
KC_F5 , KC_F6 , KC_F7 , KC_F8 , XXXXXXX, KC_CAPS, KC_MUTE, KC_VOLD, KC_VOLU, KC_PAUS,
|
||||
OS_LGUI, OS_LALT, OS_LSFT, OS_LCTL, XXXXXXX, KC_NUM, OS_RCTL, OS_RSFT, OS_RALT, OS_RGUI,
|
||||
_______, _______, _______, _______
|
||||
),
|
||||
};
|
||||
27
keyboards/cata/readme.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Cata
|
||||
|
||||

|
||||
|
||||
Cata is a 34 key ortholinear keyboard, powered by a Waveshare RP2040-Zero.
|
||||
|
||||
* Keyboard Maintainer: [skarrmann](https://github.com/skarrmann)
|
||||
* Hardware Supported: Cata PCBs with RP2040-Zero
|
||||
* Hardware Availability: [Cata GitHub repository](https://github.com/skarrmann/cata)
|
||||
|
||||
Make example for this keyboard (after setting up your build environment):
|
||||
|
||||
make cata:default
|
||||
|
||||
Flashing example for this keyboard:
|
||||
|
||||
make cata:default:flash
|
||||
|
||||
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
|
||||
|
||||
## Bootloader
|
||||
|
||||
Enter the bootloader in 3 ways:
|
||||
|
||||
* **Bootmagic reset**: Hold down the key at (0,0) in the matrix (the top left key) and plug in the keyboard.
|
||||
* **Physical reset button**: Double-tap the RESET button on the RP-2040 Zero (button on the right).
|
||||
* **Keycode in layout**: Press the key mapped to `QK_BOOT` if it is available.
|
||||
14
keyboards/cornifi/config.h
Normal file
@@ -0,0 +1,14 @@
|
||||
// Copyright 2024-2025 QMK
|
||||
// SPDX-License-Identifier: GPL-3.0-or-later
|
||||
|
||||
#pragma once
|
||||
|
||||
#define SERIAL_USART_FULL_DUPLEX
|
||||
#define SERIAL_USART_TX_PIN GP12
|
||||
#define SERIAL_USART_RX_PIN GP13
|
||||
#define USB_VBUS_PIN GP24
|
||||
|
||||
/* RP2040- and hardware-specific config */
|
||||
#define RP2040_BOOTLOADER_DOUBLE_TAP_RESET
|
||||
#define RP2040_BOOTLOADER_DOUBLE_TAP_RESET_TIMEOUT 500U
|
||||
#define PICO_XOSC_STARTUP_DELAY_MULTIPLIER 64
|
||||
96
keyboards/cornifi/keyboard.json
Normal file
@@ -0,0 +1,96 @@
|
||||
{
|
||||
"manufacturer": "v3lmx",
|
||||
"keyboard_name": "cornifi",
|
||||
"maintainer": "v3lmx",
|
||||
"bootloader": "rp2040",
|
||||
"diode_direction": "COL2ROW",
|
||||
"features": {
|
||||
"bootmagic": true,
|
||||
"extrakey": true,
|
||||
"mousekey": true,
|
||||
"nkro": true
|
||||
},
|
||||
"matrix_pins": {
|
||||
"direct": [
|
||||
["GP21", "GP25", "GP26", "GP28", "GP29", "GP5"],
|
||||
["GP20", "GP22", "GP27", "GP2", "GP3", "GP8"],
|
||||
["GP19", "GP23", "GP1", "GP0", "GP4", null],
|
||||
[null, null, "GP16", "GP17", "GP18", null]
|
||||
]
|
||||
},
|
||||
"processor": "RP2040",
|
||||
"split": {
|
||||
"bootmagic": {
|
||||
"matrix": [4, 0]
|
||||
},
|
||||
"enabled": true,
|
||||
"matrix_pins": {
|
||||
"right": {
|
||||
"direct": [
|
||||
["GP9", "GP8", "GP4", "GP3", "GP2", "GP25"],
|
||||
["GP10", "GP6", "GP1", "GP28", "GP27", "GP21"],
|
||||
["GP11", "GP5", "GP0", "GP29", "GP26", null],
|
||||
[null, null, "GP16", "GP17", "GP18", null]
|
||||
]
|
||||
}
|
||||
},
|
||||
"serial": {
|
||||
"driver": "vendor"
|
||||
}
|
||||
},
|
||||
"url": "https://github.com/v3lmx/cornifi",
|
||||
"usb": {
|
||||
"device_version": "1.0.0",
|
||||
"pid": "0x0000",
|
||||
"vid": "0xFEED"
|
||||
},
|
||||
"layout_aliases": {
|
||||
"LAYOUT": "LAYOUT_split_3x5_3_ex2"
|
||||
},
|
||||
"layouts": {
|
||||
"LAYOUT_split_3x5_3_ex2": {
|
||||
"layout": [
|
||||
{"matrix": [0, 0], "x": 0, "y": 0.9},
|
||||
{"matrix": [0, 1], "x": 1, "y": 0.3},
|
||||
{"matrix": [0, 2], "x": 2, "y": 0},
|
||||
{"matrix": [0, 3], "x": 3, "y": 0.35},
|
||||
{"matrix": [0, 4], "x": 4, "y": 0.45},
|
||||
{"matrix": [0, 5], "x": 5, "y": 0.7},
|
||||
{"matrix": [4, 5], "x": 8, "y": 0.7},
|
||||
{"matrix": [4, 4], "x": 9, "y": 0.45},
|
||||
{"matrix": [4, 3], "x": 10, "y": 0.35},
|
||||
{"matrix": [4, 2], "x": 11, "y": 0},
|
||||
{"matrix": [4, 1], "x": 12, "y": 0.3},
|
||||
{"matrix": [4, 0], "x": 13, "y": 0.9},
|
||||
{"matrix": [1, 0], "x": 0, "y": 1.9},
|
||||
{"matrix": [1, 1], "x": 1, "y": 1.3},
|
||||
{"matrix": [1, 2], "x": 2, "y": 1},
|
||||
{"matrix": [1, 3], "x": 3, "y": 1.35},
|
||||
{"matrix": [1, 4], "x": 4, "y": 1.45},
|
||||
{"matrix": [1, 5], "x": 5, "y": 1.7},
|
||||
{"matrix": [5, 5], "x": 8, "y": 1.7},
|
||||
{"matrix": [5, 4], "x": 9, "y": 1.45},
|
||||
{"matrix": [5, 3], "x": 10, "y": 1.35},
|
||||
{"matrix": [5, 2], "x": 11, "y": 1},
|
||||
{"matrix": [5, 1], "x": 12, "y": 1.3},
|
||||
{"matrix": [5, 0], "x": 13, "y": 1.9},
|
||||
{"matrix": [2, 0], "x": 0, "y": 2.9},
|
||||
{"matrix": [2, 1], "x": 1, "y": 2.3},
|
||||
{"matrix": [2, 2], "x": 2, "y": 2},
|
||||
{"matrix": [2, 3], "x": 3, "y": 2.35},
|
||||
{"matrix": [2, 4], "x": 4, "y": 2.45},
|
||||
{"matrix": [6, 4], "x": 9, "y": 2.45},
|
||||
{"matrix": [6, 3], "x": 10, "y": 2.35},
|
||||
{"matrix": [6, 2], "x": 11, "y": 2},
|
||||
{"matrix": [6, 1], "x": 12, "y": 2.3},
|
||||
{"matrix": [6, 0], "x": 13, "y": 2.9},
|
||||
{"matrix": [3, 2], "x": 3, "y": 3.7},
|
||||
{"matrix": [3, 3], "x": 4, "y": 3.7},
|
||||
{"matrix": [3, 4], "x": 5, "y": 3.2, "h": 1.5},
|
||||
{"matrix": [7, 4], "x": 8, "y": 3.2, "h": 1.5},
|
||||
{"matrix": [7, 3], "x": 9, "y": 3.7},
|
||||
{"matrix": [7, 2], "x": 10, "y": 3.7}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
27
keyboards/cornifi/keymaps/default/keymap.c
Normal file
@@ -0,0 +1,27 @@
|
||||
// Copyright 2025 @v3lmx
|
||||
// SPDX-License-Identifier: GPL-3.0-or-later
|
||||
|
||||
#include QMK_KEYBOARD_H
|
||||
|
||||
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
||||
// clang-format off
|
||||
[0] = LAYOUT_split_3x5_3_ex2(
|
||||
KC_Q, KC_W, KC_E, KC_R, KC_T, KC_LBRC, KC_RBRC, KC_Y, KC_U, KC_I, KC_O, KC_P,
|
||||
KC_A, KC_S, KC_D, KC_F, KC_G, XXXXXXX, XXXXXXX, KC_H, KC_J, KC_K, KC_L, KC_SCLN,
|
||||
KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM,KC_DOT, KC_SLSH,
|
||||
KC_ESC, MO(1), KC_TAB, KC_ENT, MO(2), KC_BSPC
|
||||
),
|
||||
[1] = LAYOUT_split_3x5_3_ex2(
|
||||
KC_1, KC_2, KC_3, KC_4, KC_5, _______, _______, KC_6, KC_7, KC_8, KC_9, KC_0,
|
||||
XXXXXXX,XXXXXXX,XXXXXXX,XXXXXXX,XXXXXXX,_______, _______, KC_LEFT,KC_DOWN,KC_UP, KC_RIGHT,XXXXXXX,
|
||||
XXXXXXX,XXXXXXX,XXXXXXX,XXXXXXX,XXXXXXX, XXXXXXX,XXXXXXX,XXXXXXX,XXXXXXX,XXXXXXX,
|
||||
KC_LGUI,_______,KC_SPC, KC_ENT, XXXXXXX, KC_RALT
|
||||
),
|
||||
[2] = LAYOUT_split_3x5_3_ex2(
|
||||
KC_EXLM, KC_AT,KC_HASH, KC_DLR, KC_PERC,_______, _______, KC_CIRC,KC_AMPR,KC_ASTR,KC_LPRN,KC_RPRN,
|
||||
XXXXXXX,XXXXXXX,XXXXXXX,XXXXXXX,XXXXXXX,_______, _______, KC_MINS,KC_EQL, KC_LBRC,KC_RBRC,KC_BSLS,
|
||||
XXXXXXX,XXXXXXX,XXXXXXX,XXXXXXX,XXXXXXX, KC_UNDS,KC_PLUS,KC_LCBR,KC_RCBR,KC_PIPE,
|
||||
KC_LGUI,XXXXXXX, KC_SPC, KC_ENT, _______,KC_RALT
|
||||
)
|
||||
// clang-format on
|
||||
};
|
||||
32
keyboards/cornifi/readme.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# cornifi
|
||||
|
||||

|
||||
|
||||
The cornifi keyboard is a split keyboard based on the [corne](https://github.com/foostan/crkbd) with the physical layout of the [fifi](https://github.com/raychengy/fifi_split_keeb).
|
||||
|
||||
* Keyboard Maintainer: [v3lmx (github)](https://github.com/v3lmx)
|
||||
* Hardware Availability: [v3lmx/cornifi (github)](https://github.com/v3lmx/cornifi)
|
||||
|
||||
Make example for this keyboard (after setting up your build environment):
|
||||
|
||||
make cornifi:default
|
||||
|
||||
Flashing example for this keyboard:
|
||||
|
||||
make cornifi:default:flash
|
||||
|
||||
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
|
||||
|
||||
## Bootloader
|
||||
|
||||
Enter the bootloader in 3 ways:
|
||||
|
||||
* **Bootmagic reset**: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard
|
||||
* **Physical reset button**: Hold down the `boot` button and press the `reset` button
|
||||
* **Keycode in layout**: Press the key mapped to `TD_BOOT` twice if it is available
|
||||
|
||||
## Keymap
|
||||
|
||||
It is recommended to make your own keymap using the [external userspace feature(https://docs.qmk.fm/newbs_external_userspace).
|
||||
|
||||
You can find an example here: [v3lmx qmk userspace](https://github.com/v3lmx/qmk_userspace)
|
||||
39
keyboards/enmeseoz/enmepad3x4/keyboard.json
Normal file
@@ -0,0 +1,39 @@
|
||||
{
|
||||
"manufacturer": "ENMESEOZ",
|
||||
"keyboard_name": "ENMEPAD",
|
||||
"maintainer": "ENMESEOZ",
|
||||
"bootloader": "rp2040",
|
||||
"diode_direction": "COL2ROW",
|
||||
"features": {
|
||||
"bootmagic": true,
|
||||
"nkro": true
|
||||
},
|
||||
"matrix_pins": {
|
||||
"cols": ["GP26", "GP27", "GP28", "GP29"],
|
||||
"rows": ["GP3", "GP4", "GP5"]
|
||||
},
|
||||
"processor": "RP2040",
|
||||
"usb": {
|
||||
"device_version": "1.0.0",
|
||||
"pid": "0x0000",
|
||||
"vid": "0xFEED"
|
||||
},
|
||||
"layouts": {
|
||||
"LAYOUT_3x4": {
|
||||
"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}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
31
keyboards/enmeseoz/enmepad3x4/keymaps/default/keymap.c
Normal file
@@ -0,0 +1,31 @@
|
||||
/* Copyright 2025 ENMESEOZ
|
||||
*
|
||||
* This program is free software: you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License as published by
|
||||
* the Free Software Foundation, either version 2 of the License, or
|
||||
* (at your option) any later version.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
*/
|
||||
|
||||
#include QMK_KEYBOARD_H
|
||||
|
||||
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
||||
|
||||
LAYOUT_3x4(
|
||||
KC_0, KC_1, KC_4, KC_7,
|
||||
KC_ENT, KC_2, KC_5, KC_8,
|
||||
MO(1), KC_3, KC_6, KC_9
|
||||
),
|
||||
LAYOUT_3x4(
|
||||
QK_BOOT, KC_TRNS, KC_TRNS, KC_TRNS,
|
||||
KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS,
|
||||
KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS
|
||||
)
|
||||
};
|
||||
25
keyboards/enmeseoz/enmepad3x4/readme.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# ENMEPAD 3x4
|
||||
|
||||
ENMEPAD3x4 a compact macropad controlled with rp2040.
|
||||
|
||||
* Keyboard Maintainer: [bkchqaeh](https://github.com/bkchqaeh)
|
||||
* Hardware Supported: *rp2040*
|
||||
* Hardware Availability: *Not available*
|
||||
|
||||
Make example for this keyboard (after setting up your build environment):
|
||||
|
||||
make enmeseoz/enmepad3x4:default
|
||||
|
||||
Flashing example for this keyboard:
|
||||
|
||||
make enmeseoz/enmepad3x4:default:flash
|
||||
|
||||
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
|
||||
|
||||
## Bootloader
|
||||
|
||||
Enter the bootloader in 3 ways:
|
||||
|
||||
* **Bootmagic reset**: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard
|
||||
* **Physical reset button**: Briefly press the button on the back of the PCB - some may have pads you must short instead
|
||||
* **Keycode in layout**: Press the key mapped to `QK_BOOT` if it is available
|
||||
33
keyboards/enochchau/dropout/dropout.c
Normal file
@@ -0,0 +1,33 @@
|
||||
// Copyright 2025 Enoch Chau <enoch965@gmail.com>
|
||||
// SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
#include "quantum.h"
|
||||
|
||||
// Mimic handle_backlight_caps_lock to use num lock indicator for backlight
|
||||
void handle_backlight_num_lock(led_t led_state) {
|
||||
// Use backlight as num_lock indicator
|
||||
uint8_t bl_toggle_lvl = 0;
|
||||
bool backlight_enabled = is_backlight_enabled();
|
||||
|
||||
if (led_state.num_lock && !backlight_enabled) {
|
||||
// Turning num_lock ON and backlight is disabled in config
|
||||
// Toggling backlight to the brightest level
|
||||
bl_toggle_lvl = BACKLIGHT_LEVELS;
|
||||
} else if (!led_state.num_lock && backlight_enabled) {
|
||||
// Turning num_lock OFF and backlight is enabled in config
|
||||
// Toggling backlight and restoring config level
|
||||
bl_toggle_lvl = get_backlight_level();
|
||||
}
|
||||
|
||||
backlight_set(bl_toggle_lvl);
|
||||
}
|
||||
|
||||
bool led_update_kb(led_t led_state) {
|
||||
bool res = led_update_user(led_state);
|
||||
if (res) {
|
||||
#ifdef BACKLIGHT_ENABLE
|
||||
handle_backlight_num_lock(led_state);
|
||||
#endif
|
||||
}
|
||||
return res;
|
||||
}
|
||||
60
keyboards/enochchau/dropout/keyboard.json
Normal file
@@ -0,0 +1,60 @@
|
||||
{
|
||||
"manufacturer": "enochchau",
|
||||
"keyboard_name": "dropout",
|
||||
"maintainer": "enochchau",
|
||||
"backlight": {
|
||||
"levels": 6,
|
||||
"on_state": 0,
|
||||
"pin": "B6"
|
||||
},
|
||||
"development_board": "promicro",
|
||||
"diode_direction": "COL2ROW",
|
||||
"encoder": {
|
||||
"rotary": [
|
||||
{"pin_a": "D0", "pin_b": "D4"}
|
||||
]
|
||||
},
|
||||
"features": {
|
||||
"backlight": true,
|
||||
"bootmagic": true,
|
||||
"encoder": true,
|
||||
"extrakey": true,
|
||||
"mousekey": true,
|
||||
"nkro": true
|
||||
},
|
||||
"matrix_pins": {
|
||||
"cols": ["B3", "B1", "D7", "C6"],
|
||||
"rows": ["D1", "B2", "E6", "B4", "B5"]
|
||||
},
|
||||
"tags": ["numpad"],
|
||||
"url": "https://github.com/enochchau/dropout-numpad",
|
||||
"usb": {
|
||||
"device_version": "0.0.1",
|
||||
"pid": "0x2800",
|
||||
"vid": "0x9650"
|
||||
},
|
||||
"layouts": {
|
||||
"LAYOUT": {
|
||||
"layout": [
|
||||
{"label": "Num Lock", "matrix": [0, 0], "x": 0, "y": 0},
|
||||
{"label": "/", "matrix": [0, 1], "x": 1, "y": 0},
|
||||
{"label": "*", "matrix": [0, 2], "x": 2, "y": 0},
|
||||
{"label": "Play", "matrix": [0, 3], "x": 3, "y": 0, "encoder": 0},
|
||||
{"label": "7", "matrix": [1, 0], "x": 0, "y": 1},
|
||||
{"label": "8", "matrix": [1, 1], "x": 1, "y": 1},
|
||||
{"label": "9", "matrix": [1, 2], "x": 2, "y": 1},
|
||||
{"label": "-", "matrix": [1, 3], "x": 3, "y": 1},
|
||||
{"label": "4", "matrix": [2, 0], "x": 0, "y": 2},
|
||||
{"label": "5", "matrix": [2, 1], "x": 1, "y": 2},
|
||||
{"label": "6", "matrix": [2, 2], "x": 2, "y": 2},
|
||||
{"label": "+", "matrix": [2, 3], "x": 3, "y": 2},
|
||||
{"label": "1", "matrix": [3, 0], "x": 0, "y": 3},
|
||||
{"label": "2", "matrix": [3, 1], "x": 1, "y": 3},
|
||||
{"label": "3", "matrix": [3, 2], "x": 2, "y": 3},
|
||||
{"label": "Enter", "matrix": [3, 3], "x": 3, "y": 3, "h": 2},
|
||||
{"label": "0", "matrix": [4, 0], "x": 0, "y": 4, "w": 2},
|
||||
{"label": ".", "matrix": [4, 2], "x": 2, "y": 4}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
35
keyboards/enochchau/dropout/keymaps/default/keymap.c
Normal file
@@ -0,0 +1,35 @@
|
||||
// Copyright 2025 Enoch Chau <enoch965@gmail.com>
|
||||
// SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
#include QMK_KEYBOARD_H
|
||||
|
||||
enum layer_names {
|
||||
_BASE,
|
||||
_LIGHT
|
||||
};
|
||||
|
||||
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
||||
|
||||
[_BASE] = LAYOUT(
|
||||
LT(1, KC_NUM), KC_PSLS, KC_PAST, KC_MPLY,
|
||||
KC_P7, KC_P8, KC_P9, KC_PMNS,
|
||||
KC_P4, KC_P5, KC_P6, KC_PPLS,
|
||||
KC_P1, KC_P2, KC_P3, KC_PENT,
|
||||
KC_P0, KC_PDOT
|
||||
),
|
||||
|
||||
[_LIGHT] = LAYOUT(
|
||||
_______, _______, _______, _______,
|
||||
_______, BL_UP, BL_DOWN, BL_TOGG,
|
||||
_______, _______, _______, _______,
|
||||
_______, _______, _______, QK_BOOT,
|
||||
_______, _______
|
||||
)
|
||||
};
|
||||
|
||||
#if defined(ENCODER_MAP_ENABLE)
|
||||
const uint16_t PROGMEM encoder_map[][NUM_ENCODERS][NUM_DIRECTIONS] = {
|
||||
[_BASE] = {ENCODER_CCW_CW(KC_VOLU, KC_VOLD)},
|
||||
[_LIGHT] = {ENCODER_CCW_CW(_______, _______)}
|
||||
};
|
||||
#endif
|
||||
1
keyboards/enochchau/dropout/keymaps/default/rules.mk
Normal file
@@ -0,0 +1 @@
|
||||
ENCODER_MAP_ENABLE = yes
|
||||
27
keyboards/enochchau/dropout/readme.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# dropout
|
||||
|
||||

|
||||
|
||||
A numpad with a rotary encoder.
|
||||
|
||||
* Keyboard Maintainer: [Enoch Chau](https://github.com/enochchau)
|
||||
* Hardware Supported: PCB w/ Pro Micro compatible development board
|
||||
* Hardware Availability: [Github](https://github.com/enochchau/dropout-numpad)
|
||||
|
||||
Make example for this keyboard (after setting up your build environment):
|
||||
|
||||
make enochchau/dropout:default
|
||||
|
||||
Flashing example for this keyboard:
|
||||
|
||||
make enochchau/dropout:default:flash
|
||||
|
||||
See the [build environment setup](https://docs.qmk.fm/#/getting_started_build_tools) and the [make instructions](https://docs.qmk.fm/#/getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](https://docs.qmk.fm/#/newbs).
|
||||
|
||||
## Bootloader
|
||||
|
||||
Enter the bootloader in 3 ways:
|
||||
|
||||
* **Bootmagic reset**: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard
|
||||
* **Physical reset button**: Briefly press the button on the micro-controller
|
||||
* **Keycode in layout**: Press the key mapped to `QK_BOOT` if it is available
|
||||
20
keyboards/handwired/dactyl_manuform/5x7_2_6/config.h
Normal file
@@ -0,0 +1,20 @@
|
||||
/*
|
||||
Copyright 2012 Jun Wako <wakojun@gmail.com> Nikolai Grigoriev @ngrigoriev
|
||||
|
||||
This program is free software: you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation, either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
*/
|
||||
|
||||
#pragma once
|
||||
|
||||
#define EE_HANDS
|
||||
115
keyboards/handwired/dactyl_manuform/5x7_2_6/keyboard.json
Normal file
@@ -0,0 +1,115 @@
|
||||
{
|
||||
"manufacturer": "Nikolai Grigoriev",
|
||||
"keyboard_name": "Dactyl Manuform 5x7 2-key last row 6-key thumb cluster",
|
||||
"maintainer": "ngrigoriev",
|
||||
"build": {
|
||||
"lto": true
|
||||
},
|
||||
"development_board": "promicro",
|
||||
"diode_direction": "COL2ROW",
|
||||
"features": {
|
||||
"bootmagic": false,
|
||||
"nkro": true
|
||||
},
|
||||
"matrix_pins": {
|
||||
"cols": ["F5", "F6", "F7", "B1", "B3", "B2", "B6"],
|
||||
"rows": ["D4", "C6", "D7", "E6", "B4", "B5"]
|
||||
},
|
||||
"qmk": {
|
||||
"locking": {
|
||||
"enabled": true,
|
||||
"resync": true
|
||||
}
|
||||
},
|
||||
"split": {
|
||||
"enabled": true,
|
||||
"transport": {
|
||||
"protocol": "i2c"
|
||||
},
|
||||
"usb_detect": {
|
||||
"enabled": true
|
||||
}
|
||||
},
|
||||
"url": "https://github.com/ngrigoriev/dactyl-manuform-5x7_2_6",
|
||||
"usb": {
|
||||
"device_version": "1.0.0",
|
||||
"pid": "0x0000",
|
||||
"vid": "0xFEED"
|
||||
},
|
||||
"layouts": {
|
||||
"LAYOUT_5x7_2_6": {
|
||||
"layout": [
|
||||
{"label": "KC_GRV", "matrix": [0, 0], "x": 0, "y": 0.5, "w": 1.5},
|
||||
{"label": "KC_1", "matrix": [0, 1], "x": 1.5, "y": 0.5},
|
||||
{"label": "KC_2", "matrix": [0, 2], "x": 2.5, "y": 0},
|
||||
{"label": "KC_3", "matrix": [0, 3], "x": 3.5, "y": 0},
|
||||
{"label": "KC_4", "matrix": [0, 4], "x": 4.5, "y": 0},
|
||||
{"label": "KC_5", "matrix": [0, 5], "x": 5.5, "y": 0},
|
||||
{"label": "KC_NO", "matrix": [0, 6], "x": 6.5, "y": 0},
|
||||
{"label": "KC_EQL", "matrix": [6, 0], "x": 12, "y": 0},
|
||||
{"label": "KC_6", "matrix": [6, 1], "x": 13, "y": 0},
|
||||
{"label": "KC_7", "matrix": [6, 2], "x": 14, "y": 0},
|
||||
{"label": "KC_8", "matrix": [6, 3], "x": 15, "y": 0},
|
||||
{"label": "KC_9", "matrix": [6, 4], "x": 16, "y": 0},
|
||||
{"label": "KC_0", "matrix": [6, 5], "x": 17, "y": 0.5},
|
||||
{"label": "KC_BSPC", "matrix": [6, 6], "x": 18, "y": 0.5, "w": 1.5},
|
||||
{"label": "KC_TAB", "matrix": [1, 0], "x": 0, "y": 1.5, "w": 1.5},
|
||||
{"label": "KC_Q", "matrix": [1, 1], "x": 1.5, "y": 1.5},
|
||||
{"label": "KC_W", "matrix": [1, 2], "x": 2.5, "y": 1},
|
||||
{"label": "KC_E", "matrix": [1, 3], "x": 3.5, "y": 1},
|
||||
{"label": "KC_R", "matrix": [1, 4], "x": 4.5, "y": 1},
|
||||
{"label": "KC_T", "matrix": [1, 5], "x": 5.5, "y": 1},
|
||||
{"label": "KC_NO", "matrix": [1, 6], "x": 6.5, "y": 1},
|
||||
{"label": "KC_MINUS", "matrix": [7, 0], "x": 12, "y": 1},
|
||||
{"label": "KC_Y", "matrix": [7, 1], "x": 13, "y": 1},
|
||||
{"label": "KC_U", "matrix": [7, 2], "x": 14, "y": 1},
|
||||
{"label": "KC_I", "matrix": [7, 3], "x": 15, "y": 1},
|
||||
{"label": "KC_O", "matrix": [7, 4], "x": 16, "y": 1},
|
||||
{"label": "KC_P", "matrix": [7, 5], "x": 17, "y": 1.5},
|
||||
{"label": "KC_BSLS", "matrix": [7, 6], "x": 18, "y": 1.5, "w": 1.5},
|
||||
{"label": "KC_LCTL", "matrix": [2, 0], "x": 0, "y": 2.5, "w": 1.5},
|
||||
{"label": "KC_A", "matrix": [2, 1], "x": 1.5, "y": 2.5},
|
||||
{"label": "KC_S", "matrix": [2, 2], "x": 2.5, "y": 2},
|
||||
{"label": "KC_D", "matrix": [2, 3], "x": 3.5, "y": 2},
|
||||
{"label": "KC_F", "matrix": [2, 4], "x": 4.5, "y": 2},
|
||||
{"label": "KC_G", "matrix": [2, 5], "x": 5.5, "y": 2},
|
||||
{"label": "KC_NO", "matrix": [2, 6], "x": 6.5, "y": 2},
|
||||
{"label": "KC_DEL", "matrix": [8, 0], "x": 12, "y": 2},
|
||||
{"label": "KC_H", "matrix": [8, 1], "x": 13, "y": 2},
|
||||
{"label": "KC_J", "matrix": [8, 2], "x": 14, "y": 2},
|
||||
{"label": "KC_K", "matrix": [8, 3], "x": 15, "y": 2},
|
||||
{"label": "KC_L", "matrix": [8, 4], "x": 16, "y": 2},
|
||||
{"label": "KC_SCLN", "matrix": [8, 5], "x": 17, "y": 2.5},
|
||||
{"label": "KC_RSFT", "matrix": [8, 6], "x": 18, "y": 2.5, "w": 1.5},
|
||||
{"label": "KC_LSFT", "matrix": [3, 0], "x": 0, "y": 3.5, "w": 1.5},
|
||||
{"label": "KC_Z", "matrix": [3, 1], "x": 1.5, "y": 3.5},
|
||||
{"label": "KC_X", "matrix": [3, 2], "x": 2.5, "y": 3},
|
||||
{"label": "KC_C", "matrix": [3, 3], "x": 3.5, "y": 3},
|
||||
{"label": "KC_V", "matrix": [3, 4], "x": 4.5, "y": 3},
|
||||
{"label": "KC_B", "matrix": [3, 5], "x": 5.5, "y": 3},
|
||||
{"label": "KC_N", "matrix": [9, 1], "x": 13, "y": 3},
|
||||
{"label": "KC_M", "matrix": [9, 2], "x": 14, "y": 3},
|
||||
{"label": "KC_COMM", "matrix": [9, 3], "x": 15, "y": 3},
|
||||
{"label": "KC_DOT", "matrix": [9, 4], "x": 16, "y": 3},
|
||||
{"label": "KC_SLSH", "matrix": [9, 5], "x": 17, "y": 3.5},
|
||||
{"label": "KC_RSFT", "matrix": [9, 6], "x": 18, "y": 3.5, "w": 1.5},
|
||||
{"label": "KC_PGUP", "matrix": [4, 2], "x": 2.5, "y": 4},
|
||||
{"label": "KC_PGDN", "matrix": [4, 3], "x": 3.5, "y": 4},
|
||||
{"label": "KC_LBRC", "matrix": [10, 3], "x": 15, "y": 4},
|
||||
{"label": "KC_RBRC", "matrix": [10, 4], "x": 16, "y": 4},
|
||||
{"label": "KC_LCTL", "matrix": [4, 4], "x": 5, "y": 5, "h": 1.5, "r": 30},
|
||||
{"label": "KC_ESC", "matrix": [4, 5], "x": 6, "y": 5, "h": 1.5, "r": 30},
|
||||
{"label": "KC_ENTER", "matrix": [10, 1], "x": 12.5, "y": 5, "h": 1.5, "r": -30},
|
||||
{"label": "KC_SPC", "matrix": [10, 2], "x": 13.5, "y": 5, "h": 1.5, "r": -30},
|
||||
{"label": "KC_UP", "matrix": [5, 5], "x": 7.5, "y": 6.5, "r": 45},
|
||||
{"label": "KC_DOWN", "matrix": [5, 3], "x": 8, "y": 7.5, "r": 45},
|
||||
{"label": "KC_LEFT", "matrix": [11, 3], "x": 10.5, "y": 7.5, "r": -45},
|
||||
{"label": "KC_RIGHT", "matrix": [11, 1], "x": 11, "y": 6.5, "r": -45},
|
||||
{"label": "KC_LCMD", "matrix": [5, 4], "x": 6.5, "y": 7, "r": 45},
|
||||
{"label": "KC_LALT", "matrix": [5, 2], "x": 7, "y": 8, "r": 45},
|
||||
{"label": "KC_RCTL", "matrix": [11, 4], "x": 11.5, "y": 8, "r": -45},
|
||||
{"label": "KC_RALT", "matrix": [11, 2], "x": 12, "y": 7, "r": -45}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,74 @@
|
||||
/* vim: noai:ts=4:sw=4:nowrap
|
||||
*/
|
||||
/*
|
||||
Copyright 2012 Jun Wako <wakojun@gmail.com> Nikolai Grigoriev @ngrigoriev
|
||||
|
||||
This program is free software: you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation, either version 2 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
*/
|
||||
|
||||
#include QMK_KEYBOARD_H
|
||||
|
||||
enum layers {
|
||||
_BASE,
|
||||
_MAGIC,
|
||||
_NUMPAD,
|
||||
_FN
|
||||
};
|
||||
|
||||
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
|
||||
[_BASE] = LAYOUT_5x7_2_6(
|
||||
KC_GRV, KC_1, KC_2, KC_3, KC_4, KC_5, MO(_MAGIC), KC_EQL, KC_6, KC_7, KC_8, KC_9, KC_0, KC_BSPC,
|
||||
KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, MO(_NUMPAD), KC_MINUS, KC_Y, KC_U, KC_I, KC_O, KC_P, KC_BSLS,
|
||||
KC_LCTL, KC_A, KC_S, KC_D, KC_F, KC_G, _______, KC_DEL, KC_H, KC_J, KC_K, KC_L, KC_SCLN, KC_QUOT,
|
||||
OSM(MOD_LSFT), KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, OSM(MOD_RSFT),
|
||||
KC_PGUP, KC_PGDN, KC_LBRC, KC_RBRC,
|
||||
KC_LCTL, LT(_FN, KC_ESC), KC_ENTER,KC_SPC,
|
||||
KC_UP, KC_DOWN, KC_LEFT, KC_RIGHT,
|
||||
KC_LCMD, KC_LALT, KC_RCTL, KC_RALT
|
||||
),
|
||||
|
||||
[_FN] = LAYOUT_5x7_2_6(
|
||||
_______, KC_F1, KC_F2, KC_F3, KC_F4, KC_F5, MO(_MAGIC), _______, KC_F6, KC_F7, KC_F8, KC_F9, KC_F10, KC_F11,
|
||||
_______, _______, _______, KC_UP, _______, _______, _______, _______, _______, _______, _______, _______, _______, KC_F12,
|
||||
_______, _______, KC_LEFT, KC_DOWN, KC_RGHT, _______, QK_BOOT, _______, KC_LEFT, KC_DOWN, KC_UP, KC_RIGHT, _______, _______,
|
||||
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,
|
||||
KC_MPRV, KC_MNXT, _______, _______,
|
||||
_______, _______, KC_DEL, _______,
|
||||
_______, _______, _______, _______,
|
||||
_______, _______, _______, _______
|
||||
),
|
||||
|
||||
[_NUMPAD] = LAYOUT_5x7_2_6(
|
||||
_______, _______, _______, _______, _______, _______, MO(_MAGIC), _______, _______, KC_NUM, _______, KC_PMNS, KC_PPLS, _______,
|
||||
_______, _______, _______, _______, _______, _______, _______, _______, _______, KC_P7, KC_P8, KC_P9, _______, _______,
|
||||
_______, _______, _______, _______, _______, _______, _______, _______, KC_LEFT, KC_P4, KC_P5, KC_P6, KC_PAST, _______,
|
||||
_______, _______, _______, _______, _______, _______, _______, KC_P1, KC_P2, KC_P3, KC_PSLS, _______,
|
||||
_______, _______, KC_P0, KC_PDOT,
|
||||
_______, _______, _______, KC_PENT,
|
||||
_______, _______, _______, _______,
|
||||
_______, _______, _______, _______
|
||||
),
|
||||
|
||||
[_MAGIC] = LAYOUT_5x7_2_6(
|
||||
_______, _______, _______, _______, _______, _______, _______, CG_SWAP, _______, _______, _______, _______, _______, QK_REBOOT,
|
||||
_______, _______, _______, _______, _______, _______, _______, CG_NORM, _______, _______, _______, _______, _______, _______,
|
||||
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, QK_BOOTLOADER,
|
||||
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,
|
||||
_______, _______, _______, _______,
|
||||
_______, _______, _______, _______,
|
||||
_______, _______, _______, _______,
|
||||
_______, _______, _______, _______
|
||||
)
|
||||
};
|
||||
|
||||
29
keyboards/handwired/dactyl_manuform/5x7_2_6/readme.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# handwired/dactyl_manuform/5x7_2_6
|
||||
|
||||

|
||||
|
||||
A standard Dactyl Manuform keyboard with 5x7 matrix, 6 thumb cluster keys. Last row has 2 keys only. Index column has 3 rows. The outer keys are 1,5u wide. [More info on https://github.com/ngrigoriev/dactyl-manuform-5x7_2_6](https://github.com/ngrigoriev/dactyl-manuform-5x7_2_6). Based on the original set of Dactyl Manuform keyboards created and maintaied by [Jack Humbert](https://github.com/jackhumbert).
|
||||
|
||||
This keyboard can be generated using one of Dactyl Manuform generators, such as (https://dactyl.mbugert.de/manuform).
|
||||
|
||||
* Keyboard Maintainer: [Nikolai Grigoriev](https://github.com/ngrigoriev)
|
||||
* Hardware Supported: Promicro
|
||||
* Hardware Availability: general DIY
|
||||
|
||||
Make example for this keyboard (after setting up your build environment):
|
||||
|
||||
make handwired/dactyl_manuform/5x7_2_6:default
|
||||
|
||||
Flashing example for this keyboard:
|
||||
|
||||
make handwired/dactyl_manuform/5x7_2_6:default:flash
|
||||
|
||||
See the [build environment setup](getting_started_build_tools) and the [make instructions](getting_started_make_guide) for more information. Brand new to QMK? Start with our [Complete Newbs Guide](newbs).
|
||||
|
||||
## Bootloader
|
||||
|
||||
Enter the bootloader in 3 ways:
|
||||
|
||||
* **Bootmagic reset**: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard
|
||||
* **Physical reset button**: Briefly press the button on the back of the PCB - some may have pads you must short instead
|
||||
* **Keycode in layout**: Press the key mapped to `QK_BOOT` if it is available
|
||||
@@ -251,7 +251,7 @@
|
||||
{"label": "Alt", "matrix": [4, 2], "x": 2.5, "y": 4, "w": 1.25},
|
||||
{"label": "Space", "matrix": [4, 6], "x": 3.75, "y": 4, "w": 6.25},
|
||||
{"label": "Alt", "matrix": [4, 10], "x": 10, "y": 4, "w": 1.5},
|
||||
{"label": "Ctrl", "matrix": [4, 12], "x": 12, "y": 4, "w": 1.5},
|
||||
{"label": "Ctrl", "matrix": [4, 12], "x": 11.5, "y": 4, "w": 1.5},
|
||||
{"label": "\u2190", "matrix": [4, 13], "x": 13, "y": 4},
|
||||
{"label": "\u2193", "matrix": [4, 14], "x": 14, "y": 4},
|
||||
{"label": "\u2192", "matrix": [4, 15], "x": 15, "y": 4}
|
||||
@@ -327,7 +327,7 @@
|
||||
{"label": "Alt", "matrix": [4, 2], "x": 2.5, "y": 4, "w": 1.25},
|
||||
{"label": "Space", "matrix": [4, 6], "x": 3.75, "y": 4, "w": 6.25},
|
||||
{"label": "Alt", "matrix": [4, 10], "x": 10, "y": 4, "w": 1.5},
|
||||
{"label": "Ctrl", "matrix": [4, 12], "x": 12, "y": 4, "w": 1.5},
|
||||
{"label": "Ctrl", "matrix": [4, 12], "x": 11.5, "y": 4, "w": 1.5},
|
||||
{"label": "\u2190", "matrix": [4, 13], "x": 13, "y": 4},
|
||||
{"label": "\u2193", "matrix": [4, 14], "x": 14, "y": 4},
|
||||
{"label": "\u2192", "matrix": [4, 15], "x": 15, "y": 4}
|
||||
|
||||
33
keyboards/haverworks/theseus75/config.h
Normal file
@@ -0,0 +1,33 @@
|
||||
// Copyright 2023 Moritz Plattner (@ebastler), Alex Havermale (@haversnail)
|
||||
// SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
#pragma once
|
||||
|
||||
/* Defines for configuring the serial driver for split comms (see https://docs.qmk.fm/drivers/serial) */
|
||||
#define SERIAL_USART_DRIVER SD3 // USART 3
|
||||
|
||||
/* Defines for required pins */
|
||||
#define ID_PIN A13
|
||||
#define USBSW_PIN A14 // Switches the hub input/output with the MUXes
|
||||
#define PSW_PIN A15 // Turns the power routing to the USB-C port on/off
|
||||
#define BUS_B_PIN C13 // Tells the hub to be bus-powered or self-powered (which in turn tells the clients to use 100 mA or 500 mA)
|
||||
#define USB_VBUS_PIN C15 // Only the master side will have VBUS present at power-up (used to determine master/slave)
|
||||
#define USBPD_1_PIN F0
|
||||
#define USBPD_2_PIN F1
|
||||
|
||||
/* Additional defines for managing power and state scross split */
|
||||
#define DISABLE_BUS_POWER_MODE TRUE
|
||||
#define KB_STATE_SYNC_INTERVAL 500
|
||||
#define USBPD_ALLOWANCE_CHECK_INTERVAL 100
|
||||
#define SPLIT_TRANSACTION_IDS_KB RPC_ID_KB_STATE
|
||||
|
||||
/* Defines for the RGB matrix */
|
||||
#define INDICATOR_MAX_BRIGHTNESS 255
|
||||
#define CAPS_LOCK_LED_INDEX 0 // LED1 on PCB
|
||||
#define WS2812_EXTERNAL_PULLUP
|
||||
#define WS2812_PWM_DRIVER PWMD3
|
||||
#define WS2812_PWM_CHANNEL 4
|
||||
#define WS2812_PWM_PAL_MODE 10
|
||||
#define WS2812_DMA_STREAM STM32_DMA1_STREAM2
|
||||
#define WS2812_DMA_CHANNEL 2
|
||||
#define WS2812_DMAMUX_ID STM32_DMAMUX1_TIM3_UP
|
||||