From 3245846096320a7d030949162c0916493f144291 Mon Sep 17 00:00:00 2001 From: Antoine Martin Date: Wed, 6 Apr 2022 14:37:38 +0200 Subject: [PATCH] Run Arduino formatter --- keymap.ino | 174 ++++++++++++++++++++++++++--------------------------- 1 file changed, 87 insertions(+), 87 deletions(-) diff --git a/keymap.ino b/keymap.ino index 183b2d2..0c19fa8 100644 --- a/keymap.ino +++ b/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();