Run Arduino formatter
This commit is contained in:
parent
fdf74434ce
commit
3245846096
130
keymap.ino
130
keymap.ino
|
@ -8,8 +8,8 @@
|
||||||
|
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* These #include directives pull in the Kaleidoscope firmware core,
|
These #include directives pull in the Kaleidoscope firmware core,
|
||||||
* as well as the Kaleidoscope plugins we use in the Model 01's firmware
|
as well as the Kaleidoscope plugins we use in the Model 01's firmware
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
|
||||||
|
@ -45,16 +45,16 @@
|
||||||
#include "Kaleidoscope-HostPowerManagement.h"
|
#include "Kaleidoscope-HostPowerManagement.h"
|
||||||
|
|
||||||
/** This 'enum' is a list of all the macros used by the Model 01's firmware
|
/** This 'enum' is a list of all the macros used by the Model 01's firmware
|
||||||
* The names aren't particularly important. What is important is that each
|
The names aren't particularly important. What is important is that each
|
||||||
* is unique.
|
is unique.
|
||||||
*
|
|
||||||
* These are the names of your macros. They'll be used in two places.
|
These are the names of your macros. They'll be used in two places.
|
||||||
* The first is in your keymap definitions. There, you'll use the syntax
|
The first is in your keymap definitions. There, you'll use the syntax
|
||||||
* `M(MACRO_NAME)` to mark a specific keymap position as triggering `MACRO_NAME`
|
`M(MACRO_NAME)` to mark a specific keymap position as triggering `MACRO_NAME`
|
||||||
*
|
|
||||||
* The second usage is in the 'switch' statement in the `macroAction` function.
|
The second usage is in the 'switch' statement in the `macroAction` function.
|
||||||
* That switch statement actually runs the code associated with a macro when
|
That switch statement actually runs the code associated with a macro when
|
||||||
* a macro key is pressed.
|
a macro key is pressed.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
enum { MACRO_VERSION_INFO,
|
enum { MACRO_VERSION_INFO,
|
||||||
|
@ -63,58 +63,58 @@ enum { MACRO_VERSION_INFO,
|
||||||
|
|
||||||
|
|
||||||
/** The Model 01's key layouts are defined as 'keymaps'. By default, there are three
|
/** The Model 01's key layouts are defined as 'keymaps'. By default, there are three
|
||||||
* keymaps: The standard QWERTY keymap, the "Function layer" keymap and the "Numpad"
|
keymaps: The standard QWERTY keymap, the "Function layer" keymap and the "Numpad"
|
||||||
* keymap.
|
keymap.
|
||||||
*
|
|
||||||
* Each keymap is defined as a list using the 'KEYMAP_STACKED' macro, built
|
|
||||||
* of first the left hand's layout, followed by the right hand's layout.
|
|
||||||
*
|
|
||||||
* Keymaps typically consist mostly of `Key_` definitions. There are many, many keys
|
|
||||||
* defined as part of the USB HID Keyboard specification. You can find the names
|
|
||||||
* (if not yet the explanations) for all the standard `Key_` defintions offered by
|
|
||||||
* Kaleidoscope in these files:
|
|
||||||
* https://github.com/keyboardio/Kaleidoscope/blob/master/src/kaleidoscope/key_defs_keyboard.h
|
|
||||||
* https://github.com/keyboardio/Kaleidoscope/blob/master/src/kaleidoscope/key_defs_consumerctl.h
|
|
||||||
* https://github.com/keyboardio/Kaleidoscope/blob/master/src/kaleidoscope/key_defs_sysctl.h
|
|
||||||
* https://github.com/keyboardio/Kaleidoscope/blob/master/src/kaleidoscope/key_defs_keymaps.h
|
|
||||||
*
|
|
||||||
* Additional things that should be documented here include
|
|
||||||
* using ___ to let keypresses fall through to the previously active layer
|
|
||||||
* using XXX to mark a keyswitch as 'blocked' on this layer
|
|
||||||
* using ShiftToLayer() and LockLayer() keys to change the active keymap.
|
|
||||||
* keeping NUM and FN consistent and accessible on all layers
|
|
||||||
*
|
|
||||||
* The PROG key is special, since it is how you indicate to the board that you
|
|
||||||
* want to flash the firmware. However, it can be remapped to a regular key.
|
|
||||||
* When the keyboard boots, it first looks to see whether the PROG key is held
|
|
||||||
* down; if it is, it simply awaits further flashing instructions. If it is
|
|
||||||
* not, it continues loading the rest of the firmware and the keyboard
|
|
||||||
* functions normally, with whatever binding you have set to PROG. More detail
|
|
||||||
* here: https://community.keyboard.io/t/how-the-prog-key-gets-you-into-the-bootloader/506/8
|
|
||||||
*
|
|
||||||
* The "keymaps" data structure is a list of the keymaps compiled into the firmware.
|
|
||||||
* The order of keymaps in the list is important, as the ShiftToLayer(#) and LockLayer(#)
|
|
||||||
* macros switch to key layers based on this list.
|
|
||||||
*
|
|
||||||
*
|
|
||||||
|
|
||||||
* A key defined as 'ShiftToLayer(FUNCTION)' will switch to FUNCTION while held.
|
Each keymap is defined as a list using the 'KEYMAP_STACKED' macro, built
|
||||||
* Similarly, a key defined as 'LockLayer(NUMPAD)' will switch to NUMPAD when tapped.
|
of first the left hand's layout, followed by the right hand's layout.
|
||||||
|
|
||||||
|
Keymaps typically consist mostly of `Key_` definitions. There are many, many keys
|
||||||
|
defined as part of the USB HID Keyboard specification. You can find the names
|
||||||
|
(if not yet the explanations) for all the standard `Key_` defintions offered by
|
||||||
|
Kaleidoscope in these files:
|
||||||
|
https://github.com/keyboardio/Kaleidoscope/blob/master/src/kaleidoscope/key_defs_keyboard.h
|
||||||
|
https://github.com/keyboardio/Kaleidoscope/blob/master/src/kaleidoscope/key_defs_consumerctl.h
|
||||||
|
https://github.com/keyboardio/Kaleidoscope/blob/master/src/kaleidoscope/key_defs_sysctl.h
|
||||||
|
https://github.com/keyboardio/Kaleidoscope/blob/master/src/kaleidoscope/key_defs_keymaps.h
|
||||||
|
|
||||||
|
Additional things that should be documented here include
|
||||||
|
using ___ to let keypresses fall through to the previously active layer
|
||||||
|
using XXX to mark a keyswitch as 'blocked' on this layer
|
||||||
|
using ShiftToLayer() and LockLayer() keys to change the active keymap.
|
||||||
|
keeping NUM and FN consistent and accessible on all layers
|
||||||
|
|
||||||
|
The PROG key is special, since it is how you indicate to the board that you
|
||||||
|
want to flash the firmware. However, it can be remapped to a regular key.
|
||||||
|
When the keyboard boots, it first looks to see whether the PROG key is held
|
||||||
|
down; if it is, it simply awaits further flashing instructions. If it is
|
||||||
|
not, it continues loading the rest of the firmware and the keyboard
|
||||||
|
functions normally, with whatever binding you have set to PROG. More detail
|
||||||
|
here: https://community.keyboard.io/t/how-the-prog-key-gets-you-into-the-bootloader/506/8
|
||||||
|
|
||||||
|
The "keymaps" data structure is a list of the keymaps compiled into the firmware.
|
||||||
|
The order of keymaps in the list is important, as the ShiftToLayer(#) and LockLayer(#)
|
||||||
|
macros switch to key layers based on this list.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
A key defined as 'ShiftToLayer(FUNCTION)' will switch to FUNCTION while held.
|
||||||
|
Similarly, a key defined as 'LockLayer(NUMPAD)' will switch to NUMPAD when tapped.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* Layers are "0-indexed" -- That is the first one is layer 0. The second one is layer 1.
|
Layers are "0-indexed" -- That is the first one is layer 0. The second one is layer 1.
|
||||||
* The third one is layer 2.
|
The third one is layer 2.
|
||||||
* This 'enum' lets us use names like QWERTY, FUNCTION, and NUMPAD in place of
|
This 'enum' lets us use names like QWERTY, FUNCTION, and NUMPAD in place of
|
||||||
* the numbers 0, 1 and 2.
|
the numbers 0, 1 and 2.
|
||||||
*
|
|
||||||
*/
|
*/
|
||||||
|
|
||||||
enum { PRIMARY, NUMPAD, FUNCTION }; // layers
|
enum { PRIMARY, NUMPAD, FUNCTION }; // layers
|
||||||
|
|
||||||
|
|
||||||
/* This comment temporarily turns off astyle's indent enforcement
|
/* This comment temporarily turns off astyle's indent enforcement
|
||||||
* so we can make the keymaps actually resemble the physical key layout better
|
so we can make the keymaps actually resemble the physical key layout better
|
||||||
*/
|
*/
|
||||||
// *INDENT-OFF*
|
// *INDENT-OFF*
|
||||||
|
|
||||||
|
@ -169,8 +169,8 @@ KEYMAPS(
|
||||||
// *INDENT-ON*
|
// *INDENT-ON*
|
||||||
|
|
||||||
/** versionInfoMacro handles the 'firmware version info' macro
|
/** versionInfoMacro handles the 'firmware version info' macro
|
||||||
* When a key bound to the macro is pressed, this macro
|
When a key bound to the macro is pressed, this macro
|
||||||
* prints out the firmware build information as virtual keystrokes
|
prints out the firmware build information as virtual keystrokes
|
||||||
*/
|
*/
|
||||||
|
|
||||||
static void versionInfoMacro(uint8_t keyState) {
|
static void versionInfoMacro(uint8_t keyState) {
|
||||||
|
@ -203,7 +203,7 @@ const macro_t *macroAction(uint8_t macroIndex, uint8_t keyState) {
|
||||||
|
|
||||||
|
|
||||||
/** toggleLedsOnSuspendResume toggles the LEDs off when the host goes to sleep,
|
/** toggleLedsOnSuspendResume toggles the LEDs off when the host goes to sleep,
|
||||||
* and turns them back on when it wakes up.
|
and turns them back on when it wakes up.
|
||||||
*/
|
*/
|
||||||
void toggleLedsOnSuspendResume(kaleidoscope::plugin::HostPowerManagement::Event event) {
|
void toggleLedsOnSuspendResume(kaleidoscope::plugin::HostPowerManagement::Event event) {
|
||||||
switch (event) {
|
switch (event) {
|
||||||
|
@ -219,8 +219,8 @@ void toggleLedsOnSuspendResume(kaleidoscope::plugin::HostPowerManagement::Event
|
||||||
}
|
}
|
||||||
|
|
||||||
/** hostPowerManagementEventHandler dispatches power management events (suspend,
|
/** hostPowerManagementEventHandler dispatches power management events (suspend,
|
||||||
* resume, and sleep) to other functions that perform action based on these
|
resume, and sleep) to other functions that perform action based on these
|
||||||
* events.
|
events.
|
||||||
*/
|
*/
|
||||||
void hostPowerManagementEventHandler(kaleidoscope::plugin::HostPowerManagement::Event event) {
|
void hostPowerManagementEventHandler(kaleidoscope::plugin::HostPowerManagement::Event event) {
|
||||||
toggleLedsOnSuspendResume(event);
|
toggleLedsOnSuspendResume(event);
|
||||||
|
@ -277,8 +277,8 @@ KALEIDOSCOPE_INIT_PLUGINS(
|
||||||
);
|
);
|
||||||
|
|
||||||
/** The 'setup' function is one of the two standard Arduino sketch functions.
|
/** The 'setup' function is one of the two standard Arduino sketch functions.
|
||||||
* It's called when your keyboard first powers up. This is where you set up
|
It's called when your keyboard first powers up. This is where you set up
|
||||||
* Kaleidoscope and any plugins.
|
Kaleidoscope and any plugins.
|
||||||
*/
|
*/
|
||||||
void setup() {
|
void setup() {
|
||||||
// First, call Kaleidoscope's internal setup function
|
// First, call Kaleidoscope's internal setup function
|
||||||
|
@ -298,10 +298,10 @@ void setup() {
|
||||||
}
|
}
|
||||||
|
|
||||||
/** loop is the second of the standard Arduino sketch functions.
|
/** loop is the second of the standard Arduino sketch functions.
|
||||||
* As you might expect, it runs in a loop, never exiting.
|
As you might expect, it runs in a loop, never exiting.
|
||||||
*
|
|
||||||
* For Kaleidoscope-based keyboard firmware, you usually just want to
|
For Kaleidoscope-based keyboard firmware, you usually just want to
|
||||||
* call Kaleidoscope.loop(); and not do anything custom here.
|
call Kaleidoscope.loop(); and not do anything custom here.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
void loop() {
|
void loop() {
|
||||||
|
|
Loading…
Reference in a new issue