Run Arduino formatter
This commit is contained in:
parent
fdf74434ce
commit
3245846096
174
keymap.ino
174
keymap.ino
|
|
@ -8,9 +8,9 @@
|
|||
|
||||
|
||||
/**
|
||||
* These #include directives pull in the Kaleidoscope firmware core,
|
||||
* as well as the Kaleidoscope plugins we use in the Model 01's firmware
|
||||
*/
|
||||
These #include directives pull in the Kaleidoscope firmware core,
|
||||
as well as the Kaleidoscope plugins we use in the Model 01's firmware
|
||||
*/
|
||||
|
||||
|
||||
// The Kaleidoscope core
|
||||
|
|
@ -45,17 +45,17 @@
|
|||
#include "Kaleidoscope-HostPowerManagement.h"
|
||||
|
||||
/** 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
|
||||
* is unique.
|
||||
*
|
||||
* 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
|
||||
* `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.
|
||||
* That switch statement actually runs the code associated with a macro when
|
||||
* a macro key is pressed.
|
||||
*/
|
||||
The names aren't particularly important. What is important is that each
|
||||
is unique.
|
||||
|
||||
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
|
||||
`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.
|
||||
That switch statement actually runs the code associated with a macro when
|
||||
a macro key is pressed.
|
||||
*/
|
||||
|
||||
enum { MACRO_VERSION_INFO,
|
||||
};
|
||||
|
|
@ -63,59 +63,59 @@ enum { MACRO_VERSION_INFO,
|
|||
|
||||
|
||||
/** 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"
|
||||
* 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.
|
||||
*
|
||||
*
|
||||
keymaps: The standard QWERTY keymap, the "Function layer" keymap and the "Numpad"
|
||||
keymap.
|
||||
|
||||
* 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.
|
||||
*/
|
||||
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.
|
||||
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.
|
||||
* The third one is layer 2.
|
||||
* This 'enum' lets us use names like QWERTY, FUNCTION, and NUMPAD in place of
|
||||
* the numbers 0, 1 and 2.
|
||||
*
|
||||
*/
|
||||
Layers are "0-indexed" -- That is the first one is layer 0. The second one is layer 1.
|
||||
The third one is layer 2.
|
||||
This 'enum' lets us use names like QWERTY, FUNCTION, and NUMPAD in place of
|
||||
the numbers 0, 1 and 2.
|
||||
|
||||
*/
|
||||
|
||||
enum { PRIMARY, NUMPAD, FUNCTION }; // layers
|
||||
|
||||
|
||||
/* 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*
|
||||
|
||||
KEYMAPS(
|
||||
|
|
@ -169,9 +169,9 @@ KEYMAPS(
|
|||
// *INDENT-ON*
|
||||
|
||||
/** versionInfoMacro handles the 'firmware version info' macro
|
||||
* When a key bound to the macro is pressed, this macro
|
||||
* prints out the firmware build information as virtual keystrokes
|
||||
*/
|
||||
When a key bound to the macro is pressed, this macro
|
||||
prints out the firmware build information as virtual keystrokes
|
||||
*/
|
||||
|
||||
static void versionInfoMacro(uint8_t keyState) {
|
||||
if (keyToggledOn(keyState)) {
|
||||
|
|
@ -190,38 +190,38 @@ static void versionInfoMacro(uint8_t keyState) {
|
|||
The 'switch' statement should have a 'case' for each entry of the macro enum.
|
||||
Each 'case' statement should call out to a function to handle the macro in question.
|
||||
|
||||
*/
|
||||
*/
|
||||
|
||||
const macro_t *macroAction(uint8_t macroIndex, uint8_t keyState) {
|
||||
switch (macroIndex) {
|
||||
case MACRO_VERSION_INFO:
|
||||
versionInfoMacro(keyState);
|
||||
break;
|
||||
case MACRO_VERSION_INFO:
|
||||
versionInfoMacro(keyState);
|
||||
break;
|
||||
}
|
||||
return MACRO_NONE;
|
||||
}
|
||||
|
||||
|
||||
/** 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) {
|
||||
switch (event) {
|
||||
case kaleidoscope::plugin::HostPowerManagement::Suspend:
|
||||
LEDControl.disable();
|
||||
break;
|
||||
case kaleidoscope::plugin::HostPowerManagement::Resume:
|
||||
LEDControl.enable();
|
||||
break;
|
||||
case kaleidoscope::plugin::HostPowerManagement::Sleep:
|
||||
break;
|
||||
case kaleidoscope::plugin::HostPowerManagement::Suspend:
|
||||
LEDControl.disable();
|
||||
break;
|
||||
case kaleidoscope::plugin::HostPowerManagement::Resume:
|
||||
LEDControl.enable();
|
||||
break;
|
||||
case kaleidoscope::plugin::HostPowerManagement::Sleep:
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
/** hostPowerManagementEventHandler dispatches power management events (suspend,
|
||||
* resume, and sleep) to other functions that perform action based on these
|
||||
* events.
|
||||
*/
|
||||
resume, and sleep) to other functions that perform action based on these
|
||||
events.
|
||||
*/
|
||||
void hostPowerManagementEventHandler(kaleidoscope::plugin::HostPowerManagement::Event event) {
|
||||
toggleLedsOnSuspendResume(event);
|
||||
}
|
||||
|
|
@ -277,9 +277,9 @@ KALEIDOSCOPE_INIT_PLUGINS(
|
|||
);
|
||||
|
||||
/** 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
|
||||
* Kaleidoscope and any plugins.
|
||||
*/
|
||||
It's called when your keyboard first powers up. This is where you set up
|
||||
Kaleidoscope and any plugins.
|
||||
*/
|
||||
void setup() {
|
||||
// First, call Kaleidoscope's internal setup function
|
||||
Kaleidoscope.setup();
|
||||
|
|
@ -298,11 +298,11 @@ void setup() {
|
|||
}
|
||||
|
||||
/** loop is the second of the standard Arduino sketch functions.
|
||||
* As you might expect, it runs in a loop, never exiting.
|
||||
*
|
||||
* For Kaleidoscope-based keyboard firmware, you usually just want to
|
||||
* call Kaleidoscope.loop(); and not do anything custom here.
|
||||
*/
|
||||
As you might expect, it runs in a loop, never exiting.
|
||||
|
||||
For Kaleidoscope-based keyboard firmware, you usually just want to
|
||||
call Kaleidoscope.loop(); and not do anything custom here.
|
||||
*/
|
||||
|
||||
void loop() {
|
||||
Kaleidoscope.loop();
|
||||
|
|
|
|||
Loading…
Reference in a new issue