c0baf2a964
Some values that can never, ever, change were held in local variables, rather than in PROGMEM. Fixed. Change "pressed" to a signed int so the test for < 0 makes sense, and to avoid possible weird failure modes in the case where a key release comes in when pressed is already zero. (Shouldn't happen, sure, but computers are weird.) A lot of things in process_steno had external linkage for no particular reason. They've been marked static. Stuff still builds. Distinguish between currently-held keys and keys that have been held, and expose these values through a nicely-named API so other code could, say, check on the current set of steno chording in order to make displays. Also in passing fix up the "state" value having external linkage so it could clash with other people's variable declarations. The API also provides hooks for key processing and steno chord events, so you can monitor those events without having to run in matrix_scan_user and recheck the values directly. Also document these. There is no path through processing a key that doesn't end with a return false, so the nested return foo() are gone and we just return false. |
||
|---|---|---|
| .. | ||
| gitbook/images | ||
| _summary.md | ||
| becoming_a_qmk_collaborator.md | ||
| compatible_microcontrollers.md | ||
| config_options.md | ||
| contributing.md | ||
| custom_quantum_functions.md | ||
| documentation_best_practices.md | ||
| documentation_templates.md | ||
| eclipse.md | ||
| faq_build.md | ||
| faq_debug.md | ||
| faq_general.md | ||
| faq_keymap.md | ||
| faq.md | ||
| feature_advanced_keycodes.md | ||
| feature_audio.md | ||
| feature_auto_shift.md | ||
| feature_backlight.md | ||
| feature_bluetooth.md | ||
| feature_bootmagic.md | ||
| feature_command.md | ||
| feature_dynamic_macros.md | ||
| feature_grave_esc.md | ||
| feature_key_lock.md | ||
| feature_layouts.md | ||
| feature_leader_key.md | ||
| feature_macros.md | ||
| feature_mouse_keys.md | ||
| feature_pointing_device.md | ||
| feature_ps2_mouse.md | ||
| feature_rgblight.md | ||
| feature_space_cadet.md | ||
| feature_space_shift_cadet.md | ||
| feature_stenography.md | ||
| feature_swap_hands.md | ||
| feature_tap_dance.md | ||
| feature_terminal.md | ||
| feature_thermal_printer.md | ||
| feature_unicode.md | ||
| feature_userspace.md | ||
| features.md | ||
| flashing.md | ||
| fuse.txt | ||
| getting_started_build_tools.md | ||
| getting_started_getting_help.md | ||
| getting_started_github.md | ||
| getting_started_introduction.md | ||
| getting_started_make_guide.md | ||
| getting_started_vagrant.md | ||
| hand_wire.md | ||
| hardware_avr.md | ||
| hardware_drivers.md | ||
| hardware_keyboard_guidelines.md | ||
| hardware.md | ||
| how_keyboards_work.md | ||
| internals_defines.md | ||
| internals_input_callback_reg.md | ||
| internals_midi_device_setup_process.md | ||
| internals_midi_device.md | ||
| internals_midi_util.md | ||
| internals_send_functions.md | ||
| internals_sysex_tools.md | ||
| isp_flashing_guide.md | ||
| keycode.txt | ||
| keycodes_basic.md | ||
| keycodes_us_ansi_shifted.md | ||
| keycodes.md | ||
| keymap.md | ||
| newbs_building_firmware.md | ||
| newbs_flashing.md | ||
| newbs_getting_started.md | ||
| newbs_testing_debugging.md | ||
| newbs.md | ||
| porting_your_keyboard_to_qmk_(arm_and_other_chibios_cpus).md | ||
| power.txt | ||
| quantum_keycodes.md | ||
| README.md | ||
| redirects.json | ||
| reference_glossary.md | ||
| understanding_qmk.md | ||
| unit_testing.md | ||
| usb_nkro.txt | ||
Quantum Mechanical Keyboard Firmware
What is QMK Firmware?
QMK (Quantum Mechanical Keyboard) is an open source community that maintains QMK Firmware, QMK Flasher, qmk.fm, and these docs. QMK Firmware is a keyboard firmware based on the tmk_keyboard with some useful features for Atmel AVR controllers, and more specifically, the OLKB product line, the ErgoDox EZ keyboard, and the Clueboard product line. It has also been ported to ARM chips using ChibiOS. You can use it to power your own hand-wired or custom keyboard PCB.
How to Get It
If you plan on contributing a keymap, keyboard, or features to QMK, the easiest thing to do is fork the repo through Github, and clone your repo locally to make your changes, push them, then open a Pull Request from your fork.
Otherwise, you can either download it directly (zip, tar), or clone it via git (git@github.com:qmk/qmk_firmware.git), or https (https://github.com/qmk/qmk_firmware.git).
How to Compile
Before you are able to compile, you'll need to install an environment for AVR or/and ARM development. Once that is complete, you'll use the make command to build a keyboard and keymap with the following notation:
make planck/rev4:default
This would build the rev4 revision of the planck with the default keymap. Not all keyboards have revisions (also called subprojects or folders), in which case, it can be omitted:
make preonic:default
How to Customize
QMK has lots of features to explore, and a good deal of reference documentation to dig through. Most features are taken advantage of by modifying your keymap, and changing the keycodes.