qmk_firmware/keyboards/<keyboard>/<keyboard>.h. For our numpad, this file would be
KC_NOto designate places in the switch matrix where there is no switch. Sometimes,
____are used as shorthand to make this section easier to read if it needs to be debugged. This is usually defined near the beginning of the
XXXXXXX(seven capital X's) for
_______(seven underscores) for
k<row><column>, counting from 0. The names themselves actually don't matter, as long as they match between the top section, which receives the keycodes from the keymap, and the bottom half which designates where each key is in the matrix.
info.json, saving it in the same folder that contains
keyboard_nameobject to set the name of the keyboard. For instruction purposes, we will put each key's object on its own line. This is only to make the file more human-readable, and does not affect the Configurator's functionality.
layoutsobject contains the data that represents the physical layout of the keyboard. It has an object
LAYOUT, which needs to match the name of our layout macro from
LAYOUTobject itself has an object named
layout, which contains one JSON object for each physical key on our keyboard, formatted as follows:
"h"keys, which represent a key's width and height, respectively.
KC_NLCKas the first key, and so on as the keymap is built. The
labelkeys are not used; they are only for the user's reference in identifying specific keys when debugging the